DEV Community: Adam Bennett

Migrating to Downloadable Fonts on Android

Adam Bennett — Thu, 28 Jun 2018 10:21:02 +0000

This is a rehost of the article I wrote for the Blockchain Engineering blog. You can find the original article here.

At Blockchain, we have many mobile users in bandwidth constrained environments such as developing countries. As such keeping the app small and lightweight is a priority for the Android team. Smaller app sizes increase both installs and conversion rates - important metrics for any mobile-focused company. We've used various techniques over the last year to prevent bloat to the app including shrinking what few PNGs we have, using VectorDrawables at every possible opportunity, and aggressively leveraging ProGuard.

In previous versions of the app, we bundled three fonts and relied on a third party library named Calligraphy to render the fonts across all API levels for us. Calligraphy has served us well, and for a long time was the only viable solution for font application. But the library is yet another third-party dependency and hasn't been updated in nearly a year.

One downside of using a third-party solution is that Blockchain does not have full control over these fonts - Google could break how the library works at some point in the future. The other downside to this approach is that the necessary bundled fonts take up space. Thankfully, this is no longer required.

Android Oreo added downloadable fonts, which allows apps to request typefaces from a font provider and load them at runtime instead of loading them from the apps assets folder. This has added benefits in that it reduces the chances of an app installation failing randomly, and multiple apps requesting the same font can share these resources.

As of Support Library 26.0.0, Google backported the font provider, and this has given us a native (or close to native) solution all the way down to API 14, which is beyond what we need here at Blockchain.

Adding a downloadable font is simple - head to the Layout Editor, select fontFamily -> More Fonts, and choose whatever you might need. Android Studio then imports all of the necessary files, and also adds entries to the Android Manifest and generates the relevant XML files declaring the font used, and how to retrieve it from the font provider.

We did find a slight oddity as to how this system worked. Google claims that this gives you access to every typeface on fonts.google.com. In practise, however, we could only get two variations of Montserrat via the Android Studio interface - regular and bold. We make heavy use of Montserrat Light plus Montserrat Semi-Bold, so this was not ideal.

In searching for a solution, we found the fonts we wanted via fonts.google.com and noticed that the URL parameters included a weight (300 for light, 600 for semi-bold). Simply adding these parameters into the fontProviderQuery allowed us to download them without issue, although Android Studio did then highlight the query as having no exact match. We found that this particular Lint error could be safely ignored, as the correct weights of font were loaded successfully on every test device.

app:fontProviderQuery="name=Montserrat&weight=600"

We use a couple of custom Views which could not be themed this way directly, so we also had to programmatically download the Typeface and apply this at runtime, rather than using XML or Styles. For this, we used Kotlin and higher order functions to request fonts asynchronously, before delivering the result to the caller.

Taking advantage of the flexibility of Kotlin, we also added an Extension Function that applies the newly loaded Typeface directly to a TextView. We use this in a couple of places to dynamically change the font on a TextView depending on whether or not it was the last selected View.

Lastly, we found that the speed of the loading process occasionally caused Views to "pop" as the font was applied and the View bounds adjusted. This was easily fixed by adding a local cache of Typeface objects keyed to a CustomFont object, which encapsulates the query necessary to load the font. This made programmatically loading fonts functionally instant in most cases.

After all that, we managed to reduce the APK size from 7.7MB to 6.8MB - an 11% reduction - with the download size reducing from 5.4MB to 5.0MB - a 7.5% reduction. This is a substantial win for relatively little work, and makes a huge difference to end users. If you want to view the changes, feel free to check out the feature PR here.

If you found this interesting, we're currently hiring engineers for the Android team.

A Closer look at Slices on Android

Adam Bennett — Thu, 31 May 2018 10:32:21 +0000

In the lead-up to Google IO 2018 and after peering into the Android P Alpha release, some people noticed a mysterious new "Slices" class within the P SDK docs. There was a lot of speculation as to what Slices actually did, and Sebastiano Poggi at Novoda did a great deep-dive into what was known at the time.

But now that IO has passed, what have we learned about Slices, how can we leverage them in our apps, and why would we even want to? To answer that question, let's start with App Actions.

Actions Everywhere

App Actions, also known as Actions on Google, are part of a new framework that allows developers to integrate their app fairly deeply with Google Assistant, Search, the Play Store and wherever else Google wants in the future. Whilst App Actions are not yet even in developer preview, we know a little about them from the overview website and various talks at IO.

There is a lot that you can do with App Actions such as interacting directly via Google Assistant and registering custom Intents, but for now we'll focus on how they act as a bridge to Slice functionality.

At a high level Google has defined a growing set of Intents with their own data schemes. Developers then expose content within their app to these Intents, and offer functionality via deep-linking. For the purposes of this article, we'll be looking at the actions.intent.GET_CRYPTOCURRENCY_PRICE Intent, which has got me rather excited for obvious reasons.

Intents such as GET_CRYPTOCURRENCY_PRICE can be triggered by what Google are confusingly calling Semantic Intents - which are generally spoken-word or typed queries to the Google Assistant or Search. With our example Intent, a Semantic Intent might be:

What's the current price of bitcoin in dollars?
What's ETH doing today?
How much is Dogecoin worth?

For an app to handle such queries themselves would be extremely difficult, but instead Google can recognise the intention of the user and then deliver results in a format that we can then process in some way:

{
  "cryptocurrency": {
    "name": "string"
  },
  "exchange": {
    "name": "string"
  },
  "target monetary spec": {
    "currency": "string",
    "valid_at": "date string (ISO 8601 format)"
  }
}

In the example above finding the name of the cryptocurrency is fairly easy, but the fiat currency is often implicit - I would assume that Google are using device locales or geographic location to infer the most likely local currency. Much of speech is implied, and Google handles this difficult task for you in many cases.

This is all well and good, but how do we register our app to take advantage of these Intents?

Enter actions.xml

actions.xml is a new file that you would include in your app which defines a mapping between App Actions Intents and the URIs that you wish your app to handle. Within this file, you can essentially pull values out of the App Action schema defined by the Intent and then insert them into whatever URL format your app accepts:

Note that this implementation is pulled from the IO session on App Actions - there's no documentation yet and it may well not be correct when App Actions launch proper. As such this is somewhat speculative.

This file is then scanned by Google on uploading an APK (or app bundle) to the Play Store, and the supported app actions are stored in a database. Users who then trigger the Semantic Intent associated with your app can then potentially see a suggestion to download your app in the Play Store (as an example, with more to follow in the future). It goes without saying that this can give you an edge in terms of discoverability.

Enter Slices

From here, you can handle the URL/deep link as you would any other within your app by registering an Intent Filter and pointing towards your class extending SliceProvider:

Within this class, you then override onMapIntentToUri to return a properly formed non-null URI from the supplied Intent, and then you can start actually building your first Slice.

onBindSlice is the next method that needs overriding, and it's here that you can extract more information from the URI (in this case, the cryptocurrency and fiat currency codes) and actually setup your UI.

Slices are somewhat unique in that you can't merely inflate your own Views - Google instead are providing a host of preset templates into which you can pass data (Strings, images, icons etc) as well as a handful of interactive features such as progressbars, sliders and toggles. This may be an issue for some but it means that all Slices will be visually consistent, and Google says this means that they're easily portable to new UI formats, devices, and dare I say it - operating systems.

Creating this UI is done via the ListBuilder class, which allows you to add rows of information; each row having methods such as setTitle, addEndItem, setPrimaryAction etc. You can also create a grid layout of sorts here. You also set a period of validity for the data, which in this example is infinite but should probably be quite short.

This simple ListBuilder statement creates a neat little Slice that looks like this in the Slices demo app, which for now is the only way to view them:

Loading Content

This is all well and good, but you don't necessarily have price information to hand - you'll probably want to fetch an up-to-date quote from the network. However in onBindSlice, we see some documentation:

onBindSlice should return as quickly as possible so that the UI tied to this slice can be responsive. No network or other IO will be allowed during onBindSlice. Any loading that needs to be done should happen in the background with a call to {@link ContentResolver#notifyChange(Uri, ContentObserver)} when the app is ready to provide the complete data in onBindSlice.

This, like the Slice templates, is another sensible API design choice from Google. Effectively, Google are running StrictMode around this particular function. The solution here is pretty simple - provide a "loading" placeholder UI Slice, load your data asynchronously, and then call notifyChange as required.

notifyChange causes onBindSlice to be called again, so in our naive example we store the update cryptocurrency price in a nullable property called bitcoinPrice, and decide whether or not to display a placeholder slice based on the property's null status. There are definitely better ways to do this, but this works for our purposes.

As far as next steps are concerned, you would most likely want to add some interactivity to the Slice, or at the very least link back into your app. Opening an Activity is achieved with setPrimaryAction which takes a SliceAction object - pretty much just a wrapper with a PendingIntent, icon and description.

Slices that are fully interactive accept a PendingIntent via setInputAction, for which you then register a BroadcastReceiver and handle accordingly.

Sign me up!

If this all sounds great to you, Android Studio 3.2 Canary offers a handy quick-start for implementing Slices. New -> Other -> SliceProvider leads you to a wizard that adds the necessary manifest entries for you, and allows you to personalise some things such as the URLs that you want to handle.

Bear in mind that none of the App Actions stuff that actually links your Slices to Google's indexing is available yet, nor will an app with a "valid" actions.xml compile for now.

Nevertheless, you can test out your Slices via the command line + Slice Viewer APK in the meantime until App Actions goes live. I'd encourage you to have a bit of a play with it and watch the Slices IO session, which really convinced me that Slices were a powerful feature worth investigating.

Great, but why?

With the example I've run with here, users who have the app installed who search for "what is the bitcoin price" or even potentially just "bitcoin" will see a Slice in Search or the Google Assistant. This can quite easily drive more engagement into your app, and I'm sure you can think of lots of interesting examples for your particular app or company. Interactivity is a great use case too, offering rapid access to features for users who may not have realised that such features existed. It's these little surprise-and-delight features that we all love in our apps, and that personally I enjoy implementing the most.

At the same time, adding App Actions on it's own can give you an edge in the Play Store listings, which can be extremely valuable. It's unclear from Google quite what they plan to do with this stuff (again, App Actions aren't yet even in developer preview), but the potential is there for driving more interaction with your app across multiple input types and devices.

For a more complete example, check out my test project repo where there's a slightly rough but concrete implementation. For Google's own documentation, check out their getting started guide here.

If this was helpful to you please leave some applause, and I'm more than happy to receive feedback. Finally, if you want to work on this sort of stuff, we're hiring!

Conditional statements in Builders in Kotlin

Adam Bennett — Thu, 26 Apr 2018 11:01:16 +0000

At Blockchain, we recently updated our Android app to use more robust push notifications via FCM, notifying users of BTC received to their wallets.

As you might expect, we added a custom vibration pattern to our notifications, but this presented a slight problem. As it turns out, devices where Android ≤4.3 will throw an errant SecurityException: Requires VIBRATE permission. This is easily fixed, but how do we do this in an idiomatic way?

One suggestion was to try/catch firing the notification — this is obviously quite nasty and is a raw deal for users on old devices. The simple way would be to this would be to turn the builder into a local val and then simply amend the builder separately:

This is absolutely fine but it breaks up the Builder pattern and we can do better. What if we could put this logic in-line?

Using extension functions, we can extend NotificationCompat.Builder and create a new function that accepts a predicate, and calls either one function or another depending on the outcome. Taking advantage of function literals with receivers (ie, A.() -> A), we can ensure that the functions to be triggered are both existing public methods of NotificationCompat.Builder and return the NotificationCompat.Builder object itself.

This allows us to do this:

Much cleaner, and doesn’t break the Builder flow. This ternary function seems pretty useful, can we generify it for use with any Builder class? Of course:

So this worked great and I felt pretty good about it for about 15 minutes, and then I realised that infact, Kotlin already had me covered:

apply is in-fact what exactly I was looking for, as this is both it’s receiver and return type. Sheepishly, I corrected my fun-but-not-idiomatic code and pushed it to origin.

Still, this was a fun learning experience that I thought I’d share. Kotlin and it’s high-order functions, including those built-in, are incredibly powerful and I love finding new applications for them.

Best iOS resources for an experienced dev?

Adam Bennett — Fri, 18 Aug 2017 08:36:09 +0000

I'm an experienced Android developer, but I'm looking at branching out into iOS development too. Has anyone here done the same? What are some good resources for learning iOS? What challenges did you face when you started working on iOS?

Synthetic Accessors in Kotlin

Adam Bennett — Mon, 10 Jul 2017 14:03:12 +0000

So this is a pretty nerdy blog and should be a quick one, but I just wanted to share my findings.

As you may know, accessing private methods or fields in Java from nested or anonymous inner classes results in the creation of synthetic accessor methods. Jake Wharton’s talk on Java’s hidden costs is worth a watch here if you have no idea what I’m talking about.

These synthetic accessors are generated by the compiler and have big drawbacks on Android — potentially adding hundreds if not thousands of unnecessary methods across a project, each contributing to hitting the dex limit. Direct access to these methods or fields can also be up to 7 times faster than using a getter, which is nothing to sniff at.

Consequently at Blockchain we use the Thunk annotation to signal to developers that we’ve changed the scope of a field or method for the sake of avoiding synthetic accessor creation. There’s also a handy inspection built into Android Studio to highlight cases that you might have missed:

This is pretty well known. But is this an issue in the new hotness, Kotlin?

In short, yes.

Ultimately this shouldn’t be too surprising: Kotlin compiles down to the equivalent Java bytecode, so this is indeed a problem here too. I figured it would be but I wanted to check, so here’s what I found:

class SyntheticAccessorTest {

    private var counter = 0

    fun main(args: Array<String>) {

        val someClass = SomeClass(object : SomeInterface {
            override fun doSomething() {
                printSomething()
            }

            override fun doSomethingElse() {
                counter++
            }
        })
    }

    private fun printSomething() {
        print("Something")
    }
}

class SomeClass(var listener: SomeInterface)

interface SomeInterface {

    fun doSomething()

    fun doSomethingElse()

}

Here we have a simple test class which invokes the constructor of another simple class and takes an anonymous implementation of an interface. In one of the callbacks, we invoke a function which is private, in another we increment a counter which is also private. Unfortunately because of this, the resulting .class file will absolutely have synthetic accessor methods, and once we look into it, it’s easy to see why.

In Android Studio, if we select Kotlin Bytecode and then Decompile, we get this Java (I’ve simplified this a bit for readability):

public final class SyntheticAccessorTest {
   private int counter;

   public final void main(@NotNull String[] args) {
      new SomeClass(new SomeInterface() {
         public void doSomething() {
            SyntheticAccessorTest.this.printSomething();
         }

         public void doSomethingElse() {
            int var1;
            SyntheticAccessorTest.this.counter = (var1 = SyntheticAccessorTest.this.counter) + 1;
         }
      });
   }

   private final void printSomething() {
      String var1 = "Something";
      System.out.print(var1);
   }
}

If we then decompile the file with javap -p -c SyntheticAccessorTest.class, we then get this:

public final class SyntheticAccessorTest {
  private int counter;
public final void main(java.lang.String[]);
    Code:
       [...]
private final void printSomething();
    Code:
       [...]
public SyntheticAccessorTest();
    Code:
       [...]
public static final void access$printSomething(SyntheticAccessorTest);
    Code:
       [...]
public static final int access$getCounter$p(SyntheticAccessorTest);
    Code:
       [...]
public static final void access$setCounter$p(SyntheticAccessorTest, int);
    Code:
       [...]
}

And there they are: it’s these access$ methods that are the problem. In fact we get two for the counter field; one for set, one for get. You can easily see how this starts to add up quickly in an Android project.

If we change both counter and printSomething() to internal, we get this instead:

public final class SyntheticAccessorTest {
  private int counter;
public final int getCounter$Test_Project();
    Code:
       [...]
public final void setCounter$Test_Project(int);
    Code:
       [...]
public final void main(java.lang.String[]);
    Code:
       [...]
public final void printSomething$Test_Project();
    Code:
       [...]
public SyntheticAccessorTest();
    Code:
       [...]
}

Better. But what is interesting here is that whilst we lose the synthetic accessor for printSomething(), we still get two methods for setting and getting the counter property. This is due to Kotlin automagically adding getters and setters to properties, and indeed if we check the generated Java, we see:

public final int getCounter$production_sources_for_module_Test_Project() {
   return this.counter;
}

public final void setCounter$production_sources_for_module_Test_Project(int var1) {
   this.counter = var1;
}

Whether or not this seems unnecessary is up to you. In most Java classes you’d likely have written setters and getters anyway, so you haven’t really gained any unneeded methods in many situations. However in this case as the property is being accessed inside the parent class: these are obviously superfluous. Applying the same inspection to the equivalent Java code results in just 3 methods; two fewer than Kotlin.

If this is a huge concern for you there’s a simple fix; add the @JvmField annotation to the property and the getter/setter won’t be generated (thanks to Kirill Rakhman for the heads up).

So yes, you do need to be careful about accessing private functions in Kotlin for the same reason as you do in Java, and there appears to be a hidden cost in simply using properties. Sadly there isn’t yet an inspection for this yet, but I’m hoping that IntelliJ/Google will add this fairly soon. In the meantime, check your code carefully if the dex method count is something you worry about.

Ensuring code quality onÂ Android

Adam Bennett — Fri, 16 Jun 2017 16:25:08 +0000

Everybody likes to think they output good quality code, but how do you ensure that whilst making sure that your team members are on the same page? Here’s a few techniques that I’ve used over the years. This blog is mostly aimed at team leads or seniors working with 3+ people, but some may tips be useful for single contributor/OSS projects.

Formatting & Consistency

Personally, I’m super pedantic about the formatting in my code. Even just errant or missing spaces a bugbear, but thankfully there are tools to prevent this sort of general annoyance.

Code styleÂ rules

The first step is to make sure that your team are all reading from the same hymn sheet. Some may be more strident about consistency than others, but at the very least you should choose a code style and stick with it. For many, just using the default IntelliJ/Android Studio code style is enough; many use the Google Java code style.

Regardless of whether you use the default or some crazy custom settings, why not simplify everyone’s lives and bundle your settings with your project’s git repo? This saves you digging around IntelliJ’s preferences when onboarding a new team member, and provides one less excuse for those not adhering to standards.

Bootstrap

Better yet, why not have your project install your code style for you? This idea is shamelessly lifted from the excellent Kickstarter app, where they have a scripts folder which contains a bash file which sets up the project for youâ€Š–â€Šcopying across their code style xml, removing the default file header, running git submodule update --init --recursive, and even checking for the presence of their keystore and warning the user if it’s not found.

We’ve made use of this idea on the Blockchain Android app, and it makes onboarding new developers and contributing to the open source repo much easier. Alternatively you could probably write this as a Gradle build script too if that’s more your thing.

Android Guidelines

IntelliJ/Android Studio’s formatting rules can only get you so farâ€Š–â€Šwhat about formatting for RxJava operators? Resource naming conventions? Do you want your team using conditionals without braces?

For this, I recommend that you write or fork a more complete style guide, such as the excellent one by the Ribot team. This leaves no ambiguity as to how you expect your team to write your code, and I leave a version of it that I’ve edited pinned to Chrome to refer to whenever I forget something silly. Recently we started using Kotlin in production but I found the official guidelines a bit lacking, so I wrote a basic guideline for that too. Link to these guidelines in your README.md and never have an argument about line wrapping again.

Enforcement

So you’ve done all of this but you want to make sure that people are actually sticking to the rules you’ve laid outâ€Š–â€Šhow do you go about it?

Thankfully there are tools out there which allow you to validate this stuff. Checkstyle is the most commonly used tool for this; just ensure that the checkstyle task is being run in CI (you do have CI, don’t you?) and that it fails the build when necessary.

You may find initially that getting builds to pass is pretty painful, as you might have to edit some rules to enforce your own style choices. Consequently, we’re not currently using it at Blockchain, but I would 100% use it on a new project if given the chance.

Robustness

What good is pretty, consistent code if it breaks or can’t be maintained? How do you make sure that your code is relatively robust?

Testing

Testing on Android used to be an absolute nightmare. Nowadays, it’s comparatively simple assuming you’ve chosen a sensible architecture and maintain reasonable design choices such as inversion of control. Consequently there’s no excuse for not having tests: they promote confidence in your code, catch edge cases you might not have designed for (if the tests are well written) and it’s just generally gratifying to see your coverage go up.

You should run unit tests on CI whenever code is pushed to a remote branch. This helps catch bugs during the development process and ensure that nothing too scary gets pushed to master. In that vein, we also have it set up so that a different CI server runs integration tests on creating a pull request into either develop or master. As these are slower, we don’t want necessarily want them running on every push.

We also make use of protected branches, which prevents a lazy developer from force pushing to master, and won’t allow us to merge PRs until all checks have passed (unit & integration tests, plus code coverage via Jacoco + Coveralls.io).

Architecture

For a testable app, you’ll want to be using some form of architecture convention, such as MVP, MVVM, MVI, Redux or whatever your preferred way is. This helps separate the Android layer (which is very difficult to test) from the core business logic, and if done sensibly can make a huge difference in making the app more testable. We use MVP at Blockchain (although you can see here that we’re moving away from MVVM).

We also make heavy use of Dagger2, which has a pretty steep learning curve but makes handling the creation and injection of your dependencies much easier, and therefore makes testing simpler. I would definitely recommend spending some time learning how to use it.

Again this is where having a company guideline linked in your repo is probably the simplest way to make sure the team is adhering to your architecture. Referring back to Ribot, their style guide also includes an awesome architecture diagram as well as their reasoning as to why they chose the layers and structure that they did. If you’re thinking about switching to something like MVP, write out a similar diagram as you may find it helpful, then get coding a simple example for the team to refer to.

Bugs

Of course, testing only gets you so far; there will be plenty of bugs that you might not have spotted. Here again, there are tools to give you a hand.
Lint is a big one, and this can be run from the command line (and therefore CI) and output the results for you. You can also customise your lint rules should you so want, and again bundle them in your repo.

You should aim to reduce the number of lint errors that you see at build time, but for years this was quite difficult to enforce as either a single error would fail your build, or you simply added lintOptions.abortOnError false to your build.gradle. Mercifully, the Android team has added a tool to allow you to set a baseline and save that in your repoâ€Š–â€Šmeaning that from that point forward, any new errors results in build failures.

The downside is that Lint only runs when you’re generating a release build, and when you’re under pressure to get a build out to QA or what have you, that might not be the best time to have to fix errors. The solution is simple: add a Lint task to your CI process (are you noticing a pattern yet?). It’s as simple asÂ ./gradlew lint, although saving the output is going to vary based on your CI provider.

Another excellent tool is FindBugs, which spots all sorts of issues related to security, performance and general code correctness. It’s a fantastic tool which I’m ashamed to admit I haven’t added to CI yet, but is run manually at least once a month to get a feel for general code correctness. I recommend it thoroughly. Again, add any custom filters to your repo so that everyone has access.

Crashes

With all the tools and caution in the world, sometimes bugs will slip through the net. How do we handle those?

Firstly, do not rely solely on the Google Play Store. Bug reports have to be manually uploaded by users, which in my experience means that less that 0.1% of all crashes are ever reported. This will change due to Google’s new stance on the matter (where everything is reported automatically), but you still don’t want to rely on the Play Store dashboard for your bug hunting.

For that I have always used Crashlytics which is exceptional. I’ve also used Firebase’s solution which is so-so, but Firebase/Google now recommend that you switch to Crashlytics anyway, which will be incorporated into their metrics in the coming month. If you don’t currently have a crash reporting library; get this added now and prepare to be humbled.

Kotlin

It wouldn’t be an Android blog without some mention of Kotlinâ€Š–â€Šbut in all seriousness; by some estimates 60% of crashes in Android apps are Null Pointer Exceptions. Kotlin’s nullable type handling helps reduce that dramatically, and should be considered for the improvement it can make to your app’s reliability (and overall developer productivity & happiness).

One caveat to this is that many static analysis tools don’t currently work with Kotlin, and Lint itself has less checks. I expect this will change in the next six months though, as the language explodes in popularity and Google throws their weight and expertise behind it.

Other tools

Sonarqube is another well-established tool that attempts to provide you with an overview of your code’s quality. It gives you a measure of technical debt, code coverage, code smells and a bunch of other useful metrics. I can’t speak to it’s quality, but it’s something that I’d like to integrate at some point.

Of course, your main line of defence in ensuring that good code goes out to your consumers is peer review. Much has been written about how to go about reviewing the code of others so I won’t say much here, other than you absolutely need to make pull requests a key part of your programming workflow if you don’t already. Linus’s Law states:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Or more succinctly: given enough eyeballs, all bugs are shallow. Although there won’t be many eyes if you work by yourself, giving yourself a “cooling off” period between writing a PR and merging it can be invaluable too.

This workflow also allows you as a team lead to keep an eye on the performance of each team member and help out those that are struggling, allows Juniors to learn from the Seniors and should be a level playing field for all where ideas and notes are exchanged, not judgements levied.

You may not want all to use all of the ideas I written about here, but I’m hoping that some of you found this useful. Go forth and create beautiful, consistent, reliable code!

What I look for in a Junior Android Dev

Adam Bennett — Fri, 28 Apr 2017 18:59:56 +0000

About a week ago, someone on /r/androiddev asked the question “What are the things that every Junior Android Developer should know?”. Being the kind of guy that I am, I was browsing the subreddit at work (whilst compiling, obviously) and got an answer in early which people seemed to like a lot. So this is mostly just me expanding on my points.

Skillset

If you’re looking to come onboard as a Junior, there’s a few things that I’d expect you to know. None of them particularly in-depth, of course (not in a patronising way), but for me to see that you’re interested in the field and learning as much as you can, I’d want to see at least some low-level knowledge in the following areas:

The Activity Lifecycle

It’s Android. There’s no getting away from it. These events are absolutely crucial to developing an app that doesn’t crash when you accidentally rotate the screen because you’re browsing in bed.

On first glance this diagram doesn’t look all that friendly:

But in reality, I don’t expect a Junior to know the whole thing off by heart. As long as you’re aware of onCreate, onPause, onResume and onDestroy, what causes them and their implications, then you’re off to a good start. If you’re a bit unsure, check out the official docs. If you give an example as to how the lifecycle could cause a memory leak, I’d be mightily impressed.

Android Components

The building blocks of any app. There’s only 4 major components: Activities, Services, Content Providers and Broadcast Receivers, and each has an important part to play in creating an Android app. You won’t necessary need all of them in a single app (for instance, in my professional career I’ve never needed to write a Content Provider), but I’d still 100% like to see that a candidate can explain roughly what each one does and what they might use one for.

Persistence Options

There’s a handful of options for persisting data on Android, and each has their own pros, cons and use-cases. There’s a helpful guide on the Android Developer website which explains how to use each type, and again I’d want to see if you can recall them and in broad strokes what you might use each type for.

Networking

This is a biggie and there’s an awful lot to know, but for someone wanting to go for a Junior position there’s only a couple of things that I’d deem essential.
Basic REST knowledge is a must, and if you can’t make a simple GET or POST request from an Android app then you’ll want to get back to hacking together some basic apps. Pretty much every app I can think of makes REST requests, and this knowledge is fundamental. Android’s Volley class is a good place to start if you want to learn the absolute basics, but in an ideal world you’ll know that it’s a pretty outdated way of doing things.

As such, if you’ve used an alternative such as Retrofit then you’ll be in a good place. There are a handful of other possible ways to do networking on Android but almost all of them are pretty niche nowâ€Š–â€ŠRetrofit is super simple, pairs nicely with the power and flexibility of OkHttp and is regularly updated with great features by the extraordinary team at Square.

Alongside that, some knowledge of serialisation would be great. Experience of Gson, Jackson, Moshi or similar is a great sign, as nobody in 2017 should be plucking values manually out of JSON.

Android StudioÂ Skills

Android Studio has come an awfully long way since the first alpha rolled out several years ago now, back in the dark days when everyone used Eclipse. Even as a Junior, I’d want to see some indication that you know the program pretty wellâ€Š–â€Šnavigating everywhere by hand is a bad sign and horribly unproductive, so I like to see people using shortcuts a lot. In fact one of my favourite interview questions is to ask a candidate's favourite shortcut, as there are so many that I regularly learn something new.

To be clear, I’m not expecting you to be a ninja by any stretch. But knowing your tools to a reasonable level shows interest in the craft. Knowing a few of these will make you dramatically more productive and make pair programming much less painful.
If you’re still using IntelliJ that’s fine too, and if you’re using Eclipse… well, I think I’d be more curious as to why than anything else.

Git

Another important one. Amazingly there are people these days who work without using a VCS system, and that’s a really big red flag for me. If you’re not using git right now you should be, and whilst the learning curve is a little steep the payoff is huge. Admittedly it can be difficult to see the benefit if you’ve solely worked by yourself up to this pointâ€Š–â€Šuntil you’ve realised that you’ve made a horrible error 6 hours into refactoring and want to revert to how the app was when it worked. This guide is no-nonsense and will get you started, and to be honest you don’t need any more than that.

Even if you just use git from a GUI like the excellent SourceTree, that’s fine with me.

Of course there are a handful of other VCS systems out there and knowing any of them is greatâ€Š–â€Šbut git is the most widely used by far.

Design Patterns

This one is perhaps less essential, and I’m sure many use some of the more common patterns without realising that they’re classified as â€˜design patterns’. But if you know the basics such as Builders, Singletons and Factory Methods and where you might use them (or even where you can find an example in the Android SDK), then that’s great.

If you happen to own or even just know about The Gang of Four or Effective Java, bonus points for you. Talking of which:

Bonus Points

You’ve ever written a Unit test, or understand why writing them on Android can be so amazingly difficult
You own at least one of the all-time classic development books
You’ve dabbled with other languages, Kotlin in particular
You’ve published something to the Play Store

Other Stuff

Of course there are other attributes that I really like to see in someone applying for a Junior Developer role, which can mostly be filed under â€˜soft skills’.
In my opinion, the role of a Junior is mostly to learn as much as they can as quickly as possible so that they can contribute meaningfully to the product. By and large, Juniors are assigned initially simple work by a Senior that will gradually take them deeper and deeper into the stack, building the developers confidence and skills along the way.

As such, to be a good Junior I think it’s critical to have good autodidact skills, and to an extent you can prove that with what I would call peripheral knowledge. You might not know how to use it, but you know that RxJava is so hot right now and it’s been on your TODO list for some other time. A lot of blogs talk about Kotlin, so that’s on there too. You’ve heard about the awful world where we had to maintain compatibility with Gingerbread. You have some idea of what the next version of Android is bringing to the table. That sort of thing.

Anything that shows that you’ve read around a bit is a really great sign, even if you’re only aware of some libraries/techniques/common issues/features.
To that end, I’d hope that you’re signed up to the excellent Android Weekly, browse /r/androiddev, and can maybe name a couple of the most influential people in the industry and follow their blogs, Mediums, Twitter accounts etc. Maybe you listen to Fragmented too.

Ultimately what I want to see more than almost anything else is some passion for the platform. I’ve been tinkering with Android for 6 years now and developing for 4, and I still get excited when I see an update from the Android team. I wasn’t expecting the Android O preview until months after it was actually announced, and I immediately flashed the (rather unstable) alpha to my device because I just had to have a play and find out what was new.

I love checking out new devices when they get announced, I race to get the latest updates from APKMirror, I’ve flashed countless custom ROMs and bricked a few devices over the years. I always watch I/O when it’s on, and one day I’ll finally make the pilgrimage to Mountain View. I own several Android t-shirts, which for an adult male is ridiculous. If you can relate to any of that; you’re my kind of developer.

Android is the most rapidly adopted technology in history, and I’m excited to be involved in it. If that excites you and you can tick off the majority of the boxes I’ve listed here then I’d like to work with you, and I look forward to teaching you as much as I can about the platform that I love.