In our previous post we looked at writing a custom lint check to enforce usages of a custom view instead of an Android framework implementation.

In this post, we’ll go over how to unit test such a scenario, and take the opportunity to look at some additional options of unit testing with lint as well.

Sometimes an Android project will have to implement a custom view that is an extension of an existing Android view. We may do this for style purposes, or to implement additional logic, or any number of customization purposes.

This solution brings a new problem for our codebase - how do we enforce that other developers use our custom view, instead of the Android framework view? We can solve this problem by writing our own Android lint check.

In our previous post we looked at the HTTP cache from Apollo Android for storing network responses. In this post, we look at its counter part, the normalized cache.

Caching is the practice of storing data that we requested previously so we can serve it faster in the future. This creates a better user experience by decreasing loading times. It also has long term benefits like reducing the number of network requests, to save on phone resources or potentially provide offline support. Today, we’re going to discuss how to use the HTTP cache for the Apollo Android SDK.

During a recent live stream on my Twitch channel, we explored three different solutions to dependency injection on Android. A do it yourself approach, Koin, and Dagger Hilt. Let’s revisit them side by side, and look at the nuances between them, so we can determine which solution we want to use in our own applications.