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.

In the last post, we demonstrated the different types of database relationships in Room. Next, we’re going to explore another niched concept of Room database management: database migrations. A migration is a way to handle moving from one version of a database to another as users update your application from the play store.