Image for post
Image for post
Image by Dan Nelson from Pixabay

When updating my Android caching library, layercache, with built-in support for the new Jetpack SecurityEncryptedSharedPreferences I started to write unit tests using Robolectric, but soon came across the exception java.security.KeyStoreException: AndroidKeyStore not found.

Usually, shadows come to mind when faced with issues like this, but in this article, we will discuss why this won’t work and how we can get around the problem to continue to write unit tests without requiring a test device.

What is Jetpack Security

The Security library implements crypto security best practices for storing data at rest and currently provides the classes EncryptedSharedPreferences and EncryptedFile.

EncryptedSharedPreferences

EncryptedSharedPreferences is an implementation of SharedPreferences where the keys and values are both encrypted. …


Image for post
Image for post

It’s hard to write an app in Android without coming across the need to serialise data using either Parcelable or Serializable. In this article, we will explore why at Babylon Health we test our implementations of these interfaces even when using code-generation tools like @Parcelize, and the tools we use to help us write tests that work for all our classes.

Why test Parcelable and Serializable implementations

Our codebase contains over 50 Parcelable and Serializable objects. When I started at Babylon, most of these were implemented using AutoParcel; however, due to build performance issues using annotation processors, I re-wrote most of these by hand.

It is worth noting that at the time @Parcelize was still experimental, so we chose not to use it. Of course, this is now officially released, and our codebase has since evolved to use it. …


Image for post
Image for post

This 3-part mini-series talks a little bit about the technical choices I make when building an app, specifically an A-Z app, to go at least some of the way to describe some aspects of what makes a (technically) great app.

  1. UI
  2. Code quality
  3. Architecture

Architecture

It doesn’t matter whether you use MVP, MVVM, MVI or whatever the next craze is as long as you use it consistently in your project as there’s nothing worse than a code base with unclear intentions.

For this particular app, I use MVVM and LiveData with a sprinkling of coroutines and clean architecture, most importantly though I try to obey the SOLID principle which Elin Nilsson summarised brilliantly in her talk at droidcon London 2018. …


Image for post
Image for post

To protect our apps from man-in-the-middle attacks one of the first things that usually springs to mind is certificate pinning. Indeed, in early 2017 I published an article that discusses implementing SSL Pinning on Android.

At the time little did I know that in late 2017 Google were to announce that Chrome 68 would deprecate support for HTTP public key pinning (HPKP). Chrome 68 was released on 24 July 2018.

The issues of certificate pinning are numerous. Firstly deciding on a reliable set of keys to pin against is tough. Once you made that decision if your expectations don’t match reality your users suffer from not being able to access your app or website. Smashing Magazine learnt about this the hard way in late 2016 when they blocked users access for up to a year because of a mismatch between the pins and the certificates. …


Image for post
Image for post

This 3-part mini-series talks a little bit about the technical choices I make when building an app, specifically an A-Z app, to go at least some of the way to describe some aspects of what makes a (technically) great app.

  1. UI
  2. Code quality
  3. Architecture

Code quality

The quality of the code is more than just how you go about structuring your classes but extends into how you spot potential issues from null pointer exceptions to memory leaks.

Static analysis

There are some excellent static analysis tools out there such as Facebook’s Infer and Uber’s NullAway if your code base is still heavily Java, however, as my apps are now 100% Kotlin they no longer offer me much help. …


Image for post
Image for post

This 3-part mini-series talks a little bit about the technical choices I make when building an app, specifically an A-Z app, to go at least some of the way to describe some aspects of what makes a (technically) great app.

  1. UI
  2. Code quality
  3. Architecture

In mid-2017 my daughter was born, and I instantly knew I wanted to create a mobile app to help her learn.


In the incredible Effective Java, item 30 continues from the previous item covering generic methods in preference to a client needing explicit casts on input parameters and return values.

The implementation in Kotlin is not much different to Java just with the type parameter list specified between fun and the function name.

// Generic method
fun <T> union(vararg sets: Set<T>): Set<T> {
return sets.flatMap { it }.toSet()
}
val union = union<Number>(setOf<Int>(1, 2), setOf<Double>(3.1, 4.2))

Introducing generic methods shouldn’t break backwards compatibility in Kotlin unless of course it introduces a new generic class as discussed in item 29 so there is little reason to ignore the guidance, avoid the Any object where you can. …


As with Java, there is no excuse in forcing clients to cast types when using your code especially when making a class generic is often trivial. Item 29 of Joshua Bloch’s brilliant Effective Java covers this by showing an example of generifying a Stack class which might look as follows in Kotlin:

class Stack(initialCapacity: Int = 16) {
private var elements = arrayOfNulls<Any?>(initialCapacity)
private var size = 0

val isEmpty = size == 0

fun push(e: Any) {
ensureCapacity()
elements[size++] = e
}

fun pop(): Any {
if (size == 0) throw EmptyStackException()
return (elements[--size] as Any).also {
elements
[size] = null // Eliminate obsolete reference
}
}

private fun ensureCapacity() {
if (elements.size == size)
elements = Arrays.copyOf(elements, …


Joshua Bloch in item 28 of Effective Java talks about why you should prefer lists to arrays by firstly highlighting some of their differences. Interestingly with Kotlin some of the differences no longer hold true because of its changes to the generic type system.

In Java, arrays are covariant meaning that where Sub is a subtype of Super an array of type Sub[] is a subtype of Super[] which can lead to an ArrayStoreException at runtime if you store a different subtype of Super in an array:

// runtime exception
Object[] objectArray = new Long[1];
objectArray[0] = "Compiles but throws an…


In the excellent Effective Java, item 27 covers unchecked warnings with the main take-home being you should remove as many as you can. Kotlin already helps by reducing the potential number of warnings we get, for example, with its use of smart casts and star-projections instead of raw types.

if (obj is String) {
println(obj.length) // Smart-cast to a String automatically
}

Where you cannot remove a warning but know it to be type-safe then in Java you would annotate the class with @SuppressWarnings(“unchecked”), the Kotlin equivalent being @Suppress(“UNCHECKED_CAST”), and of course document why it is type-safe.

One of the other tools up Kotlin’s sleeve is inline functions with reified type parameters which allow you to perform is T checks for the type parameter along with access to T::class.java. The following example is from Android…

About

Matthew Dolan

Matt Dolan has been eating doughnuts and developing with Android since the dark days of v1.6.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store