How to create your own Lint rule

When you are part of a multi-team project in Android, it becomes relatively hard to have a common understanding of how components should be used. This is where Android Lint can help you! In this blog we will show you how you can write your own Lint rules and test them. As an example, we create a sample Lint Detector, which is used to detect whether you have excluded the "secret data" in your application from the Android Authobackup introduced in Android Marshmallow.

Read more →

Android Resource Configuration override and Large Text Mode

In Android, the resource Configuration dictates what resources and assets are selected. The system populates a default configuration to match your device and settings (screen size, device orientation, language). Sometimes, you need to deviate from these defaults. Since API 17 you can use applyOverrideConfiguration(Configuration) to specify an alternative resource config. The normal place to do so is in the attachBaseContext(Context) method of your Activity.

public class MainActivity extends Activity {

protected void attachBaseContext(Context newBase) {
    final Configuration override = new Configuration();
    override.locale = new Locale("nl", "NL");



Here's what that looks like:

Screenshot Screenshot

Unfortunately, there's a catch.Read more →

Android: Custom ViewMatchers in Espresso

Somehow it seems that testing is still treated like an afterthought in mobile development. The introduction of the Espresso test framework in the Android Testing Support Library improved the situation a little bit, but the documentation is limited and it can be hard to debug problems. And you will run into problems, because testing is hard to learn when there are so few examples to learn from.

Anyway, I recently created my first custom ViewMatcher for Espresso and I figured I would like to share it here. I was building a simple form with some EditText views as input fields, and these fields should display an error message when the user entered an invalid input.

Read more →

Android Design Support: NavigationView

Android NavigationView

When Google announced that Android apps should follow their Material Design standards, they did not give the developers a lot of tools to actually implement this new look and feel. Of course Google’s own apps were all quickly updated and looked amazing, but the rest of us were left with little more than fancy design guidelines and no real components to use in our apps.

So last weeks release of the Android Design Support Library came as a relief to many. It promises to help us quickly create nice looking apps that are consistent with the rest of the platform, without having to roll everything for ourselves. Think of it as AppCompat’s UI-centric companion.

The NavigationView is the part of this library which I thought the most interesting. It helps you create the slick sliding-over-everything navigation drawer that is such a recognizable part of material apps. I will demonstrate how to use this component and how to avoid some common mistakes.

Read more →

The LGPL on Android

My client had me code review an Android app built for them by a third party. As part of my review, I checked the licensing terms of the open source libraries that it used. Most were using Apache 2.0 without a NOTICE file. One was using the GNU Lesser General Public License (LGPL).

My client has commercial reasons to avoid Copyleft-style licenses and so I flagged the library as unusable. The supplier understandably was not thrilled about the rework that implied and asked for an explanation and ideally some way to make it work within the license. Looking into it in more detail, I'm convinced that if you share my client's concerns, then there is no way to use LGPL licensed code on Android. Here's why I believe this to be the case.

Read more →

How to run Android Instrumentation tests with ProGuard

The app I'm working on has an extensive, automated test suite built using Instrumentation and Robotium. These are white-box tests; they know about the Java classes that make up the tested app. This means that we were unable to run the tests after ProGuarding our application. I've never seen ProGuard break any working code after setting up the right exclusions. Nevertheless, it's a bit questionable to have a huge automated test suite and not run it on the APK that we deliver to the Play Store.

ProGuard and Instrumentation Tests

One possible work-around is to use the UIAutomator framework, which does not have this limitation. There are several reason's why we couldn't: it requires API level 16 (Jelly Bean), our app supports API 8 (Froyo) as its minimum SDK version. Furthermore, we already had our test suite in place and rewriting it from scratch didn't seem like a very good use of time. Here's what we did instead.

Read more →

A better custom ViewGroup

Jerome P. commented on my earlier post denouncing the ViewHolder pattern. He suggested an improvement to the ViewGroup approach that inverts the direction of dependency between the ContactView and its layout XML file. Instead of referencing the custom class from XML, the Java code now references the layout file using a standard resource reference. This adds further type safety and it means your view class can be completely ProGuarded.
Read more →

ViewHolder considered harmful

The ListView is the most complicated, common view widget in the Android SDK. It is part of a family of widgets known as Adapter Views. These are views that use an Adapter class to mediate between the view widget and the list data it is showing.

ListView, ListAdapter and List of DataType.

The adapter's job is to prepare the views to be shown in the ListView for each element in the dataset. This tends to involve many findViewById(int) lookups, which are quite costly in CPU time. The standing Best Practices for Android dictate that adapters use something called the ViewHolder Pattern to mitigate the cost of these lookups.

Adapter classes tend to be a hotspot of smelly program code in Android, because they straddle the View and Controller responsibilities of the MVC model (1). In my part of the Clean Code in Android Apps talk at XebiCon 2013 I demonstrated why adapters get smelly, why ViewHolder doesn't help and how to use a custom view to alleviate this problem. Read on for the reprise.

Read more →

Anatomy of a Looper

There's an intersting low-level class in the Android SDK called Looper. Each app has at least one, because it powers the UI Thread. You can create Android apps perfectly fine without ever using Looper yourself, but it's an interesting thing, so let's take a look under the bonnet.

Read more →

Android Package Synergy

Unlike announced in my previous post this one is neither soon nor on a surprise topic. It is about a general aspect of Android that is, to my opinion, very powerful but often under utilized.

Android apps are not monolithic but rather a collection of components of different kinds. I suspect android took inspiration from the concept of midlet suites in j2me and believe it expanded on that quite well.
These components (except for provider) can be exposed through intent filters in the package's manifest and can be used by other components in different packages. This allows apps to accomplish tasks together which a single app could never do.
Read more →