In this article, we will show an example of using a ViewModel to initiate navigation in Jetpack Compose. For this, we use navigation state, not events.

Why not let the View control navigation?

In Google’s Jetpack examples, navigation is triggered from the composable View. As a result, control of the screen state is shared between the View and the ViewModel. Using the ViewModel to control navigation results in a single source of truth. For example, when the ViewModel starts an asynchronous action and wants to navigate after the action finishes, it can cleanly and easily do so.

Singleton Navigation Manager (alternative)

Joe Birch, among others, describes a singleton navigation manager to handle ViewModel initiated navigation. This implementation is simple, but has one vulnerability. Any ViewModel (or any class) can trigger navigation, not just the screen that is currently in view. This can cause ViewModels in the backstack to start navigation. For example, after an async action finishes. This could result in hard-to-find issues.

Active screens listen to Navigation

When we let screens listen to their own ViewModel and navigation state, ViewModels in the backstack cannot initiate navigation because they don’t have a view. Only when the view attached to a ViewModel is resumed, then the ViewModel’s navigation logic can be triggered.

When we abstract away the logic that is needed for this approach, then the implementation can be simple and short. But before we do so, let’s discuss state and events.

Why use State

“Events up, state down” is Google’s proposed way of communicating between ViewModel and View, also for navigation. They chose this unidirectional data flow because of data consistency, testability and maintainability.

In practice, this means:

• View to ViewModel communication are function calls / events, like viewModel.onXClicked(). Google seems to include direct function calls in their definition of events.
• ViewModel to View communication is done by using (View)state only.

For example, a navigation flow might look like this:

Note that in the example project, most logic in this flow is abstracted away.

Using state in the ViewModel for navigation might feel a bit strange at first, especially because of step 4 and 5 in the diagram: notifying the ViewModel of the navigation (4) and setting the state to Idle (5). Using state here does make the code unidirectional and unambiguous.

Implementation

The needed navigation logic can be found in the ViewModelNavigationCompose example project and is not elaborate. In your project, you will need to use these 3 files:

• NavigationState: the state model class.

• RouteNavigator: a class that ViewModels can delegate their navigation state logic to, as shown in HomeViewModel. When you’ve added it, your ViewModel can call methods like navigateToRoute, navigateUp and popToRoute.

• NavRoute: the super class for your routes. Your screens will need these to be able to support navigation, as shown in HomeRoute.

If your composable supports navigation arguments, take a look at ContentPageRoute.

That’s all

With this approach, you will have a single source of truth. View state, including navigation, is controlled by the ViewModel. The navigation logic is abstracted away, keeping your ViewModels and Routes short and clean.

This logic is a starting point. navigateForResult was not implemented yet; I usually try to keep it out of my projects as much as possible. If you have any comments or suggestions for improvements, let me know.

Want to read more?

• An interesting read on state and events from Michael Ferguson: Sending ViewModel Events to the UI in Android.
• Google’s documented viewpoint on the UI layer in app architecture.

Did you encounter the “IllegalArgumentException: X is unknown to this NavController” in your crash logs while you feel that your navigation setup is valid? You’re not the only one. Let’s fix it!

The cause

You would experience the exception when you are trying to navigate to a destination that is not included in the current navigation graph. This could be an implementation mistake on your part, but if you’re sure it’s not: in the world of Fragments this also happens when you trigger a (second) navigation request from a fragment that is no longer the current location (currentDestination) in the navController. In other words, when navigating from A to B, there is a moment when:

• Fragment A is still active and showing.
• The navigation library already changed its current location,currentDestination, to Fragment B.

When a second request to navigate from fragment A comes in at exactly this moment, and it uses a destination that is not included in B’s graph: 💥kaboom.

Reproducing

You can reproduce this by wildly clicking your buttons at the same time or by mimicking it in your code. When B is not a valid destination in its own navigation graph (B cannot navigate to B), this code in Fragment A will crash your app:

navController.navigate(actionToB) // 👍 currentDestination A -> B
navController.navigate(actionToB) // 💥 there is no actionToB in B

The navigation library developers are not going to fix this problem, as written in this bug report, because they feel it’s the Fragment’s responsibility.

Fixing

Jake Lee wrote a good solution to resolve this error. Here’s an extension method that makes his solution more generic: Fragment.mayNavigate()

mayNavigate will return true if the current Fragment is still the current one according to the NavController. If it’s not, then we should not do the navigate call, because we’re already navigating away from the current Fragment.

The inners

Inside mayNavigate, the function adds the current destination as one of the fragment’s view tags, so that on the next navigate call we can check if the fragment doing the navigate call is also still the ‘current fragment’ according to the navigation library.

More goodies: navigateSafe()

To ease its use, I added more extension methods, so we can simply replace all findNavController().navigate() calls with the safer navigateSafe(…) in our Fragments’ code as shown in this gist.

Bye-bye crash, hello sleep! Let me know if you see any room for improvement.

In most of my projects, I use an OkHttp interceptor to monitors traffic and add headers to requests. There are some drawbacks to this setup.

The problem with interceptors

• Fragmented query construction. The class that constructs the request (your remote repository) knows nothing about the headers that are added in the interceptor while these are part of the same request.
• The interceptor is smart and all-knowing. Headers often differ per endpoint and may be based on app-state like login-state, auth tokens and the user-selected language. To fetch or use this logic, the interceptor needs to be too smart. It may cross module boundaries to acquire data. It can break feature-module independence.
• Overriding or manipulating issues. Header manipulation specific for one endpoint or feature is harder to achieve. Same for headers that are specific for one request, like a file upload.

Alternatives

There are ways around these problems, but they won’t make you fly. To name a few: one could add custom annotations on requests to communicate what type of headers should be set in the interceptor. This only solves a small part of the problem. Retrofit’s @Header and @Headers annotations can also be used, but often result in duplicate code.

To the rescue: Strong typed header maps

Instead of an interceptor, we can use a HeadersMap directly in the Retrofit interface. It’s short and generic but leaves room for mistakes because any map can be used as input for the request’s interface method.

// NO. (too generic and therefore room for mistakes)

@GET("user")
fun getUser(@HeaderMap headers: Map<String, String>): User

However, if we make the header’s type more explicit then we won’t be able to mix up different sets of headers.

// YES

@GET("user")
fun getUser(@HeaderMap authedHeaders: AuthenticatedHeaders): User

The AuthenticatedHeaders class can look like this.

/* for requests that require authentication */
class AuthenticatedHeaders : MainApiHeaders()

/* for requests that are public */
class PublicHeaders : MainApiHeaders()

open class MainApiHeaders: HashMap<String, String>()

Using an inline class is not desirable here because Retrofit explicitly requires a Map, and we would lose our strong narrow typed parameter if we deconstruct the inner class when calling the interface method.

Now in our Retrofit Api interface methods, we can specify explicitly what headers are needed on what request.

@GET("articles")
fun getArticles(
    @HeaderMap publicHeaders: PublicHeaders): List<Articles>

@GET("user")
fun getUser(@HeaderMap authedHeaders: AuthenticatedHeaders): User

In this way, trying to call getUser with the wrong headers would result in an IDE and compilation error. To provide the headers, I usually make use of a HeadersProvider per endpoint.

The HeadersProvider is injected into the feature’s Service or RemoteRepository class. The state data it needs is supplied at header-construction time. For example:

// in the class that starts the request:

apiMain.getProfile(authenticatedHeaders =
    headersProvider.getAuthenticatedHeaders(accessToken)
)

As a result, headers can be altered safely based on parameters like the login state or user settings. Generating different headers per endpoint is easy and the header logic can be centralized per feature, per endpoint or for the whole app, depending on the use-case.

When using ViewBinding (available from Android Studio 3.6), a best practice is to nullify the binding in a Fragment’sonDestroyView. In our project, we often forgot to do so. We also copy-pasted binding logic to all our Fragments, causing duplicate code, and added an abundant number of null checks in our Fragments’ methods. To clean up our code we created a ViewBindingHolder class that takes care of the binding’s lifecycle and supplies some helper methods that keep the code in our fragments safe and short.

The advantage of this approach

• enables safe access to the binding property.
• makes code short and clean.
• nullifies the binding at the end of the lifecycle.

Usage

Using the ViewBindingHolder requires two adjustments to the Fragment:

1. ViewBindingHolder<YourBindingClass> by… to initialize the ViewBindingHolder class as a delegate to your Fragment.
2. initBinding in onCreateView to bind the view.

Outside of onCreateView, there are two ways to access the binding:

1. binding?

Assuming that the binding might be null is the safest option. Since we’re using a delegate you can access the binding property directly from your Fragment.

binding?.textTitle.text = “The safest way to access”

2. requireBinding()

When you are sure your logic runs within the view lifecycle of the fragment, you can use requireBinding().

fun initTitle() = requireBinding() {
    // here, 'this' is the 'binding' property.    
    textTitle.text = "ViewBinding and Lifecycle handling"
}

You can also use it without a code block:

fun initTitle() {
    val binding = requireBinding()
    binding.textTitle.text = "ViewBinding and Lifecycle handling"
}

When requireBinding() is called outside of the Fragment’s view lifecycle, it will throw an IllegalStateException, similar to the behaviour of requireActivity().

Inside ViewBindingHolder

This is the class that makes it possible, I added some comments to explain the details.

To use it, copy the ViewBindingHolder class to some central place inside your project. Let me know if you find any room for improvement!

ViewBinding in Fragments: the clean & easy way was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

When your app contains a dynamic feature module (downloaded and installed on demand) and regular feature modules, setting up the DI graph poses some limitations.

The dependency of dynamic features is reversed. The module knows about App, but App ‘hardly’ knows the dynamic feature and cannot access its classes. In the App’s build file this distinction shows as:

android { ...
    dynamicFeatures = [":my_dynamic_feature"]
}

dependencies { ...
    implementation project(':core')
}

As you can see in the graph, Core and Regular Feature module do not reference the App module. This enforces separation of concerns. However, this is not possible for the dynamic feature module: it must hard-reference App as a dependency.

The problem

The main problem is that the DI root in App cannot access Dynamic Feature. Or in other words: the dagger-android tree cannot be constructed because it hard-codes the Subcomponents from the ContributesAndroidInjector annotated classes. It generates this code at compile time and to do so, it needs references to the components and modules it is connecting.

Towards the solution

One could try to inject components using dagger-android and this solution, but it involves reflection. Dagger’s Subcomponents are always declared top-down and are therefore unsuited. Dagger’s regular Components are connected more loosely and ‘sideways’.

The Plaid app uses this setup using Components. In a diagram it looks like this:

Plaid uses only dynamic features. When mixing the solution with regular feature modules, the solution will not work well because all modules need to know App in this setup. It would result in circular dependencies:

The solution

After setting up the dependent Components approach, we move the DI to the Core module, then the app dependencies will become clean:

The root of the DI graph is not constructed in App, but in Core, using dependent Components to make sure Core does not need to know the other Components in the graph.

Implementation details

The Core module contains the DI’s core Component:

@Component(modules = [...])
interface CoreComponent {

The other components, of the feature modules, all reference this CoreComponent:

@Component(
    dependencies = [CoreComponent::class],
    modules = [...]
)
interface DynamicFeatureComponent {

The Core module has an interface class that any Application using it should implement:

interface CoreComponentProvider {
    fun provideCoreComponent(): CoreComponent
}

The App module constructs the CoreComponent’s object:

class MainApplication : Application(), CoreComponentProvider {

    lateinit var coreComponent: CoreComponent

    override fun onCreate() {
        super.onCreate()

        coreComponent = DaggerCoreComponent
            .builder()
            .contextModule(AppContextModule(this))
            .build()
    }

    override fun provideCoreComponent() = coreComponent
}

Each module uses this CoreComponent and adds its own Components. For example in a feature module’s Fragment:

override fun onAttach(context: Context?) {
    super.onAttach(context)

    DynamicFeatureComponent
        .builder()
        .coreComponent(requireActivity().coreComponent())
        .dynamicFeatureModule(DynamicFeatureModule(this))
        .build()
        .inject(this)
}

DynamicFeatureModule is just a regular module, AppContextModule provides the context:

@Module
class AppContextModule(val application: Application) {

    @Singleton
    @Provides
    fun provideContext(): Context = application
}

And coreComponent() is an extension function:

fun Activity.coreComponent() = (applicationContext as? CoreComponentProvider)?.provideCoreComponent()
        ?: throw IllegalStateException("CoreComponentProvider not implemented: $applicationContext")

Note that linked components should have distinct scopes.

Also note that you need to define the classes that CoreComponent provides explicitly in provision methods, otherwise they will not be shared with linked components:

...
interface CoreComponent {

    fun context(): Context
    fun firebaseFirestore(): FirebaseFirestore
    ...

That’s all. An example project:

Frank1234/DynamicDaggerTest

After writing this article I noticed that handling Dynamic Feature Modules is very close to Instant App handling. A lot has been written on this subject. An interesting read would be:

Dagger2 for Modular Architecture

The React Native library for Android is currently not well setup for Espresso testing. Here are the steps to get it done nonetheless. Some of these also apply to Appium.

TL;DR 1. Add testIDs in React Native. 2. Run the layout inspector to check mappings. 3. Wait for RN views to become visible in the tests. 4. Test.

Add testIDs in React Native

To find an RN view from Android, add ContentDescriptions to the RN views on debug builds. This has one drawback: the code in test builds is slightly different from release builds. However, adding a ContentDescription on release builds would make screen readers go crazy; we stick to injecting on debug.

Add a testUtils.js file to the RN project, to inject ContentDescriptions. The same method also facilitates the iOS app, where actual testIDs are used:

On view creation, RN’s accessabilityLabel is mapped to a ContentDescription in Android. We add accessible:true to also apply it to views that normally don’t use ContentDescriptions, e.g. TextViews and Buttons. To make sure multiple views do not use the same id, centralise them in the Android project:

object RNTestIds {

    val myAwesomeListViewId = "myAwesomeListViewId"
    val myAwesomeProgressBarId = ...
}

This file can go into src/androidTest/ so that it will only be included in instrumented test builds. Now let’s add the same IDs in React Native. In your RN component, import the testUtils file that we created earlier:

import setTestID from '../../utils/testUtils';

When you render your view in RN, add the testID, e.g.:

<myAwesomeListViewId
        {...setTestID("myAwesomeListViewId")}
        etc.>

As said before, this will result in an Android view with ContentDescription="myAwesomeListViewId" on debug builds, this id can be used to get hold of the views using Espresso.

Waiting for RN views

Rendering RN views is done async; RN uses a Javascript thread and bridge. Therefore, the tests will have to wait on RN views to become visible. We could build a custom Idling Resources implementation that takes into account the JS thread and bridge. An easier approach is to use a function that waits on a view to come into existence and be displayed. In the Android project, create an EspressoViewFinder file:

The most important function here is waitForDisplayed, which waits for a view to become visible to the user before doing a callback. Example usage in a test:

@Test
fun startUp_showsProgress() {
    waitForDisplayed(withContentDescription(RNTestIds.progressBar)){
        progressBar ->
            onView(progressBar).check(matches(isDisplayed()))
    }
}

Voila, you created your first Espresso to React Native test! Let’s now create another, slightly more complex one.

Mapping the Layout Inspector

When building tests, use Android Studio’s Layout Inspector to see what a React Native view is actually mapped to in Android’s native environment. For example, a RN SectionList maps to a native ReactScrollView (that extends Android’s ScrollView) containing a ViewGroup . This ViewGroup contains all child elements, but the ReactScrollView has our ContentDescription set on it:

So, when checking wether a SectionList contains content, we will have to check the childCount of the ViewGroup inside the ScrollView:

waitForDisplayed(
     withContentDescription(RNTestIds.myAwesomeListViewId)) { 
        scrollViewMatcher ->

     waitForDisplayed(childAtIndex(scrollViewMatcher, 0)) {
        scrollContentMatcher ->

        val scrollContentInteraction = onView(scrollContentMatcher)
        val baseCount = 2 // header and footer of the scrollView

        scrollContentInteraction.check(matches(isDisplayed()))
        scrollContentInteraction.check(matches(
            hasChildCount(baseCount + expectedItemCount)))
     }
  }

The childAtIndex and waitForDisplayed methods are in the EspressoViewFinder we created earlier. Note that the callbacks (the higher-order Kotlin functions) in waitForDisplayed are not mandatory. You can also omit them:

waitForDisplayed(withContentDescription(
    RNTestIds.myAwesomeListViewId))

// any code you add here only runs once the view is displayed

Next Steps

This article was written to give you a head start on UI testing React Native views in Android, but you will probably encounter more obstacles along the way. If so, do not add unconditional delays in the tests; it will slow them down and make them unreliable. Build proper solutions, and please share them with us.

Happy testing!

Espresso testing React Native was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some assignments for filling knowledge gaps. And for your pleasure.

This is a list of questions that was given to one of our Junior Developers, Heinrich Wesson. First part: Knowledge boost for junior Android developers — Part I. The result is a collection of handy skills and information.

1. Annotations

Mention a few useful annotations in Android that we are not using in our code yet.

@RestrictTo(RestrictTo.Scope.SUBCLASSES): Where the protected modifier makes the method accessible to all classes in the same package, this annotation can be used to make an element accessible to its subclasses only.

@CheckResult: Used on a method, this will cause the compiler to show a warning when the method is called and the returned value is not checked or used, usually meaning that the developer misunderstood what the method does.

2. Java 8 Streams

What are Java (8) streams? When should we use it?

A Stream is a code abstraction added in Java 8. It is a pipeline of operations that can be performed on a data source, usually on Collections. It continues to provide concise and readable code when many different transformations are done. A short overview of Java streams in this Cheat Sheet.

myList
    .stream()
    .filter(s -> s.startsWith("c"))
    .map(String::toUpperCase)
    .sorted()
    .forEach(System.out::println);

The above would be a long list of for loops in imperative code. However, speed improvements are not guaranteed using Streams. It is a debated subject. Especially the use of Parallel Streams may harm performance. I would suggest the use of Streams only when it would be really difficult for future developers to understand the imperative code.

3. Testing

What types of testing are available on android? Describe some of them shortly.

• Unit Tests: Automated testing of code-units by calling for example methods with varying values. Often the response and results are checked, sometimes also the inner workings are spied upon. Frameworks as Mockito and Robolectric ease implementing Unit Tests on Android.
• Instrumented Tests. Put your UI to the test on a device or emulator using these tests. You can test many small pieces of your code and also run broader screen and navigation tests. See: Espresso-testing.
• Monkey Tests. Used for stress-testing; a monkey slamming your phone.
• StrictMode. Notifies you when you created Google policy breaking code.
• Firebase Test Lab is Google’s collection of testing tools. Includes automated, general ui testing (Robo Tests, no coding needed) and instrumentation tests on real devices. Reports back with performance metrics, screenshots and video’s.
• LeakCanary. Guards your app from the most blatant memory leaks.
• Google’s Test Procedures. A checklist for manual testing.

4. Generics

What are Generics? Show a good use case for it.

Generics enables the use of types as parameters using angle brackets (<>). Before generics were introduced, developers had to more often cast elements, easily causing ClassCastExceptions. This can be avoided using generics.

List<String> myList = new ArrayList<>();

When using this list, you won’t have to worry that there is anything other than String objects in it. In the entity implementing the type a generic is generally denoted by a T or other single letter:

public class ArrayList<T> extends …

During your code’s compilation, all these generics are replaced with their respective type erasure. Wildcards can be used for type parameters when the type is unknown: <?>, bounded: <? extends Number> or inferred: <? super Integer>. More info about Generics and More Fun with Wildcards.

5. Pair Programming

Explain Pair Programming. Do you think we should try it?

In pair programming, two developers work on one work station. One developer plays the role of the driver, writing the code, and the other person, the observer, reviews the code constantly as it gets written. The two developers switch these roles frequently. (source: Wikipedia)

Pair programming is an agile software development technique. In my opinion, doing stand-ups to discuss problems, code reviews and building a large automated test coverage serves the same purpose in a more efficient way. Also, I am afraid I will fall asleep watching my colleague code. It never hurts to try though, let’s pick a date for it!

Some tips here: Effective pair programming. For the enthusiasts there is also Mob Programming.

6. Support Libraries

What is the difference between support library v4, v7 and v13? When would you use v13 instead of v7?

The difference is no longer the minimum API version:

Starting with Support Library version 26.0.0 (July 2017), the minimum supported API level has changed to Android 4.0 (API level 14) for all support library packages. (source: Google Docs)

• v13 features have been merged into v4
• v7 packages depend on v4

So in general, referencing v7 is all you need. Unless you want to exclude packages and you do not use anything from v7, then you could reference v4 libraries. Using the support library is also recommended when you target late Android versions; It adds extra features like RecyclerView and CardView. Furthermore, the support library is constantly updated and improved, where Android versions are rather static.

Some semi-recent investigations into the support lib here and here.

7. Reflection

What is reflection and why should you usually not use it?

Reflection enables developers to inspect packages and APIs, for example to see if a specific class or method is available at runtime. One can also access and change private field’s values using reflection.

Method method = classInstance.getMethod(methodNameStr, View.class);
retValue = handler.invoke(method, view);

Drawbacks to using it includes:

• Significant performance overhead.
• Solutions based on reflection are often fragile. If you are accessing private members and the underlying API changes it might lead to unexpected problems inside your app.

8. Browsing Dependencies

How does one browse a project’s dependency libraries’ packages in Android Studio?

Click on the arrows in the panel of your Project View and select Project. The Project view will now have an External Libraries section where all dependency libraries can be browsed.

9. Anonymous Classes

What is an anonymous class? Show a good use case.

Anonymous classes enable you to declare and instantiate a class at the same time, inline. It often increases code readability, for example when using listeners or callbacks:

myButton.setOnClickListener(
    new View.OnClickListener() {
        public void onClick(View v) {
            addNewItem();
        }
    });

It becomes more readable using a lambda, same code as above:

myButton.setOnClickListener(v -> addNewItem());

Or even shorter, but maybe less readable:

myButton.setOnClickListener(this::addNewItem);

A warning: inner classes keep a reference to their outer class. This can in certain implementations lead to a memory leak. More info here and here.

10. MVP

There are many flavors of the Model-view-presenter architecture. Note a few things to keep in mind when deciding on one.

1. Will our presenter persist through orientation change or will it be reconstructed? Both have their benefits; Pros and cons.
2. Will we inject presenters and views using Dagger 2? Using Dagger 2 makes the code more complex to set up, but easier to test. Example.
3. Will we use an abstraction layer (Interface) from View to Presenter as well, or just from Presenter to View? Example of a two-way Contract.
4. Will we use data binding and mix MVP with MVVM? As done here.
5. Will we allow the presenter to know of / access the Context? (Preferably not: it makes testing more difficult.) Some tips here.
6. Will we use an abstraction layer (Interactors) from the Presenter to the data part of the app? Example of Interactor usage.
7. Will we use RXJava and have our presenter subscribe to observables? Just as Dagger 2, RXJava might take some time to get used to, but it is a very powerful tool.

A great collection of MVP flavors and architecture examples can be found in Android Architecture Blueprints.

Happy coding!

Knowledge boost for junior Android developers — Part II was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some assignments for filling knowledge gaps. And for your pleasure.

This list of questions was given to one of our Junior Developers — Heinrich Wesson — as a last exercise before becoming an Intermediate Developer. It contains information I wish I, when I started, would have known earlier and some things to avoid that I learned the hard way. This is the first half of the results, a collection of handy skills and information.

This is a series of two articles, the second part can be found here.

1. Private Storage

How do you browse the private storage of an app? Explain the contents.

On any emulator, use the DDMS File Explorer and navigate to data/data/com.mycompany.myapp. As an alternative, you can copy the app’s private directory to a local folder using: adb pull /data/data/com.mycompany.myapp/. Android Studio 3+ will contain a Device File Explorer.

The private storage has a cache folder with temporary files, a files folder containing more persistent content of the app and a shared_prefs folder containing saved preferences. On a real, unrooted device browsing an apps private storage is not possible.

2. Mapping

What is a mapping file and why is it important?

When using ProGuard to obfuscate a (signed) APK’s code, a mapping file is generated which provides a translation between the original and the obfuscated code. We keep this file to be able to de-obfuscate crash reports’ stack traces. The crash reporting system (Fabric, Firebase, etc.) does this translation for us, if we provide it with the mapping file.

3. Forbidden Singletons

What is a Singleton? Why are you not allowed to implement this pattern?

A Singleton Pattern restricts the instantiation of a class to one object, using a static reference to it. Singletons seem easy to use because they can be accessed from everywhere. However, they can cause major problems e.g.:

• When multithreading, Singletons can change state from any thread. This may lead to unexpected behaviour.
• Singletons can leak your context.

A great many more drawbacks are mentioned in Singletons in Android. In short: don’t create them, there is always a better solution. Note that not all developers agree with me on this, see for example these opinions.

4. Browsing Preferences

What is an easy way to browse your app’s current (shared) preference values?

Use Stetho with Chrome DevTools (chrome://inspect) and go to Local Storage > myApp_preferences.

You can also browse your app’s private directory and look at the contents of the preference file.

5. JRebel

Explain JRebel 2.0 in one sentence. Should we use it? Why? What are the downsides?

JRebel is an IDE plugin that improves Android build times using code- and resource-swapping. It is similar to what Instant Run tries to achieve, but with support for more types of code changes.

I tried it with one of our projects. On small changes in code and xml the build time went down from 13 seconds to 1 second. Procedure of installing it on the emulator went down to 2 seconds. However, almost all of this was lost when the (expensive) Enterprise Edition expired.

6. “Don’t Keep Activities” settings

What is the “Don’t Keep Activities” developer setting and why is it useful?

When the developer option Don’t Keep Activities is checked on the device, all activities that are stopped will be destroyed as well. This simulates the OS’ behaviour when your app is in the background and the system is short on memory; it will destroy your activities.

The setting is useful for testing saved (instance) states and detecting memory leaks.

7. MVP and MVVM

Give two reasons why we should switch from MVP to MVVM and two reasons why we should not.

Pros of MVVM:

1. Removes boilerplate code in the presenter — e.g. simple view state changes can be set in xml.
2. Lessens the use of findViewById, onClick forwarding, etc. resulting in even cleaner Fragment code.

Cons of MVVM:

1. MVVM is more complex than MVP — e.g. the use of ObservableFields, BaseObservable and BindingAdapters will be more difficult to grasp for junior developers. In MVP you’re basically only moving familiar code around to provide more structure to app architecture.
2. The code can become messy. Parts of the code might end up in XML, thus complicating testing, development and debugging. You might end up with a forest of (global) BindingAdapters and incomprehensible methods for bound animations, etc.
3. Compared to MVVM, more classes are easily testable in most MVP variants because these have no (or less) Android specific dependencies.

8. Parcelables

What is a Parcelable? When would you use it?

Parcelables are used to pass around POJO’s across process boundaries. This can be done between activities, services, fragments, etc. Parcelables can also be contained in savedInstanceState Bundles, e.g. to restore an object on orientation change. We prefer Parcelables over Serializables because of performance reasons; Parcelables do not use reflection.

One can use the Parceler Library to write a single annotation per Parcelable, evading boiler plate code.

9. Gerrit

Explain Gerrit. Do you think we should start using it?

Gerrit is a code review tool. Each push needs to be reviewed before it can be pushed onto the “main” branch. Main pros of extensive code reviewing:

1. Sharing of knowledge between developers.
2. Improved software quality.

For a small development team this is quite a heavyweight solution. In my opinion: some, but not all pushes need reviewing. Because we are a small team of developers, I do not think we need to use this.

10. Retained Memory and GC

Open our latest app and change your device’s orientation a few times. Now find out how many Fragment and Activity objects there are in memory.

After orientation change, selecting Dump Java Heap in the Memory Monitor in Android Studio yields multiple Activity and Fragment objects for the app. However, only one of them occupies actual (dominating) memory.

If I now select Initiate GC to run garbage collection, some of the dead objects are removed. On the second garbage collection all dead objects are removed. LeakCanary does not report any problems.

11. Google App Indexing

Explain the concept. Are there any real live examples where it greatly improved app installs? And app user retainment?

“You can enable Google to crawl through your app content and present your Android app as a destination to users through Google Search results, when that content corresponds to a web page that you own.” — Google docs

Basically it boils down to this:

So for every app page reference you will also need a web page. I found mixed results on if it is worth the effort, see this case study. Also, it seems that Google prefers Accelerated Mobile Pages (AMP) over app indexes. Furthermore, I have a feeling Instant Apps might replace the app indexing eventually.

There is nothing negative about app indexing if your company has to resources to implement it but the effort might not match the gain.

12. Context vs ApplicationContext

What is the difference between getContext() and getApplicationContext()? When would you use the second? And when not?

The Application Context has the same (long running) lifecycle as the whole application process. getContext() will return the (shorter lived) context of the current activity.

Usage of the normal getContext() can cause temporary memory leaks when used in async methods or tasks. When you change orientation, a new activity is created but the old context (activity) can only be garbage collected after the async method or task finished. Therefore, use the Application Context when you wish to outlive the Activity in long running operations. For example, the Google Dev Guide states the use of the application context explicitly on toast messages, probably because they may outlive the activity. More info on Context capabilities: Context, What Context?.

In general, it is best to use getApplicationContext() anywhere you can. Only starting an Activity, opening a dialog and inflating layouts cannot be done with the Application Context.

13. Lifecycle Detail

Why is cleaning up your app (releasing listeners, saving data, etc.) in onDestroy() not a good idea?

onDestroy() is not guaranteed to be called, see the documentation on onDestroy. Therefore, it is good practice to do most of the cleanup in onStop(). Also, because your app will use less memory when in the background the chances are smaller that the OS will kill the app process. Saving data in lifecycle methods is never a good idea. It might slow down orientation change, closing of the app, etc.

Coming up…

The second half of the assignments will follow in the next article, touching Reflection, Generic Types, the mysteries surrounding the Support Library, Java 8 Streams, Automated Testing and more. Part two can be found here.

Knowledge boost for junior Android developers — Part I was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

You have many options to reduce networking usage of your Android app. Low-hanging fruit is the use of If-Modified-Since or Etags headers. It’s already included in OkHttp3, you will just have to enable it.

Imagine your app’s friends list being updated on a website, how do you get the changes to your app, without fetching the list of friends on every app start? You could implement custom logic, or you could enable caching.

To fast forward to the client implementation, scroll to Picking the fruit: Client implementation.

If-Modified-Since and Last-Modified

Using a If-Modified-Since and Last-Modified header combination will enable your server to return a 304 NOT MODIFIED status if there have been no changes after the client’s last request. Because this response does not contain a content body, it is just a few bytes in size.

How it works: The Last-Modified header is set by the server on its response, it is the last-edit-date of the resource that the client is requesting. Let’s say the client requests a list of articles, the Last-Modified header on the response will be the last-edit-date of the most recently edited article in the list.

The Last-Modified response header from the server is used by the client on the next equivalent call as an If-Modified-Since request header. The server checks if any of the requested items changed after the If-Modified-Since date. If not, it will return a 304 NOT MODIFIED status. If there are changes, it will fetch and return the complete result. Depending on how the backend developer implemented this, it might be faster than using an Etag.

Etag and If-None-Match

An Etag functions in a similar way. Etags are less error-prone to implement but require the server to run a complete query and create a hash every time.

How it works: Your backend developer will, before sending a response, create a hash of the response content and details (e.g. using SHA1) and add this as an Etag header. The client will, on a future equivalent request, send this Etag to the server as an If-None-Match header. The server will, after preparing the response, compare its new response hash with the Etag on the request. If it’s the same then the server will return a 304 NOT MODIFIED status without content. If it does not match, then the server will respond regularly, with the new Etag as a header.

Picking the fruit: Client implementation

If you use Retrofit2, enabling Last-Modified or Etags on client side is straightforward, it is just not well documented. Where you create your Retrofit instance, turn on caching:

private final static int CACHE_SIZE_BYTES = 1024 * 1024 * 2;

public static Retrofit getAdapter(Context context, String baseUrl) {

    OkHttpClient.Builder builder = new OkHttpClient().newBuilder();

    builder.cache(
        new Cache(context.getCacheDir(), CACHE_SIZE_BYTES));

    OkHttpClient client = builder.build();

    Retrofit.Builder retrofitBuilder = new Retrofit.Builder();
    retrofitBuilder.baseUrl(baseUrl).client(client);

    return retrofitBuilder.build();
}

The Last-Modified headers or Etags will be automatically used depending on the servers responses. In addition you will want to reduce processing/parsing time:

Reduce processing

On a 304 status, Retrofit2 and OkHttp3 will pretend this response was equal to the last response; the cached response is returned. To notice the 304, check the raw response code:

if (response.isSuccessful() &&
    response.raw().networkResponse() != null &&
    response.raw().networkResponse().code() ==
           HttpURLConnection.HTTP_NOT_MODIFIED) {

    // not modified, no need to do anything.
    return;
}

// parse response here

Getting the normal (not raw) response code would give you the cached status code, probably 200 OK:

response.networkResponse().code() // NO

In some cases you might not need to check on HTTP_NOT_MODIFIED. For example, you might want to re-parse the response when you want to show something directly from the network, even though it has not changed.

Troubleshooting

When your Etag or Last-Modified setup is not functioning:

1. Check your Cache-Control headers

Use Stetho or an OkHttp logging interceptor to check your headers. If it shows something like:

Cache-Control: must-revalidate, no-cache, no-store, private // NO

then the server’s cache configuration is incorrect. Cache must be enabled for OkHttp3 caching to work. A correct header would be:

Cache-Control: private, must-revalidate // YES

Using Stetho or a logging interceptor* will also allow you to see the Last-Modified and Etag headers on all your requests and responses. Double check if they are present and correct.

* depending on the interceptor and its position in the list of interceptors, you might not able to see the If-Modified-Since header in your logs when the header is added after your log statements. If so, checking with Charles Proxy will always show you the correct headers.

2. Using both Etags and Last-Modified

OkHttp3 will check the cache headers in this strict order:

1. If the last response contained an ETag header, the same ETag value is used in the next request as If-None-Match.
2. If point 1 is false and the last response contained a Last-Modified header, then this value is used in the next request as If-Modified-Since.

So if you use both, the Etag might block your Last-Modified usage. More info here: What’s under the hood of the OkHttp’s cache?

Minor effort

I have seen developers trying to set and save If-Modified-Since and If-None-Match headers manually. There is no need for this if you use Retrofit2 and/or OkHttp3.

Setting up correct cache configurations on client and server side is all you need to do in order to lower the network footprint of your app.

Reducing your networking footprint with OkHttp, Etags and If-Modified-Since was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.