Since Google introduced the support annotations library, there’s been an increase in the application of the @Nullable and @NonNull annotations in APIs. It’s helpful in languages such as Java where optional values are not first class citizens. Static analyzers can infer at compile time if an object has the possibility of being null when passed to (or returned from) a method.
While the benefits of these annotations can certainly be helpful, they may also hinder users of an API. A great case in point would be that of the findViewById method in Android’s ActivityAppCompat class:
There are a handful of reasons why you’d want to load in a resource file for a test:
Input (or output) data is large and complex
Input (or output) data is not easily mockable, such as a File or InputStream
Configuration data is preferably externalized
One option would be to place your resources in your app’s /res or /assets directory. This requires instrumenting your tests so that you can access the resources through the app’s Context. This can be undesirable for two reasons:
Last week I gave a talk on RxJava at the Austin Droids meetup. It marked the group’s fifth year in existence (congrats to the organizers!) and was also the most attended meetup in its history. I was hoping to have the talk recorded but after some technical issues we weren’t able to make it happen. I posted the slides online after the talk but I don’t think they stand too well on their own. So I’ve taken the time to write out my narrative to the slides below.
When Android developers choose a library for their project, they aren’t merely looking for things such as features, usability, performance, documentation and support. They also care how large the library is and the number of methods it’s going to add. As a project grows and so does its dependencies, developers feel the pressure to keep their app below the 65k method limit. Proguard is too slow to wait for with non-release builds and developers try to avoid multidex like the plague. It’s therefore crucial that library authors be conscious about the size of their projects.
The simplest approach to keeping your library’s method count down is to not include any unnecessary dependencies. Any dependencies you do include will transitively be added to your users’ projects. For example, if you need a few simple utility methods, such as closing a resource quietly, don’t go adding Guava just to do this. Instead, roll your own or extract it from an existing library (make sure to give credit!). Your users will most definitely appreciate the exclusion of over 14k methods when you only needed a few.