a full stack enthusiast interested in Javascript / Typescript / Kotlin / Python / React / React Native / (Android & iOS) native / Cloud

Previously, we talked about how to do mock using dagger 2 and dagger-android. But as the wise man said: If You Didn't Test It, It Doesn't Work. So let’s see how to do the test. An important part of doing the UI test is mock, we don’t really want to deal with network request even it allows us to. Today, I share the knowledge of how to mock the injections from dagger-android in the UI test (instrumented tests). I write this because most of the online tutorials are using dagger-android in a dagger 2 way which leads to more code, or even worse, some mixed up usage will make people even more confused. Even though confuse is a word that tends to be bound with dagger. :D Oh, well, it’s a bad joke.

Permission handling should be simple, but not the case in Android. Or at least before you know a lot about it. This article aims to solve that problem. And we will use Anko here to make it better.

When I say dynamic UI I mean the UI you generated from a library like Anko or just plain Android API.

In previous blog, we used plain dagger to do the dependency injection on Android, but there is another package from Google named dagger-android, and it’s tailed for Android. Things get more interesting here. Let’s see.

Here is another blog for mocking dagger in Espresso test if you need it.

DI is a pattern to decouple your code. You don’t need to have a DI framework to handle the injection, but using such will make your application better. Things like singleton and initialization. Let’s see how to do that in Android using Dagger. Even you don’t what DI is, we will go through it pretty fast and clear. We will use Kotlin, plain Dagger and Android Studio here.

ActionBar is good for UE, but sometimes we do want to hide it. Here we will see the ways to do it.

With the new android.arch.lifecycle.ViewModel, you can extend your own ViewModel which is life cycle aware. Or you can use AndroidViewModel if you want to inject context to your model. One problem with the default ViewModel is the constructor takes zero parameters. If you want to make it takes parameters, you need to make a new FactoryClass for each view model. But with Kotlin, it could be more simple. Let’s see how to do it.

Databinding for MVVM or any other pattern is a must have. Let’s see how to set it up. The reason for this blog is that it seems most of the examples out there online either deprecated or just try to solve another problem. Our goal is to setup a project with a brand new project generated from Android Studio.

I encountered a weird thing today. In Android Studio 3.1.1, import android.arch.lifecycle.ViewModelProvider is totally fine while import android.arch.lifecycle.ViewModelProviders is not fine. Because there is no ViewModelProviders under lifecycle package.

The solution is to add the packages by yourself. It doesn’t even get mentioned in the official doc and most of the tutorials online. And after working with some already setup project. It finally bites me.

Mock is the answer to this kind of case when you need to deal with the IO thing like network request. Such that, you can test your logic without worrying about the underneath implementation. But sometimes it’s not the case. Integration test is the answer.