In the most recent live stream for Tasks Of Affirmation, we looked at creating a good developer experience. It’s important to consider developers at the start of any new project, so we can ensure that over the lifetime of a project anyone who contributes can understand how to contribute, match any guidelines that a team has, and get up and running quickly. We also want to ensure that our codebase maintains a certain quality of formatting and a lack of code smells - and putting these checks in place before you even start prevents them from ever being introduced at all.

Let’s look at five developer experience concepts I consider essential to every project.

In the late summer of 2020, I began live streaming on my Twitch channel. We started off by building an Android Study Guide application. The purpose of the application was to build something people would be interested in using, while also taking the opportunity to build an application out in the open.

For a number of reasons, discussed in the latest video, I’ve decided to sunset that project and begin a new live stream series: Tasks Of Affirmation.

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.