How we got this idea

The idea to create such a game came to me during a hackathon several years ago. The format assumed that I had one working day to develop, that is, 8 hours. I chose the Android SDK to get the prototype done in time. Perhaps game engines would be better suited, but I don’t know any of them good enough.

Another game suggested to me the concept of control with the help of emotions: there you could set the character’s movements by changing the volume of your voice. Maybe already someone has also used emotions in the game control. But I knew few such examples, so I settled on this format.

Watch out! It is a loud video!

Setting up the development environment

We only need Android Studio on the computer. If you don’t have a real Android device to run, you can use an emulator with a webcam enabled.

Creating a project with ML Kit

ML Kit is a great tool to impress the hackathon jury as you use AI in your prototype! It also helps you embed machine learning solutions into projects, such as functionality for defining objects in a frame, as well as translation and OCR.

It is suitable for us that ML Kit has a free offline API for recognizing smiles and open or closed eyes.

Previously, we had to first register in the Firebase console in order to create any project with ML Kit. Now we can skip this step for offline functionality.

Android app

Removing unnecessary

Let’s take the official sample and remove what we don’t need so as not to write the logic for working with the camera from scratch.

First, download the example and try running it. Explore the Face detection mode: it will look like the article preview.

Note that the link goes to the specific commit in the past. The tutorial uses this particular version of the sample as its base. You surely can use the latest version of the sample, but you’ll have to match the diffs and adapt the ideas to the new version.

Manifest

Let’s start editing AndroidManifest.xml. We will remove all activity tags except the first one. And we will put the CameraXLivePreviewActivity in its place so that we can start from the camera right away. We leave only face in the android:value attribute to exclude unnecessary resources from the APK.

Full diff.

Camera

We will save time and won’t delete unnecessary files, and instead, we will focus on the elements of the CameraXLivePreviewActivity screen.

On line 117, we will set the face detection mode:

private String selectedModel = FACE_DETECTION;

On line 118, we will turn on the front camera:

private int lensFacing = CameraSelector.LENS_FACING_FRONT;

At the end of the onCreate method we will hide the settings on lines 198–199:

findViewById(R.id.settings_button).setVisibility(View.GONE); findViewById(R.id.control).setVisibility(View.GONE);

We can stop at this point. But if the FPS rendering and face grid are visually distracting, then you can turn them off in the following way:

In the VisionProcessorBase.java file, we remove lines 213–215 to hide the FPS:

graphicOverlay.add(
       new InferenceInfoGraphic(
          graphicOverlay, currentLatencyMs, shouldShowFps ? framesPerSecond : null));

In the FaceDetectorProcessor.java file, we remove lines 75–78 to hide the face grid:

for (Face face : faces) {
    graphicOverlay.add(new FaceGraphic(graphicOverlay, face));
    logExtrasForTesting(face);
}

Full diff.

Emotion recognition

Smile detection is turned off by default, but it’s straightforward to get started. It’s not for nothing that we took the example code as a basis! We will allocate the parameters we need into a separate class and declare the listener interface:

We will set up the FaceDetectorProcessor in the CameraXLivePreviewActivity class and subscribe to receive the emotion state to enable emotion classification. Then we convert the probabilities to boolean flags. For testing, we will add a TextView to the layout, in which we will show emotions through emoticons.

Full diff.

Divide and conquer

We are making a game, so we need a place to draw the elements. We will assume that it runs in portrait mode on the phone. Let’s split the screen into two parts: the camera on top and the game on the bottom.

Controlling a character with a smile is a difficult task, and the hackathon has little time to implement advanced mechanics. Therefore, our character will collect cool things along the way, being either at the top of the playing field or at the bottom. We will add actions with closed or open eyes as a complication of the game: we caught cool things with closed eyes, which means the points are doubled.

If you want to implement different gameplay, then I can suggest you some other options:

• Guitar Hero/Just Dance — analog, where you need to show a certain emotion to the music;
• a race with overcoming obstacles, where you need to reach the finish line in a specific time or without crashing;
• shooter, where the player shoots the enemy with a wink.

We will display the game in a custom Android View. In the onDraw method, we will draw the character to Canvas. In the first prototype, we will restrict ourselves to geometric primitives.

Player

Our character is a square. We’ll size it and position it to the left on initialization since it will be fixed to the same place. The Y-axis position will depend on the player’s smile. We will calculate all absolute values ​​relative to the size of the game area. It’s easier than choosing specific sizes, and we will also get a good look on other devices.

Cake

Our character “runs” and tries to catch cakes to score as many points as possible. We use the standard technique with the transition to the reference system relative to the player: he will stand still, and the cakes will fly towards him. If the cake square intersects with the player’s square, we count the point. And if at the same time at least one of the user’s eyes is closed, we count two points. ¯ \ _ (ツ) _ / ¯

Also there will be only one cake in our universe. When a character eats it, it moves off the screen to a random line with a random coordinate.

Intermediate results

We will make the display of points very simple. We will display the number in the screen center. We only need to consider the text height and indent the top for beauty.

Let’s see what game we made:

Graphics

We’ll add some graphics so we won’t be ashamed to show the game at the hackathon presentation!

Images

We don’t know how to draw impressive graphics. Fortunately, there are websites with free game assets. I liked this website, although it is currently not available directly for a reason unknown to me.

Animation

We draw on Canvas, which means we need to implement the animation ourselves. If there are pictures with animation, it will be easy to program them. We introduce a class for an object with images that alternate with each other.

The background also needs to be animated to get the motion effect. Having a series of background frames in memory is expensive. Therefore, we will do a trickier thing: draw one image with a time shift. Idea outline:

Full diff.

Final result

It’s hardly a masterpiece, but it’s okay for a prototype overnight. You can find the code here. It runs locally without any additional steps.

Finally, I will add that ML Kit Face Detection can be useful for other scenarios.

For example, you can analyze all the people in the frame and make sure everyone smiles and opens their eyes to take perfect selfies with friends. Detecting multiple faces in a video stream works out of the box, so the task is not difficult.

Using face contour recognition from the Face Detection module helps to replicate the masks that are now popular in almost all camera apps. And if we add interactivity through the definition of a smile and a wink, they will be doubly fun to use.

This functionality — face contour recognition — can be used for more than just entertainment. Those who have tried to cut out a photo for documents themselves will appreciate this feature. We take the face contour and automatically crop out the photo with the desired aspect ratio and the correct head position. The gyroscope sensor will help determine the proper shooting angle.

Let’s become friends on Twitter, Github, and Facebook!

Clap, share and follow me if you like it🐱‍💻

Let’s make a game with a smile control was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

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:

• Set 21 min API. It simplifies API usage a lot.
• Add .idea folder to root .gitignore . It contains files from .idea by default, but there is usually no need to keep any of .idea files.
• If you are familiar with Kotlin, enable it in the empty project wizard. Kotlin is the preferred language for Android development.
• Add project under git, for example, on GitHub. Try to give a meaningful name for every commit. Moreover, commit code piece by piece. It is a positive sign for those who will discover your repository.

Links: install Android Studio, run an app on an emulator, on the device.

First screen

The first screen contains an image and text. Content is static for now. The task is to create this in an Activity.

Please sign in to Figma to get full information about the design. Pay attention to the distance between elements on the screen.

It looks easy to implement but try to see it in landscape mode. Also, try different image shapes and text that doesn’t fit in the screen.

Landscape

Okay, let’s lay down for a second and rest after the hard work. Oh no, our app looks strange in landscape mode. The image is small, and it is hard to read the text. Therefore we need to study resource directory qualifiers.

I propose to implement a landscape layout as displayed below. The screen is divided into two parts horizontally.

List

Now move on to more complicated exercises. Take a look at the list design above. In Android, it is usually implemented via RecyclerView. An element of the list has a rounded border. The easiest way to achieve it is a CardView.

At this point, you could still use stub data. We will connect to a database later.

Pad

Sorry, but I’ll blow your mind with multiple-device configuration. As you can see we should show the double-row list in the portrait mode and one-row list in the landscape mode. Moreover, the detail screen should be placed alongside the list screen.

If you can’t beat that task, take a look at this sample. There are several ways to implement it, so it’s okay if your solution differs from the sample.

Pad testing

Without a tablet device, you could use an Android emulator to test different configurations. The more implicit way is to change the “smallest width” in the developer settings.

Camera

Our camera screen should be able to take and save a photo.

Implementing a camera from scratch on Android has been painful for many years. Because of this camera libraries exist to simplify our code:

• https://github.com/natario1/CameraView
• https://github.com/CameraKit/camerakit-android
• https://github.com/RedApparat/Fotoapparat

You could use them if you’d like. However, I’d suggest checking the new CameraX library from the Android team. At the point of writing this article, it is still in the beta version. Despite this, I hope CameraX is the future, so I prepared a sample in case you struggle with implementation details.

I left behind the scenes the easiest implementation. You could just ask Android to take a photo for you. But it is boring, isn’t it?

One last tip about the camera. You should learn about permissions and ask the camera permission before starting the preview.

CameraX troubleshooting

In the case of Caused by: java.lang.BootstrapMethodError: Exception from call site #0 bootstrap method or similar during CameraView inflating, enable Java 1.8 compatibility:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

kotlinOptions {
    jvmTarget = "1.8"
}

ML Kit

The most magical part of our application will be done by ML Kit from Google. It has free offline support for Latin-based languages. Just follow steps in this tutorial. There are several ways to recognize text on the image using the ML Kit API. I assume, that in the previous part we saved a photo to the disk, so we will use code like this:

Database

Now it is a good time to implement a database. You could use this tutorial to implement it. Additionally, I implemented the sample. But we’ll notice the warning:

Caution: Although these APIs are powerful, they are fairly low-level and require a great deal of time and effort to use.

This article describes the Room library good enough, so check it out. Generally, the implementation is easy, the only unobvious thing is using a background thread for all operations. Even DAO creation takes a noticeable amount of time, which may cause UI lags.

Test

In my opinion, testing an Android application is hard, but it worth it. As you know, there are unit tests, functional tests, and so on. However, on Android, I would divide tests into three main categories:

• Local tests that could be run on the JVM.
• Instrumented tests which should be run on device or emulator. Tests check classes.
• UI tests which should be run on device or emulator. Tests check application UI.

You should write as many local tests as you can because they are fast, easy to run. Unfortunately, they are hard to write. Therefore I wrote an article about them.

Evolution of unit tests in Android

The end

I understand that following this tutorial may be hard if you are new to Android development. You could check my implementation version below:

IvanShafran/note-app

Note that the recognition will not work without package.json file. I can’t post it due to security reasons. You could generate this file in Firebase and use it.

Let’s become friends on Twitter, Github, and Facebook!

Clap, share and follow me if you like it🐱‍💻

Note Keeper with ML —  A Pet Project Idea in Details was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

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:

• Should be shown after some condition or user action
• Has “rate us” button that leads to Google Play
• Has “remind me later” button that schedules dialog to show after some time(2 months in our case)
• Has “never show again” button that hides the dialog forever

Zero version: no unit tests

At the beginning of the Android community, unit tests were not so popular. There are several arguments behind this:

• Tests require time to be implemented and maintained
• Apps were mostly simple
• The framework itself isn’t friendly for writing unit tests

First version: my first unit test

But unfortunately, “rate us” dialog is a too vital feature to ignore unit tests. The more users leave reviews, the more new users your app gets. Also, it should not be annoying. Otherwise, people will leave 1-star reviews.

I’ve implemented a sample app that follows the logic described in the introduction. To trigger dialog, a user should click button two times. Check code in the repository.

To code first unit test, I had to do several things.

Learn a little about JUnit Framework

Feel free to skip this chapter if you are familiar with JUnit.

JUnit is the most popular testing framework for Java. It’s included in dependencies by default to all new Android projects:

dependencies {
    testImplementation 'junit:junit:4.12'
}

To write a test, you should create a class in test folder which is created by default and contains ExampleUnitTest.java. Usually, if devs test SomeClass , devs will name class with tests SomeClassTest . Moreover, most times, it belongs to the same Java package.

Let’s see a simple test. You should annotate all test methods with org.junit.Test . Android Studio will automatically show the run test button. assertEquals will throw an exception if arguments are not equal. JUnit marks test as passed if it ends without any exception.

Abstract an Android from business logic

In Android, you can’t write unit tests for a class that uses the Android framework. But wait… WHAT???!

Yes, the framework requires a specific environment and you can’t run it on any JVM. In unit tests, all Android classes are mocked to throw an exception. The best that we can do is to force it to return default values instead of throwing an exception.

// In application module build.gradle
android.testOptions {
    unitTests.returnDefaultValues = true
}

Back to the dialog, we certainly use Android classes like Activity/Fragment, View, Dialog, and others for “rate us” feature. Therefore we can’t write unit tests without a bit of effort.

First, I created an interface for every Android dependency which I use for “rate us” showing logic.

Second, I created an interface for every Java dependency that can’t be used directly in tests. More specifically, it is System.currentTimeMillis() .

Last, I applied the dependency inversion principle toShowRateUsLogic.

Mocks

Now we should write mock classes for unit tests. I’ll show one mock below. You can check all the mocks here.

First unit test

After hardworking, it is a pleasure to code the first unit test :)

To be honest, it is not. But I wrote it in the “my first unit test” style. And I’ll fix it in the next chapters.

Second version: code cleaning

The first unit test is cool but if no one can understand it, then it is useless. Therefore I’ve refactored test class:

1. setUp is marked with @Before annotation. It makes the method to be invoked before every unit test. We’ll move the common test code to setUp method.
2. A good test method has a meaningful name. It’s better for reading and also it appears in test reports. We’ll rename test1 to onFirstCheckAndOneClickItShouldNotShow .
3. I’ve added a more complicated test. The test name is too short to express all the information. That’s why we’ll add comments to the method body.
4. For the last step, we’ll delete unnecessary and wrong time set.

Third version: mocking libraries

As mentioned, we can not use Android classes in unit tests. But almost all our classes do it. And it’s quite boring to create an interface, an implementation and a mock for every class.

Fortunately, there is an alternative way. We can use mocking libraries.

Mockito

Directly to the most frequently used API:

• Use Mockito.mock(Class) to mock any interface or class
• Use Mockito.when(instance.method()).thenReturn(value) to mock method call
• Use Mockito.verify(instance).method() to check if method was called

Shared preferences mock

In my practice, shared preferences class is the most used Android dependency in business logic. Therefore I’ve implemented shared preferences mock library which mimics Android implementation. Now you can use shared preferences in unit tests with one additional line of code ;)

Fourth version: Kotlin

Kotlin is a good language for Android development. And also, it can bring improvements to unit tests code.

1. We’ll rename the test method name using spaces enclosed in backticks
2. We’ll move the common preparation code to function with default arguments
3. We’ll delete unnecessary comments because we can use named arguments
4. We’ll use mockito-kotlin cause it has a more idiomatic and compact syntax

Fifth version: Spek

Spek is a unit testing framework for Kotlin which supports Specification and Gherkin style.

Personally, the crucial features of Spek are:

• Ability to structure test due to condition
• Ability to construct tests on the go(cause test code is a lambda, not a method)

I intentionally will not describe syntax because it is easy to understand. And if you are interested in Spek then check out this link.

Moreover, Spek generates a structured test report in Android Studio.

Bonus part

The article about unit tests in Android will not be full without several mentions. If you have more links to mention, please share them in comments and I’ll add them to the article.

Robolectric

Robolectric is a framework that brings fast and reliable unit tests to Android. Tests run inside the JVM on your workstation in seconds.

It is not a pure unit testing but allows us to test Android APIs without launching a device or emulator. On the other hand, it has a bigger test run time.

Assertion frameworks

‘Rate us’ dialog logic has boolean return value, therefore we used simple assertTrue or assertFalse. But for more complicated tests, there’s not enough flexibility in default assertions.

Hamcrest is a framework for writing matcher objects allowing ‘match’ rules to be defined declaratively.

assertThat(Math.sqrt(-1), is(notANumber()))

AssertJ — fluent assertions java library.

assertThat(frodo.getName()).isEqualTo("Frodo")

Truth makes your test assertions and failure messages more readable. Similar to AssertJ, it natively supports many JDK and Guava types, and it is extensible to others.

assertThat(notificationText).contains("testuser@google.com")

Check the full sample code here:

IvanShafran/android-unit-tests-evolution-rate-us-dialog

You can star shared preferences mock library here:

IvanShafran/shared-preferences-mock

Let’s become friends on Twitter, Github, and Facebook!

Clap, share and follow me if you like it🐱‍💻

Evolution of unit tests in Android was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

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, Context.getSharedPreferences and Context.deleteSharedPreferences in memory using only Java API.

It allows you to use classes with shared preferences in unit tests as is and also to write tests for them.

Usage

Update 2022: moved to maven central.

Add it in your root build.gradle at the end of repositories:

Add the dependency to module build.gradle:

In most cases, preference class or preference utils depends on Context. In unit test instead of real Context pass Contextcreated by new SPMockBuilder().createContext().

If you already have Context with some mocked methods, you can use new SPMockBuilder().wrapContext(preconfiguredContext).

If you need raw SharedPreferences use new SPMockBuilder().createSharedPreferences().

If thread safety is necessary for your test, then configure SPMockBuilder.setThreadSafe(true) . It is false by default.

Sample

The sample below describes common code where logic uses preference class to check condition. In line 29 SPMockBuilder creates a context for the preference unit tests. Simple, isn’t it?

Alternatives

Create CounterPreferences interface and implement Java version for a test by yourself:

• Doesn’t test CounterPreferences implementation
• Requires boilerplate code in tests

Use Mockito:

• Doesn’t test CounterPreferences implementation

Use Robolectric:

• Has test startup delay for a few seconds

Use instrumented test(not a unit test!):

• Requires device for testing

The library and sample code

You can star the library and learn more info at:

IvanShafran/shared-preferences-mock

Let’s become friends on Twitter, Github and Facebook!

Clap, share and follow me if you like it🐱‍💻

Improve Android unit tests with shared preferences mock library was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR repository: https://github.com/IvanShafran/android-open-source-app-signing

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 directly from a repository. Let’s solve the problem!

First step. Create two keystores

Create one keystore for production build with strong passwords. And create another for contributors with any password. Place them both in the main app module folder. For default created project folder is “app.”

How to generate keystore

At this point add production.jks to .gitignore .

Second step. Create two properties files

Create two properties files in the same folder as described below.

Also, create production.properties with production key and passwords.

At this point add production.properties to .gitignore .

Third step. Add script

Add script listed below to the same folder and apply it in build.gradle. Script checks if production properties file exists in the folder and if it exists script uses production keystore otherwise contributors. That’s all magic :)

Don’t forget to add production.jks and production.properties to .gitignore .

Full sample here: https://github.com/IvanShafran/android-open-source-app-signing

Let’s become friends on Twitter, Github and Facebook!

Clap, share and follow me if you like it🐱‍💻

Android open source app secure build was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 through 1.2) [1]

But it only applies to fully stable APIs: std-lib, coroutines. Check [2] for the full list.

Forward compatibility

There is such statement:

Preferably (but we can’t guarantee it), the binary format is mostly forwards compatible with the next feature release, but not later ones (in the cases when new features are not used, e.g. 1.3 can understand most binaries from 1.4, but not 1.5). [1]

Not very specific but in practice, my library which targets 1.3 works fine with 1.2 and even 1.1 std-lib without any changes. And it’s not working with 1.0 due to function reference feature which I used in the library code.

But if we want more strict guarantees Kotlin compiler provides two useful flags: apiVersion and languageVersion.[3]

-language-version X.Y - compatibility mode for Kotlin language version X.Y, reports errors for all language features that came out later.[4]

-api-version X.Y - compatibility mode for Kotlin API version X.Y, reports errors for all code using newer APIs from the Kotlin Standard Library (including the code generated by the compiler).[4]

In Gradle I’ve configured it as following:

After that, you will probably see some compilation errors. In order to fix them, you should exclude new features usages and write useful extension/function/classes from 1.3 by yourself.

Library development version

You can use the latest Kotlin version in your development. Except for new language features(which we can’t use due to apiVersion and languageVersion) it also brings compiler and tooling improvements.

Dropping support of old versions

In my opinion, it is not healthy to support old versions too long. I would recommend maintaining stability only one version back. Also, you could check release dates in artifacts repository to decide which versions to support [5].

Kotlin std-lib, std-lib-jdk7 or std-lib-jdk8?

Mainly you should choose between them in the following order:

1. std-lib (for Java 6)
2. std-lib-jdk7 (for Java 7)
3. std-lib-jdk8 (for Java 8)

If your code uses some features from jdk7(for example AutoCloseable useextension) and developer who uses your library provides std-lib, not std-lib-jdk7 or std-lib-jdk8 then his app will throw NoClassDefFoundError .

In Android, there is no need to support std-lib if you minSdk 19 at least. And there is no need to support std-lib-jdk7 if you source and target compatibility JavaVersion.VERSION_1_8.[6][7] But Android Studio doesn’t warning about that so try to support std-lib with fewer restrictions.

Package structure and visibility

A good library should hide all unnecessary classes, functions and properties from library users. Mostly you should prefer using private and internal modifiers for these situations.

In addition, it is recommended to move all your not public code in the package with name “internal”:

Also, by convention, packages named “internal” are not considered public API. [8]

Java compatibility

In most cases, Kotlin does all work for you. It creates get/setfor properties for example.

Currently, I’ve faced only one problem. If you declare a public property in companion from Java it is accessible via Sample.Companion.INSTANCE . To fix that use @JvmField annotation.

Kotlin dependency in pure Java project

An Android library which is distributed as aar doesn’t include its dependency. Therefore in pure Java project library users will get NoClassDefFoundError because your library depends on Kotlin std-lib. Thus you should write notices about that in the README file or docs.

But people don’t like to read docs a lot. I would suggest one trick below. Please share in comments your opinion is it a good practice or not?

Declare dependency checker:

Check dependency in the static initializer block:

And if someone forgets to include Kotlin std-lib dependency he will get the solution in a crash log not just error.

Let’s become friends on Twitter, Github and Facebook!

Clap, share and follow me if you like it🐱‍💻

Links

1. https://kotlinlang.org/docs/reference/evolution/kotlin-evolution.html#evolving-the-binary-format
2. https://kotlinlang.org/docs/reference/evolution/kotlin-evolution.html#evolving-the-binary-format
3. https://kotlinlang.org/docs/reference/using-gradle.html#attributes-common-for-jvm-and-js
4. https://kotlinlang.org/docs/reference/evolution/compatibility-modes.html
5. https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib
6. https://developer.android.com/studio/write/java8-support
7. https://stackoverflow.com/a/13550632/7958563
8. https://kotlinlang.org/docs/reference/evolution/kotlin-evolution.html#libraries

Kotlin library development for Android/Java hints was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

@Override
public void onResume() {
    super.onResume();
    Resources resources = getContext().getResources();
}

First sample shows us that as long as fragment is attached to its host(in onResume for example) it’s safe to use getContext without nullability checking.

@Override
public void onResume() {
    super.onResume();
    new Handler().postDelayed(new Runnable() {
        @Override
        public void run() {
            final Resources resources = getContext().getResources();
        }
    }, TimeUnit.SECONDS.toMillis(5));
}

The second one reveals potential NullPointerException. If after 5 seconds fragment isn’t attached to host, app is crashed.

So getContext Nullable annotation can prevent bugs like in the second sample. But it causes a useless warning in the first sample in Java and an error in Kotlin.

How should we fix that?

Firstly we should fix potentials bugs.

1. Find all places where fragment can be detached at some point of time
2. Change code like in the sample below

In Java:

Context context = getContext();
if (context == null) {
    // Handle null context scenario
} else {
    // Old code with context
}

In Kotlin:

val context: Context = this.context ?: return // or if block

Finally replace the rest with requireContext() which returns NonNull Context instead of getContext(). But keep in mind that requireContext() will throw an exception if fragment isn’t attached to its host. So you should use requireContext() with respect to fragment lifecycle.

Wrong fixes

In Java:

1.
// requireContext() does the same
Context context = getContext();
if (context == null) {
    throw new IllegalStateException("");
}
2.
// Warning supressing only hides the real problem
private void doSomething(@NonNull final Context context) {
}

@Override
public void onResume() {
    super.onResume();

    //noinspection ConstantConditions
    doSomething(getContext());
}

In Kotlin:

// It is similar to requireContext() but with NullPointerException
val context: Context = context!!

Other similar methods

1. getActivity vs requireActivity
2. getHost vs requireHost
3. getFragmentManager vs requireFragmentManager