Raising the Bar with Android StrictMode

Every project has its own business scenarios, edge cases, and fun things to solve. Still, all of them have a similar problem: how to offer an excellent user experience to their users?

One of the things that we sometimes forget, which is tightly related to UX, is the small fragments of time that the application could be unresponsive. This is widely known as Application Not Responding (ANR) dialog. Have you experienced one of those? Maybe making a payment to your friend with your bank app and then trying to share the image to your friend? Or perhaps a splash screen that takes a long time to show the app? It doesn’t necessarily mean that you got a dialog; it could be just a perception of not having feedback when you tap or swipe on the screen.

StrictMode to the Rescue

As the Android documentation says: “StrictMode is a developer tool which detects things you might be doing by accident and brings them to your attention so you can fix them.”

That being said, StrictMode can greatly help us checking if we are using the Main thread to make I/O operations. Remember that the Main thread is also known as the UI thread. When launching an app Android creates a new Linux process along with this thread, which is responsible for everything that happens onscreen. What do you think that happens if you read a SharedPreference or parse a JSON file on the main thread? That’s right: app freezes in the best scenario, or, in a worst scenario, a wild ANR appears.

Enabling StrictMode

I have done this typically on the onCreate() method of my custom Application class. I’m just copying and pasting the code example in Android Developers:

Note that DEVELOPER_MODE is just a constant that could be built maybe using a gradle.properties external flag or something similar. In some code I've worked with this is typically by default on false, and just turned on if a developer wants the option enabled.

Let’s dive a little bit into the code above to understand what we are configuring:

StrictMode.setThreadPolicy

With this we will set up the policy for actions on the current thread (our main thread). This sets a thread-local variable which will be propagated across cross-process IPC calls. For this example we are detecting disk reads, disk writes, network, and log that has violations on the Logcat. Another option that I like adding is the penaltyFlashScreen() which will flash the screen if it finds any violation.

StrictMode.setVmPolicy

You can also set up the policy for violations on the virtual machine. In this example we are detecting that maybe a SqlLiteCursor finalized without having them closed, and objects that were not correctly closed (from java.io.Closeable). Also Logging them and making a crash if any violation is found.

Let’s Do an Experiment!

Let’s make a little demo of StrictMode:

1. Create a new Application (An app with a single activity is fine).
2. Create your custom Application and do not forget to add it on your AndroidManifest file.
3. On the onCreate() method of your custom Application add the code above. Copy and paste it but without the if sentence.
4. Add just a button and try to add this code while on your onClick event:

We will just increase by one each time the button is clicked.

5. Debug the app and check what happens if you tap on the button.

In fact when I ran the app I saw three violations in this code! Two of them when the getSharedPreferences was called, another one when we fetched the counter.

Let’s create a ViewModel and use a little help from our friend named Coroutines! I’ve just dispatched the code on a IO Dispatcher, but that’s just as an example (I don’t recommend to hardcode it, otherwise you’ll end up struggling in your unit tests!)

And on our activity we will have this:

Let’s run the app now. Now we don’t have any StrictMode violations! Problem solved!

In conclusion: StrictMode is a very useful tool to find problems in your code. Let’s be more strict on our code and raise the bar! Our clients will be thankful for having well-performing apps.