Image for post
Image for post
Photo by Kyle Glenn on Unsplash

The article presents a pet project idea for Android developers. It includes design in Figma, useful links, and other tips.

Initially, I’ve created the materials for an Android course for beginners. Most students were able to implement a project from scratch, so I believe this pet project is a good start point in Android development. Experienced developers may use it as a code sample for job applications.

An empty project

A good start is essential. Let’s create an empty project in Android Studio. Almost all default preferences are okay. Check several instructions below:

Image for post
Image for post
Photo by Jukan Tateisi on Unsplash

In the article we take a look at the unit test evolution from beginner to pro-level. “Rate us” dialog is a popular feature, and it will be a good example. Typical “rate us” dialog has requirements like:

Image for post
Image for post
Photo by Rima Kruciene on Unsplash

TL;DR: Shared preferences mock is the lightweight library let you increase coverage of unit tests and simplify code for them with one line of code.

The problem

Unit test on Android uses a framework mock where every method throws UnsupportedOperationException or does nothing depending on your settings in Gradle testOptions.

In unit tests, we mostly test business logic, which often depends on preferences. Therefore you should mock all classes which use SharedPreferences inside. It is a lot of boilerplate in tests. Moreover, because of this limitation, we never test preferences class code. However, it also may have bugs.

The solution

The library implements SharedPreferences

Image for post
Image for post
Photo by James Sutton on Unsplash

TL;DR repository:

By default Android app has debug build in which APK is signed automatically with debug keystore. But for a release build, you have to sign with a manually created keystore.

If you develop an open source app, you can’t keep a keystore together with code due to security reasons. You can easily exclude it in the .gitignore file, but in this case, your contributors won’t build an app in a release variant. It complicates open source development because some bugs can only be discovered in a release build. Moreover, you can’t run UI tests for release builds…

Image for post
Image for post
Photo by Iñaki del Olmo on Unsplash

Kotlin versions support

When we develop a regular app for Android we can choose any Kotlin version. Some teams prefer to use the latest version in order to try new features and tooling improvements. Some teams wait some time before switching to a new version. It can be linked to a release cycle or waiting for community feedback on the last version.

But when we develop a library on Kotlin we have to support both versions. Luckily Kotlin has good forward and backward compatibility.

Backward compatibility

It’s simple:

All binaries are backwards compatible, i.e. a newer compiler can read older binaries (e.g. 1.3 understands 1.0…

Image for post
Image for post
Warning in Java and error in Kotlin after updating to support lib 27.1.0

TLDR: use requireContext only when you are sure fragment is attached to its host(onResume, onViewCreated, etc).

Android team annotated some sdk methods with NonNull and Nullable in support library in 27.1.0. That change leads to warnings and errors like on the picture above.

Why did they do this?

At first sight it looks like adding more and more pain to android apps development. But actually this annotations help us to decrease crash rate.

getContext can return null when fragment isn’t attached to its host. Let’s take a look at two examples.

public void onResume() {
Resources resources = getContext().getResources();

First sample shows…

Ivan Shafran

Android developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store