Still, there are a few books that I’ve read over my career so far that have drastically changed my thinking around leadership and setting teams up for success.

Some of these books I find myself suggesting so often to people, that I figured I should probably put them down in a list somewhere. So here they are! (in no particular order.)

5 Dysfunctions of a Team

This was one of the first books I read that really challenged my understanding of what a high-performing team looks like. I’ve read some of Patrick Lencioni’s other books and would recommend having a look at them too, but this remains my favourite of his works.

There are plenty of summaries that go into what the 5 dysfunctions put forward by this book are. For me, the model helped me to understand the importance of looking for potential red flags in teams. Do people avoid accountability? Are team conversations silent and lack debate? Are people generally not engaged in the results or success of the team?

The 5 dysfunctions sit in a hierarchy, with trust being at the base. Without trust, a team has no foundation to build upon. Simple I know, but also powerful. Next time you see a team struggling with some of the issues above, have a look for examples of trust. If there aren’t any to be found, building trust would be a good place to start.

Turn the Ship Around

I particularly like books that offer examples and personal experiences (as you’ll see by some of the other titles in this list).

David Marquet was a submarine commander in the US Navy, and this book recounts his experience trying to practice servant leadership.

That process isn’t a wonderous success story. The author goes through their initial attempts to practice servant leadership that ultimately failed, and the subsequent learnings from those failures.

This book was my first exposure to the idea of servant leadership, after someone did a talk summarising this book at a local meetup. That talk was a revelation for me, at a time when I was struggling with my first forays into leadership. As such, I still recommend this book to those beginning to dip their toe into a role where they are leading others.

Team of Teams

While fighting Al-Qaeda, the US Army faced a dilemma. Their command and control approach was woefully inadequate against the decentralised approach of Al-Qaeda. While the US Army troops waited for information to flow up the chain for a decision to be made, Al-Qaeda had already come and gone.

Sound familiar?

This book helped me to see the difficulty command and control organisations face when competing in a market with more agile companies. With that, came my light bulb moment around the benefit of pushing decision making down to those closest to the decision. Pushing decision making down, focussing on communicating objectives over methods, means that teams have the authority to change their approach as needed to achieve the required objective.

I’ve referenced this book when managing up as well as when convincing others to embrace the idea of being given objectives over a list of instructions.

(Another book on this topic is Escaping the Build Trap (which itself makes some references to The Art of Action), which I haven’t listed as it’s not specifically leadership-focused, but still a great read!).

Radical Candor

We’ve all had (and given) that feedback. The type that the receiver walks away from feeling like they didn’t get the full picture. The type that’s so generic, the receiver has no idea what specifically was good or needs improvement.

If you’ve been on a course about giving and receiving feedback in the last 4 years, it’s likely this book was mentioned (or at least the 4 types of feedback). It helped me understand how to give better feedback to others, but also how to receive better feedback through asking for more context.

Dichotomy of Leadership

After I read Turn the Ship Around, my understanding of servant leadership was to always give people the objective and let them figure it out. This led to some situations where teams or team members would be stuck, but I believed they had to find their way out at all costs.

In reality, leadership is a balance. It’s a balance between knowing when to lead and when to follow. When to give people space to learn, and when the situation requires a solution, fast. This book helped me to explore how I could vary my approach, based on context.

Good Leaders Ask Great Questions

I quite often had to pause while reading this book to take down a particular quote, that just really cut to the heart of that particular topic so succinctly.

Through reading this book, I realised the importance of being intentional. Making sure I work on the things only I can do, and enable others to do the other things through giving ownership. More than that, though, the book helped me explore how I could be more intentional in how I grow and identify new opportunities for learning, by being deliberate about change.

There’s a lot of great stuff here, from an author that’s spent a lot of time helping people to grow into leadership.

Upstream

As a leader, you will over time start to deal with more abstract problems. The answers will be less obvious and require more exploration of the context.

I really enjoyed this book, particularly as the author uses some great examples around education, local government, the NFL and personal finances. They use the topics to cover the barriers they believe people often face in tackling upstream issues — problem blindness (“I don’t see the problem” or “it seems inevitable”), lack of ownership (“that problem isn’t mine to fix”), and tunnelling (“I can’t deal with that right now”).

I’d highly recommend this book for anyone looking to better understand how to get to the root of a problem and implement upstream solutions, over constantly dealing with the downstream effects.

Automating these checks means reviewers or collaborators can focus on higher-level questions, instead of comments focussed on pointing at the same issue that’s been repeated many times over or missed in previous commits.

ESLint comes with a great set of built-in rules and some great community libraries (we’ll cover more on setting this up for a project in a future post), but they have to draw the line somewhere. Some codebases or companies might have more specific needs or preferences. For example, to support migrating away from a particular library method call or avoiding an approach that has known issues.

ESLint can be extended in 2 ways — using “no-restricted” rules or creating a custom plugin.

Configuring “no-restricted” Rules

There are 3 built-in rules that we can use to configure custom restrictions:

• https://eslint.org/docs/rules/no-restricted-syntax — restrict the use of certain “syntax elements” (e.g. method calls).
• https://eslint.org/docs/rules/no-restricted-globals — restrict the use of certain global variables. This could be useful if there are global variables defined for “hydrating” the app, but that global state should not be accessed directly outside of that use case.
• https://eslint.org/docs/rules/no-restricted-properties — restrict the use of a named property on a property with a specific name. Useful if we wanted to restrict the use of screen.getByTestId, for example.

These rules make it particularly easy to extend ESLint, without the need to implement an actual plugin.

Example

To demonstrate that, let’s run through an example.

While reviewing code changes, we’ve noticed some instances of the following approach:

async function someFunction() {
  const result = await asyncFunction()
    .then(x => { /* do something */});
  return result;
}

We’ve had a conversation in the team around why it’s not ideal to mix promise chains with async/await syntax in a single call like this, so we’d rather that one or the other was used in a particular code block. Ideally, though, we’d automate this check so that await and then aren’t used together in future.

We can do this with the no-restricted-syntax rule. First, though, we need to understand what syntax is to be restricted.

Restricted syntax can take an Abstract Syntax Tree (AST) selector. ASTs are a representation of the structure of code and are used by a variety of static analysis tools and code generators. https://www.twilio.com/blog/abstract-syntax-trees is a decent intro to ASTs if you want to know more. The ESLint docs also have some examples of using AST selectors to restrict syntax.

How do you know what AST selector to use for your use case? Well, the first step I’d suggest is to take the snippet of code that has the syntax to be restricted and copy it into https://astexplorer.net/. This tool parses and displays the AST for the code that you’ve provided. If you click on a particular method call or parameter, you’ll see that particular node in the tree become highlighted, as shown below.

By selecting the await keyword and seeing what’s focussed in the AST, we can see that AwaitExpression is the name for the node type we’re looking for. But we don’t want to restrict the use of all await calls, so we need to figure out what properties of that node to use to make our selector more specific.

Similar to CSS attribute selectors, we can specifically look for AwaitExpression nodes that have a particular nested property value. If we expand the properties of that node, we eventually find what we’re looking for — the “then” property name. If we use the keys to create a path to the “then” keyword, we can pull together the below AST attribute selector:

AwaitExpression[argument.callee.property.name="then"]

To configure the no-restricted-syntax rule to generate an error using our selector with a more helpful error message, we can add the following to the rules section of our .eslintrc (or wherever else ESLint config is stored):

"no-restricted-syntax": [
  "error",
  {
    "message": "promise.then is unnecessary when using async/await",
    "selector": "AwaitExpression[argument.callee.property.name=\" then\"]"
  }
]

(Note the quotes around “then” are escaped).

This takes some practice, but this approach can be very powerful when looking to automate checks for best practices and conventions in a codebase. The examples in the ESLint docs on restricting syntax are a good starting point, but ultimately the best way to get started and learn is to give it a shot!

Custom Plugin

In some cases, those rules won’t be enough. In those cases, you can take a look at implementing a custom ESLint rule. This still deals with an AST but gives you much more control to create custom logic to implement the desired check.

Check out https://eslint.org/docs/developer-guide/working-with-plugins#create-a-plugin for info on how to get started, and also https://dev.to/spukas/how-to-write-your-first-eslint-plugin-145, which walks through creating a simple plugin.

And that’s it! Next time you see something that you think would be good to automatically check for in a project you’re working on, think about how this could be done via an ESLint rule.

Further Reading

https://www.twilio.com/blog/abstract-syntax-trees https://eslint.org/docs/developer-guide/selectors https://dev.to/spukas/how-to-write-your-first-eslint-plugin-145 https://astexplorer.net/

Not much to report this week. I had the chance to take it easy this weekend, for a change. So easy, in fact, that I forgot to publish this blogpost… So, on to the picks!

Podcast Picks

218 FS Don't Agree to Project Deadlines - The Freelancers' Show

I imagine that most people reading this have been in the position where they’ve felt forced to agree to unrealistic deadlines, either at work or with a client. This episode gives some insights in to why people agree to these deadlines, why they are bad and what you can do to avoid agreeing to them in the first place.

Slack's Architecture with Keith Adams - Podcast - Software Engineering Daily

With many companies using it for communication between team members, Slack have had to make some big decisions about their architecture as they’ve grown. This episode has the lead architect from Slack talking about how they’ve made those decisions and what they’re having to do going forward to stay ahead.

Article Picks

http://iamashley.co.uk/2016/09/06/launch-week/

This post comes from RookieOven neighbour, Jack, who recently launched (congrats!). They provide simple, quality insurance for freelancers, with a focus on good design and a friendly approach (just check out their quote page… See what I mean?). In this article, Ashley, the founder of Jack, talks about what she has learnt from launching Jack, providing some interesting insight in to what did and didn’t work well.

How Writing To-Do Lists Helps Your Brain (Whether Or Not You Finish Them)

I use todo lists quite a lot, especially when I’ve got a lot on. Taking the time to make tasks concrete enough to go on a post-it note or on a piece of paper makes a big difference to me. In this article, the author talks about some of the benefits of writing todo lists and why they work.

That’s it for this week’s roundup! Got a problem you think I could help solve? Let’s grab a coffee.

Got a good fire going up in Crianlarich this weekend

This week I’ve felt very busy. Not productive, just busy. The difference, you ask? Well, there’s quite a lot of articles on that topic.

Being productive is about understanding that there is only a certain amount of time to complete the tasks that you have. You make a conscious decision to prioritise the tasks. To understand what you can and can’t get done in a given week.

Being busy, on the other hand, is about trying to make more time to complete all the tasks that you have. You try to work as much as possible. You feel guilty when you’re not working. At the end of it all, the list of tasks is still there and you feel defeated for not having completed them all. You then go back to the start and try to fit more tasks in to the next week, repeating this cycle until burnout hits you like a ton of bricks.

This weekend I went north with Eilidh to Crianlarich for a chance to take a break from everything. It’s all too easy to forget to take these breaks. When you do, though, you remember just why they are so important.

Podcast Picks

Elixir Fountain Ben Marx 2016-08-16 - Elixir Fountain

Elixir Fountain is a great show for anyone with an interest in Elixir. In this episode, the host talks with Ben Marx from Bleacher Report about their experience running Elixir in production since v1.0.

30 Consulting, Freelance, and Side Projects - React Native Radio

Although this episode is from the React Native Radio podcast, in it the host and guests discuss their experiences doing contract and freelance software development, both full time and part time. It has some interesting insights about how each of them approach common problems such as pricing and managing time.

Article Picks

How a single conversation with my boss changed my view on delegation and failure

In this article, the author discusses the problem of workplaces that encourage the silencing of failure. They reason about why, ultimately, it is healthier for failure to be recognised as an opportunity for learning and for the organisation to move forward.

You may suffer from 'impostor syndrome.' Lots of smart people with signs of high achievement do.

This. 100 times, this. As I alluded to in last week’s post, sometimes I can struggle with believing the value that I can provide. Sometimes you‘ve just got to have the confidence to look at what you do and realise that it is obviously of value to someone, or they wouldn’t be paying you to do it.

That’s it for this week’s roundup! Got a problem you think I could help solve? Let’s grab a coffee.

Starting with this post, I’ll be sharing all of those things, on a weekly basis, helping others to discover interesting content and find out what I’m actually spending my time on!

Thoughts This Week

I’m coming to the end of a contract I’ve been working on for the past couple of months and so have been thinking about where the next piece of work is going to come from.

I’ve been fortunate enough to have gained experience across many different industries, from transport, to audio, to Oil & Gas. I’ve used various technologies, from Java to develop native Android apps, to C# for ASP.NET MVC backends, to React for an embeddable website widget. While this has been great, it puts me in a somewhat awkward position when trying to sell that experience.

I often get caught up in the fact that I don’t have 5 years experience in one particular area. I often find it difficult to backup my claims that I’m a good JavaScript/C# developer.

Lately, I’ve been thinking a lot about how to make that easier. How to get some confidence about what I’m selling. In the end, I felt that it came down to having some evidence. Having something I could point to and say, “take a look at that, that’s why I’m a good JavaScript developer”.

So, this week, I came up with a list of projects that I will be focussing on. Each of them will be open-sourced and will be accompanied by blog posts about their design and any other interesting points. One of those projects is almost ready and I’ll hopefully be able to say more about it next week!

Podcast Picks

Bootstrapped Web | For Entrepreneurs Bootstrapping Web Startups | Interviews & Business Case…

When you’re thinking of creating a new SAAS product, pricing can be a tricky thing to get right. Too low and development will be slow due to lack of capital, too high and potential customers may not see it as worth it for the potential value.

The hosts of Bootstrapped Web, along with a guest, talk about their experience with trying to price SAAS products.

Startups For the Rest of Us

Nugget is an interesting concept — charge people for receiving startup ideas in their inbox, every day. Each idea has come from a real potential customer and includes some basic validation and suggestions for next steps (i.e. potential competitors that you should look at).

In this episode, the hosts of Startups for the Rest of Us are joined by the creator of Nugget to discuss where the concept came from, how they released it and how they settled on pricing for it.

Article Picks

Queues Don't Fix Overload

This article was recommended during this month’s TechMeetup Glasgow talk on microservices, by Kevin McDermott.

The author talks about the need to implement hard operational limits when designing distributed systems. Allowing services to reject data (back-pressure) or drop data (load-shedding) when they reach those limits pushes the issue back to the data source, allowing the data source to deal with the issue appropriately (i.e. retry).

Without these limits, the sources of data believe that everything is okay, the amount of in-flight data increases until it causes issues in some other area, which is then difficult to track back to the service that was at capacity and so caused the issue.

The author talks about the general approaches many people suggest to solving these problems and why they are just displacing the issues rather than solving them.

That’s it for this week’s roundup! Got a problem you think I could help solve? Let’s grab a coffee.

1. Square business cards don’t fit in a wallet…

Some people hate business cards, but I like having something I can give to someone new that I meet that gives them some means of remembering me.

After building the website for the company, I thought that square business cards would be a good fit with the logo. While they were well received, I quickly realised a slight design flaw — they don’t fit in a standard wallet. This does mean that they don’t get lost in the back of someone’s wallet, but they can get lost somewhere else just as easily, like a jacket pocket. I’m still in two minds about this one, but for the moment at least, they’re here to stay.

2. Grow and utilise your network

Getting your first few jobs can be a daunting prospect, so to be able to talk to as many people as possible, just to say “hey, I’m here and happy to help”, can make that task a lot easier. It certainly has for me.

Renting a desk at RookieOven has also proved useful, giving me an opportunity to network and get advice from others at various stages of growing their company.

I’ve not being going to that many events in Glasgow and Edinburgh in recent months. I’ll be trying to pick that back up so that I can meet new people and find out what others are doing in the software development world.

3. Have a clear set of goals

I get a sinking feeling whenever someone asks me, “so what do you do?”. My business currently sells both my experience in software development on a contract basis and my ability to leverage that experience to complete freelance projects. But that only describes what my business does, today. It doesn’t convey my vision for where I want the company to go. To create products that make people’s lives easier.

Having a clear set of goals for what you want you and your company to achieve makes it easier to figure out the tasks required to achieve them. In the coming weeks, I will be sitting down and figuring out my goals for the next 6 months to a year and the tasks required to achieve them.

4. Keep asking, “how does this help me achieve my goal?”

As opportunities come and go, a clear set of goals can help to determine which opportunities are important and which are not.

Take Facebook, for instance. You could ask, “how does creating flying internet drones help them to connect people?”. One possible answer is that internet drones could help get more people connected to the internet, meaning that more people can access Facebook to connect with others.

While answering this question can be quite objective, it at least helps to start the conversation. It can also help prevent you from getting caught up in all the small, menial tasks. If you can’t come up with a reasonable answer as to why that small task helps you achieve your goals, move on to the next task.

Given that it’s just me starting my business, my time is quite limited. So, creating a set of goals for myself and the business will help me to decide which opportunities to take and which to pass on.

5. You are not your company and your company is not you

If you’re contracting or doing freelance work, your company’s main product right now is you. But if your plan is for that to not always be the case, it’s important to treat your company as a separate entity.

Defining Technology will post about articles from news outlets or pieces I’ve written on various social media channels. It has a personality and a set of interests, making it easier for people to connect and engage with it.

While this is still in early stages, I will be continuing to grow Defining Technology’s social media presence going forward.

6. When it comes to time, choose quality over quantity

Working 80 hours a week does not mean necessarily that you will get twice the work done compared with if you’d worked 40 hours. It’s important to prioritise tasks, instead of trying to create more time to complete them.

It’s easy to devote all your time to working, but often this just leads to burnout. The hard part is being able to switch off and spend time with friends and family. Go see a movie, or go to your favourite restaurant. This is something I’ve paid particular attention to and will be keeping in mind in future months.

7. You won’t get everything right

When starting a business, you will have to make decisions with not very much information. If you later realise that it was the wrong decision, it can be demoralising.

I’ve certainly made mistakes and will definitely make more going forward. But, I make a conscious effort to understand why it was the wrong decision and learn from it, so that I don’t make the same mistake in the future.

If you’re just starting a business, I hope that these points are of some use. I’d love to hear any comments or suggestions on starting a new business, so feel free to add a comment, or get in touch.

I have not failed. I’ve just found 10,000 ways that won’t work.

• Thomas Edison

My career up until now has been, let’s say, different from most.

Since graduating from the University of Glasgow in 2013 with an MEng degree in Electronics & Software Engineering, I’ve worked in a few different industries.

I started off working for Ecebs, a company who’s technology is behind some of the biggest smart ticketing schemes in the UK and further afield. I developed Android apps that could read (and update) smart cards that conformed to the ITSO (Interoperable Transport Standards Organisation) specification (that’s every transport smart card in the UK). I also created Smart Ticket Checker, a free Android app that can read any ITSO-compatible smart card and display the information in a user-friendly way.

From there, I moved to Linn. They use cutting edge technology to produce the highest quality audio from their systems. I worked on Kazoo, a cross-platform app for controlling your Linn HiFi system that works on OSX, Windows, Linux, iOS and Android. The app is used by owners of Linn equipment all around the world.

I then moved in to Oil & Gas by joining Streamba, a company attempting to radically change the industry by building the “Google of the energy supply chain”. They leverage big data to identify where their user’s stuff is in the supply chain and how it got there.

And on Wednesday 24th May 2016, I started Defining Technology Ltd.

A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty.

• Winston Churchill

My decision to walk away from each of those opportunities wasn’t driven by the companies themselves. I got to work with some very talented people on some interesting projects. But in every job, I always felt that something was missing.

When I’m waiting to pay at the supermarket, I don’t just see the queue. I see the potential for there to be no queue. What if there was a card-only checkout? What if trolleys were designed to encourage people to pack as they go? What if the trolley knew what was in it?

I’m constantly thinking of possible solutions to problems I face everyday and I’ve carried this way of thinking in to every job I’ve had. From stacking shelves at Tesco to optimising the energy supply chain in the North Sea, how can we do this better?

There’s a term used for organisations that look at themselves in this kind of way. They are known as “learning organisations”:

[learning organizations are] organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together

• Peter Senge

It’s not that traditional organisation don’t go through change, it’s just done in a much more big-bang kind of way. The cost of change is high, putting more pressure on the need for the change to be successful, thus increasing the time taken to implement the change to try and make sure that it works. When change can be applied and tested in small chunks, the cost is reduced and then so too is the pressure for it to be successful. If it doesn’t work, revert and try a different approach.

The problem when you think like a learning organisation when working for an organisation that doesn’t is that it leads to frustration. Frustration at a lack of control. Frustration at the inability to test new approaches to try and improve the way the organisation works. You know things could be better, but have no power to influence change.

I soon realised that indeed what I was looking for was to be part of an organisation that identifies and approaches problems in the same way I do and is willing to give people, like me, the power to try new approaches to solving those problems.

The way to get started is to quit talking and begin doing.

• Walt Disney

I knew that the sure fire way to become part of a learning organisation was to start my own. Run my own business. Make mistakes and learn from them. I could take my passion for identifying solutions to everyday problems and try to monetise those solutions.

But I had a bad case of imposter syndrome. I moved from job to job thinking I was looking for the last piece of the puzzle. “I just need that bit of experience, then I’ll be ready”. The day where I had all the experience and knowledge I felt I needed never came.

My drive to identify solutions to problems has led me to attend meetups in Glasgow and Edinburgh, like CodeCraft and RookieOven. I even started BuildBetter, a series of all day events aimed at bringing people together to practice building better software.

Through attending these events, I’ve met people with all kinds of backgrounds and experiences. People I could discuss my frustrations with and hear about what they have gone through in starting their own businesses.

Eventually I realised that the only person stopping me from starting a business was my self. If I could believe in the skills I have and my ability to adapt and learn, then I could overcome the feeling of needing to know everything.

Once we accept our limits, we go beyond them.

• Albert Einstein

2016 has been a year of doing for me. I proposed to my now-fiancée, I travelled to Vietnam to see a completely different culture and now I’ve started a business.

And it all came down to a simple decision. A decision to stop focussing on the reasons for why not to do something and instead focus on the positives for doing it.

It will be an interesting few months, but I’m definitely looking forward to the challenge.

Want to find out how Defining Technology can help you? Lets grab a coffee.

The React Native WebView gives us all the information we need to be able to link a back button to it, although it may not be immediately obvious from the docs how to do this. This guide will run through an example of how to do this.

A working example can be found on React Native Playground here and a repository with a working example project can be found here.

A stylesheet containing the styles referenced in the code snippets below can be found in the React Native Playground example mentioned above.

Setting up the WebView

Before we can add the button, we need to have a WebView that shows the content in the first place. So, presuming that you’re starting with a new project, lets replace the example components in the render method of index.android.js (and/or index.ios.js) with the following:

<View style={styles.container}>
  <WebView
    ref={WEBVIEW_REF}
    style={{flex: 1}}
    onNavigationStateChange=
      {this.onNavigationStateChange.bind(this)}
    source={{uri: ‘https://google.com’}}
    /> 
 </View>

We’ve done a few things here:

• Set the source property so that the WebView will load http://google.com
• Added a ref property so we can easily get a hold of the WebView later on
• Added a callback for onNavigationStateChanged

Right now, lets focus on the onNavigationStateChanged callback. The WebView will call this callback every time the WebView’s state changes. At any one time, the WebView can either be idle, loading or in an error state (for instance, if the request timed out).

When this callback is called, it is passed on object containing information about the page that the user is currently looking at. So lets implement the callback to get ahold of this information:

onNavigationStateChange(navState) {
  this.setState({
    canGoBack: navState.canGoBack
  });
}

Here, we’ve pulled out the canGoBack property and set it in our component’s state. This property tells us if the user has navigated past the original page we loaded and so can go back towards the original page.

There are other properties that you can pull out, such as whether the page is still loading or not and the URL of the current page. You could log navState to console to take a closer look if you’re interested in what other information it contains that you could make use of. For now, we have everything we need to add the back button.

Adding the Back Button

Thanks to our callback, we now have a value in our component’s state that tells us whether we should have an enabled back button. We still need to actually add a button that the user can press to go back. So, we’ll add the following above the WebView component in the root View:

<View style={styles.topbar}>
  <TouchableOpacity
    disabled={!this.state.canGoBack}
    onPress={this.onBack.bind(this)}
    >
    <Text style={styles.topbarText}>Go Back</Text>
  </TouchableOpacity>
</View>

We’ve added a wrapper View so that the button is shown in a top bar above the WebView. Then, we’ve wrapped the Text component in a TouchableOpacity component and added a callback so that we can handle when the user presses it. Finally, we’ve linked up the disabled property of the TouchableOpacity component to our canGoBack state property so that the user can’t press the button if they are on the original page.

The final step is to link the WebView and the back button by implementing the onBack method referenced above:

onBack() {
  this.refs[WEBVIEW_REF].goBack();
}

Simple, eh? We’ve used the reference we added to the WebView at the start to get a hold of it and then simply called it’s goBack method to navigate back.

That’s it! You’ve now got a back button for your WebView. The full example can be found on React Native Playground here or in a repository here.

If you have any questions, feel free to post below!

This post is about automated unit testing, as opposed to integration/acceptance testing. For details of running UI tests as part of an acceptance testing strategy, see Xamarin.UITest.

Creating the Project

With Xamarin Studio open, click File > New > Solution… and select Android Unit Test Project.

This will generate two source files, MainActivity.cs and TestsSample.cs. TestsSample.cs will look familiar if you’ve written NUnit tests before — it uses annotations to mark methods as tests and includes a number of examples. Under the covers Xamarin use NUnitLite for Android and iOS unit testing, which exposes the same annotations as NUnit and the same basic assertions. More information about the differences between NUnit and NUnitLite can be found here.

With MainActivity.cs, there are two interesting points. Firstly, it extends TestSuiteActivity.cs, which handles the execution of the tests. Secondly, the AddTest method is used to add tests to be executed from an assembly. The example passes in the currently executing assembly, but the tests could come from another referenced assembly.

Running this sample will show an activity with buttons for running the tests and changing some options. After running the tests, the results will be shown on screen.

Automating the Tests

We know how to run the tests manually, but how can we automate this? The documentation for unit testing on iOS points to the TouchRunner class. The documentation for this class shows that it’s quite simple to setup the iOS unit tests to be automated:

runner.Writer = new TcpTextWriter ("10.0.1.2", 16384);
// start running the test suites as soon as the application is loaded
runner.AutoStart = true;
// crash the application (to ensure it's ended) and return to springboard
runner.TerminateAfterExecution = true;

The AutoStart property of the runner is set to true to tell it to start running the tests once the configuration is complete. Setting the TerminateAfterExecution property to true ensures that the application does not stay running after the tests have been completed.

The final step is to actually get the results off of the device, which is where the Writer property comes in. The runner will write basic information about the device that it is running the tests on, as well the results of the tests, using the value of the Writer property. The default Writer writes the results to the console, but a TcpTextWriter is available that can send the results to a server.

Collecting the results and dealing with them is beyond the scope of this post, but a simple TCP server can be written in a few lines using Python that would be suitable for the job. A CI build just needs to start the server before executing the tests, ensuring that the unit test application knows the IP address and port for the TCP server.

The approach is not quite so straight forward on Android (the lack of documentation doesn’t help the matter). The first issue is that on Android there are no similar properties. The TestSuiteActivity only exposes a method for adding tests. When the application is running, we can see that there is an Options button which, when pressed, shows an activity that allows for setting the details of a remote server.

Setting these values to point to a TCP server and running the tests shows that the device details and test results are sent to the server. The code that is executing the tests has to be getting the host name and port somehow, so it’s time to start digging.

Right clicking TestSuiteActivity and clicking Go To Declaration results in the class being shown in the assembly browser. Setting language to C# in the top right-hand corner of the window shows a fairly readable version of the implementation. From the generated MainActiviy class, we can see that the work to start the execution of the tests must be happening in the OnCreate base method, so that seems like a good place to start:

protected override void OnCreate(Bundle bundle)
{
    base.OnCreate (bundle);
    ...
    bool booleanExtra = this.Intent.GetBooleanExtra ("automated", false);
    if (booleanExtra) {
        AndroidRunner.Runner.Options.LoadFromBundle (this.Intent.Extras);
    }
    ...
    if (booleanExtra) {
        ThreadPool.QueueUserWorkItem (delegate {
            Log.Info ("NUnitLite", "NUnit automated tests started");
            AndroidRunner.Runner.Run (this.current_test, this);
            Log.Info ("NUnitLite", "NUnit automated tests completed");
            this.Finish ();
        });
    }
    Log.Info ("NUnitLite", "NUnit automated tests loaded.");
}

Here we start to see some interesting stuff. The method gets a boolean extra from the intent called “automated”. This is then used to decide whether to load additional options from the extras. The value is used again later on to determine whether to automatically run the tests and finish the activity when the tests have completed, or wait for the user to manually run the tests. So, we know that adding a boolean called “automated” to the intent’s extras that is set to true will cause the tests to be automatically run. But how do we get the results to be sent to a waiting server? The key is in the AndroidRunner.Runner.Options.LoadFromBundle method:

public void LoadFromBundle(Bundle bundle)
{
    this.EnableNetwork = bundle.GetBoolean ("remote", false);
    this.HostName = (bundle.GetString ("hostName") ?? "0.0.0.0");
    this.HostPort = bundle.GetInt ("hostPort", -1);
}

public bool ShowUseNetworkLogger
{
    get
    {
        return this.EnableNetwork && !string.IsNullOrWhiteSpace (this.HostName) && this.HostPort > 0;
    }
}

This provides the last piece of the puzzle. The host name and port are also pulled from the intent’s extras. The property ShowUseNetworkLogger, which is based on the “remote” extra, is used in AndroidRunner to determine whether to create a TcpTextWriter for writing the results, or just write to the console.

We can bring all this knowledge together in to a new class:

public abstract class AutomatedTestSuiteActivity : TestSuiteActivity
{
    protected override void OnCreate(Bundle bundle)
    {
        Intent.PutExtra ("automated", true);
        Intent.PutExtra ("remote", true);
        Intent.PutExtra ("hostName", HostName);
        Intent.PutExtra ("hostPort", HostPort);
        base.OnCreate (bundle);
    }

    public override void Finish ()
    {
        System.Environment.Exit (0);
    }

    protected abstract string HostName { get; }
    protected abstract int HostPort { get; }
}

This class now handles setting all the appropriate extras, all the extending class has to do is implement properties for the host name and port. Additionally, the Finish method has been overridden so that it forces the process to exit, ensuring that the application does not hang around after the tests have finished.

I hope that this post is useful to anyone else that is investigating automated Android unit tests with Xamarin and feel free to use the AutomatedTestSuiteActivity.

References

Xamarin

iOS Unit Testing — Xamarin

NUnitLite Unification — nunit/dev wiki

NUnit.UI.TouchRunner

System Keystore

Traditionally, Android applications created their own keystores for storing sensitive credentials. ICS, however, brought in the ability for applications to access credentials stored in a system keystore when authorised by a user. This not only simplifies the process, but with some devices supporting hardware-backed keystores, it can also be more secure than an application keystore stored in the file system.

If credentials using a particular algorithm are stored using a hardware feature, such as a secure element or Trusted Execution Environment (TEE), they are effectively “bound” to that particular device once installed and so protected against extraction. To determine if an algorithm is hardware-backed, the method KeyChain.isBoundKeyAlgorithm(String) can be used.

Getting an Alias

Before an application can use credentials stored in the system keystore, the user needs to give the application access to them. The KeyChain API provides a simple means of doing this:

KeyChain.choosePrivateKeyAlias (activity, new KeyChainAliasCallback(){
  public void alias(String alias) {
    if(alias != null) {
      // Do something with the selected alias
    } else {
      // User didn't select an alias, do something
    }
  }
}, null, null, null, -1, null);

The user will be shown a dialog where they can select a certificate currently stored in the system keystore, or install a new certificate. When the user selects a certificate and closes the dialog, the callback will be given an alias for the selected certificate that it can use to access it. If the user cancels the dialog, the callback will be given a null alias.

It is important to note that although the KeyChain API allows an application to provide hints as to which certificate the user should choose, it cannot force the user to select a particular certificate.

Once an application has an alias for a certificate, it can be used to obtain information associated with it. Below is an example implementation of an X509KeyManager that uses the alias for a certificate to get it’s certificate chain and private key. This can then be used to initialise an SSL context, before setting a URL connection to use the SSL context to allow it to support client authentication, as shown below. Note that the X509Impl instance should be cached instead of being created for each connection, as getting the certificate chain and private key can be slow.

package com.deftech.spotify;

import java.net.Socket;
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
import java.security.PrivateKey;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.X509KeyManager;

import android.content.Context;
import android.security.KeyChain;
import android.security.KeyChainException;

public class X509Impl implements X509KeyManager {
    private final String alias;
    private final X509Certificate[] certChain;
    private final PrivateKey privateKey;

    public static SSLContext setForConnection(HttpsURLConnection con, Context context, String alias) throws CertificateException, KeyManagementException {
        SSLContext sslContext = null;
        try {
            sslContext = SSLContext.getInstance("TLS");
        } catch(NoSuchAlgorithmException e){
            throw new RuntimeException("Should not happen...", e);
        }
        sslContext.init(new KeyManager[] { fromAlias(context, alias)}, null, null);
        con.setSSLSocketFactory(sslContext.getSocketFactory());
        return sslContext;
    }

    public static X509Impl fromAlias(Context context, String alias) throws CertificateException {
        X509Certificate[] certChain;
        PrivateKey privateKey;
        try {
            certChain = KeyChain.getCertificateChain(context, alias);
            privateKey = KeyChain.getPrivateKey(context, alias);
        } catch (KeyChainException e) {
            throw new CertificateException(e);
        } catch (InterruptedException e) {
            throw new CertificateException(e);
        }
        if(certChain == null || privateKey == null){
            throw new CertificateException("Can't access certificate from keystore");
        }
        return new X509Impl(alias, certChain, privateKey);
    }

    public X509Impl(String alias, X509Certificate[] certChain, PrivateKey privateKey) throws CertificateException {
        this.alias = alias;
        this.certChain = certChain;
        this.privateKey = privateKey;
    }

    @Override
    public String chooseClientAlias(String[] arg0, Principal[] arg1, Socket arg2) {
        return alias;
    }

    @Override
    public X509Certificate[] getCertificateChain(String alias) {
        if(this.alias.equals(alias)) return certChain;
        return null;
    }

    @Override
    public PrivateKey getPrivateKey(String alias) {
        if(this.alias.equals(alias)) return privateKey;
        return null;
    }

    @Override public final String chooseServerAlias(String keyType, Principal[] issuers, Socket socket) {
        throw new UnsupportedOperationException();
    }

    @Override public final String[] getClientAliases(String keyType, Principal[] issuers) {
        throw new UnsupportedOperationException();
    }

    @Override public final String[] getServerAliases(String keyType, Principal[] issuers) {
        throw new UnsupportedOperationException();
    }
}

References

android.security.KeyChain

Unifying Key Store Access in ICS

Android Email Client — SSLUtils.java

I have created a simple example library project that is available on GitHub here. It only provides a means of logging in, but shows how to use libspotify on Android. The pre-requisites for using it are:

• Android NDK installed (see here)
• Spotify premium account
• API key (see here)

Below is a description of the different components of the project and the steps I followed to make it.

Get libspotify

The first task is to download the Android version of libspotify from the libspotify homepage. The required file for compiling is in the lib directory of the download. Take the largest file and remove the numbers after .so (this is version information that isn’t supported by Android). Also in the download is the header file that will be needed later, under include/libspotify/api.h. Within the Hello Spotify example project, the .so file can be found under jni/libspotify, and the header under jni/headers.

Get API key

So, now we have the library. Before we can do anything with it, we need the API key, so the C code version should be downloaded and placed in the jni folder as appkey.c.

Write the makefile (Android.mk)

Now we have almost everything we need to start working with libspotify. To be able to make the code, we need a build script, Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE    := libspotify\spotify-prebuilt
LOCAL_SRC_FILES := libspotify\libspotify.so
include $(PREBUILT_SHARED_LIBRARY)

include $(CLEAR_VARS)
LOCAL_LDLIBS    := -llog
LOCAL_SHARED_LIBRARIES := libspotify\spotify-prebuilt
LOCAL_MODULE    := hello_spotify
LOCAL_SRC_FILES := appkey.c hello_spotify.c callbacks.c
include $(BUILD_SHARED_LIBRARY)

The Android build tool uses this makefile to compile the modules before putting them in the libs directory to be used by the project. There are a couple of interesting things in the Android.mk file within the project:

• PREBUILT_SHARED_LIBRARY — Android needs you to tell it what shared libraries you have, giving them a module name which can be referenced later in the makefile
• BUILD_SHARED_LIBRARY — Here, the shared library previously named spotify-prebuilt is referenced so that Android knows it is a build dependency. We also give the new module the name hello_spotify, which we will come across later
• LOCAL_LDLIBS — Android also needs you to tell it which additional libraries you are using. The project uses Android’s logging helper, so we have to include the library.
• LOCAL_MODULE — the LOCAL_MODULE defines the name of the module. In the PREBUILT section, this is the name to be used to refer to the prebuilt libraries. In the BUILD section, it defines the name for the new library that is to be built.

Now we have everything we need to start writing the actual code!

In a project like this where we are creating a bridge between C code and Java code, there needs to be some “glue”. This glue is written as C methods that are then referenced in the Java code. For the Java compiler to find the native methods, the C method names have to comply to a strict naming convention. This is best explained by example.

Say we have a class, JNIExample, that wants to make a reference to a native method, getString(), that simply returns a string. To do this, JNIExample would look like this:

package com.a.b;

public class JNIExample {
    public native String getString();    
}

Here, we see that the native keyword has been used to tell the compiler that the method is linked to a C method. But from here, the compiler has to make the link between the C method and the Java method. To do this, the method name has to follow the convention Java___, as seen below:

JNIEXPORT jstring JNICALL Java_com_a_b_JNIExample_getString(JNIEnv *, jobject);

The JNIEXPORT and JNICALL allow the method to be called from a Java class. The method naming convention allows the compiler to link the native method to the method in the class that it relates to. The JNIEnv and jobject parameters can be used by the method to more easily interact with the Java code. Finally, as the method returns a String, the return type is a jstring (the JNIEnv provides methods for converting between char*’s and jstrings).

It is best not to try and write the C header yourself. The Java tool javah can create the appropriate C header file by pointing it to a compiled Java class that makes references to native methods. It will take care of all the parameter and return type conversion, as well as the naming convention.

There is an alternative, which is to use JNI_OnLoad to register the native methods, but that’s beyond the scope of this article. For more details about this approach, see here.

Writing it

The Hello Spotify project just has 3 C files:

• appkey.c — your app key obtained from Spotify’s website
• callbacks.c — the callback methods used by libspotify to notify us of events
• hello_spotify.c — holds our JNI glue

As for headers, we have:

• callbacks.h — defines what callbacks we have implemented
• com_deftech_spotify_HelloSpotify.h — the javah-generated header file

The callback methods mainly just log using the Android logging methods. The only one that is a bit different is the logged_in callback, that takes some of the logic from one of the libspotify examples to log some details about the logged in user.

The interesting stuff here is in hello_spotify.c. First, lets look at the method for getting the build ID:

JNIEXPORT jstring JNICALL Java_com_deftech_spotify_HelloSpotify_getBuildID(JNIEnv *env, jobject jObject) {
    return (*env)->NewStringUTF(env, sp_build_id());
}

Here, we see the use of the JNIEnv to convert a char* returned by the libspotify method sp_build_id() in to a jstring that can be returned by the method in the Java class.

Now we’ve seen a simple method, we can move on to the more complicated log in method. To log in, we first need to create a session. To create a session, we need to provide a sp_session_config struct filled with config values. These include the location to be used as cache, the app key, the callbacks, etc. Once that has been filled, the session can be created by calling sp_session_create, passing it the config settings and a double pointer that it can set to point to an allocated session.

Once the session is created, we can login with the provided username and password. If this was successful, we can then create a background thread for calling sp_session_process_events.

This background thread is important, as libspotify has many internal threads that are synchronized by pushing tasks that are executed when the sp_session_process_events method is called by an application thread. It relies on this thread listening for calls to the notify_main_thread callback, as that is libspotify saying that there are events to be processed. Additionally, the application needs to make sure that no other libspotify methods are called while sp_session_process_events is executing. As this process can get difficult to manage, I thought it was best to leave it out of this simple example. The psyonspotify example in the references shows one of it doing it.

Note that the approach for the login method is naive in a number of ways:

• from the libspotify documentation here, it states that it is not supported to have multiple active sessions, and it’s recommended to only call this [sp_create_session] once per process. It would be better to have an init method that creates a session that can be used later for operations like logging in a user. This is why if you attempted to call login a few times your app will eventually crash.
• The main_loop thread doesn’t respect the timeout or the notify_main_thread callback.
• The “blob” that can be used for remembering users isn’t handled.

Building it

The NDK code has to be compiled from the command line. Navigate to the root of the project and simply run ndk-build. This will compile the code, outputting any build errors. I found it was best to clean the project in eclipse first, run ndk-build, then refresh the eclipse project.

Now that we’ve written and compiled our C code, the next step is the Java class to wrap the native code, HelloSpotify:

package com.deftech.spotify;

import android.content.Context;

public class HelloSpotify {
    private final String cacheDir;
    static {
        System.loadLibrary("hello_spotify");
    }

    public HelloSpotify(Context context){
        cacheDir = context.getCacheDir().getAbsolutePath();
    }

    public int login(String username, String password){
        return login(username, password, cacheDir);
    }

    public native String getBuildID();
    private native int login(String username, String password, String cacheDir);
}

This class is quite simple, as most of the logic of mapping the C methods to the Java methods has already been done. The important bit is the static call to load the library name specified in Android.mk. But that’s it for the Java code!

This example project can be cloned from GitHub and (after putting in your appkey.c) used as a library project by other Android projects. It provides a simple look at how to use a native library by writing the JNI glue to call it from a Java class.

Any comments/queries, just drop a comment below!

• libspotify examples
• GitHub: spotify/psyonspotify