Through the binary

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.

Previously, we talked about how to share code across platforms in kotlin world. But as your code base grows, you will encounter a scenario where you might want decouple the code. Things like separating the platform specific implementation to another repo in order to reuse them in a future project. Well, lucky you, this is our topic today.

When you add a new activity in Android Studio. It will have a default back button at the upper left corner. How to remove it? I check many things online but they are not working. So, let’s remove it by ourselves!

When you try to deal with the across platform codes. You need to solve 2 things, one is the architecture of how to share the code, another one is how you share. Well, different languages might have different techniques. But in Kotlin, you can use multiplatform projects to share the code. And via kotlin native, you can even expand the support to iOS and Android, I mean, natively.

An example of supporting code sharing among iOS, Android, JVM and JS is added in this repo.