When writing an Android application there comes a time, where you need to pick libraries. You always have in mind that these libraries should be scaleable, will help you achieve your goal and make your developer experience easier. That’s why we pick libraries that all big companies have in their toolset and have proved to work perfectly.

Such decisions I had to take when I scaffolded the Workable Android app. One of the libraries I chose was Dagger. Dagger is a dependency injection framework that generates the dependencies at compile time. Well.. Guess what.

Dagger didn’t work well for us.

Dagger is stable and powerful and I can’t argue on that. One problem is that it is too complex, both the examples and the documentation and requires a lot of boilerplate code. I can’t remember how many times I looked over the Thermosiphon example in order to understand what exactly is happening. But complexity wasn’t the reason that Dagger didn’t work well for us despite it being a significant reason.

The biggest and most annoying problem, was the accompanied code generation by (k)apt. In our app, we also use Databinding heavily which is also based on code generation (note that for later). There was a moment when I needed to change the configuration of Dagger. After finishing with the changes and hitting compile, there were over 100 errors flooding the console. There wasn’t a clear indication what went wrong.

After a lot of continuous changes, retries and refactors over the already refactored configuration, I opened this issue on Dagger because I couldn’t reproduce it on small projects. After a couple of days of debugging with a colleague, we found that the annotation processors of Dagger and Databinding were messing around and when one failed, it caused the other processor to fail as well. As a result, I had several errors that I didn’t know how they were produced. Several days ahead struggling with the issue, we discovered that javac outputs only the first 100 errors, by default. That meant that our actual error was hidden somewhere above those 100 errors. After increasing the max errors javac produces, I found the “hidden” error and didn’t touch the Dagger setup again for 2 years, fearing similar situations.

Another issue our team faced with Dagger and probably the biggest one, was compile times. When your codebase is growing, compile times are increasing along with it. Our build takes on average 5–7mins and the incremental one is ~2.00–2.30mins. This is because kapt was breaking incremental compilation resulting in a full rebuild. Even tests are taking a long time to compile. Things can go sideways if you also add another library with code generation. Our team decided that this isn’t a “healthy” development environment to be working on and had to do something to make our build more reliable.

What did we do?

We ditched Dagger.

We decided to replace it with Koin and couldn’t be more happy with that. Koin provides almost the same feature set as Dagger without a proxy, code generation, or reflection. It has scopes, multibindings and it is much easier to understand. Also, the documentation and examples are way more simple and straightforward. There is a tiny overhead at runtime, because it creates the dependency graph, but the cost is negligible.

Its easy and fluent API, saved us a lot of time with the migration. We started the migration by rebuilding the dependency graph exactly the way it is build with Dagger but in a Koinish way. In the meantime, we retained the dependency of Dagger in our project. Each time, we created a new module, we ran in a Unit-test the dryRun function that Koin provides. This function goes through all your modules and checks if the dependency graph is set up correctly. In addition, this helpful function, guarantees us that we will not break at runtime when we are pulling dependencies.

Once we finished the dependency graph, it was time to replace Dagger’s inject call sites with Koin ones. This was a piece of cake, since Koin offers custom delegated properties to inject dependencies. The final result looked like this:

What we did on tests, was to replace modules or some parts of them with fake ones. For example, if we want to mock the above Storage, we just replaced the module with the mocked one.

One of the powerful features of Koin is the ability to declare scopes. At Workable, we have a feature that allows a user to be logged-in in multiple accounts. This functionality is backed up by a specific module. When the user switches account, we release that module and let the user-scoped module/graph pull a new instance.

But what happened with Java files? Koin also works with Java. You can see more in the official documentation. You can also find several techniques on this Github issue.

Once finished replacing all the call sites, we deleted every Dagger class annotated with Module, Component etc, resulting in 93 additions and 1803 deletions. Quite a lot huh?

After doing that, we also saw several seconds down on compile time. This is because we removed some heavy work from kapt. Here is a sample benchmark :

| Modules \ Compile time | Dagger  | Koin
|------------------------|---------|---------|
| :app                   | 41.610s | 28.374s |
| :module1               | 26.563s | 19.745s |
| :module2               | 14.345s | 11.325s |
| :module3               | 7.241s  | 3.950s  |
| :module4               | 22.828s | 5.866s  |
| :module5               | 4.976s  | 2.505s  |
| :module6               | 5.631s  | 4.684s  |
| :module7               | 1.988s  | 3.178s  |
| SUM                    | 125.15s | 79.59s  |
|------------------------|---------|---------|

Final thoughts

What I suggest you to do, is look what works best for your team. There are several dependency injection and service locators libraries out there. We decided to use Koin. But that is our choice. Maybe your choice is to create your own, which could also be a perfect solution, because it would be simpler to understand how it actually works, since it is written by you. What won us in Koin, was its simple DSL, non verbose configuration and the ability to declare scopes and multibindings.

I am not a big fan of code generation. While sometimes it makes life easier, others it drains a lot of energy from you. I don’t like the trend of a code generation tool for every single tiny problem/thing on Android but that’s my Preference(Context.MODE_PRIVATE) 😛.

At least, one could argue about the differences between dependency injection and service locator pattern. I dοn’t want to dwell on this. You can find long and contradictory articles on the definition of these things with ease. My point is to, see what suits best for your team. Just because big companies use a library, it doesn’t mean it will work for you. Evaluate it and then go for it.

Applications like Gmail or Google’s Keep support undo action.

“Traditional” app architectures, like MVC or MVP, support these actions but they don’t manage state elegantly. The main reason is that they have an implicit data flow, which means that you can possible end up in invalid states. In this article, we will see how you can avoid these states and define a state machine in your app.

What we really need is to represent state in such a way that will be trackable, immutable and serializable. This state should be our source of truth for the UI at any certain point of time. Every user interaction should render a new different state. Every new state that is produced is our way to: go back, undo and generally reproduce history.

Architectures that enforce this pattern and eliminate the previously mentioned limitations of the “traditional” architectures, are MVI (Model-View-Intent), Redux and generally reactive architectures. For the sake of simplicity, I will analyze the MVI architecture.

Model-View-Intent

Model-View-Intent architecture might seem very strange at first glance! By referring to Intent we don’t mean Android’s Intent, rather than a user’s interaction with our UI. Model is an object that processes information and keeps our state. View is the representation of the UI and cannot be rendered if Model is not present.

This architecture is heavily based on streams. If you use RxJava, every intent should be expressed as an Observable stream of events. For example, when a user clicks a button, you need to “translate” this to an Observable. Lucky for you, there is RxBinding that handles all of these translations.

MVI enforces unidirectional data flow. In a few words, unidirectional data flow provides predictable application state. This means, that a change on the UI layer will trigger an action on the data layer and the changes, that might occur, will transform the UI. This does not necessarily mean that the view directly affects storages etc. In particular View behaves as a pure function in which the same Model has the same output on the UI, without any side effects. As a result, when a bug occurs on the app, you can pinpoint it easier because data follows a “sequence” and the views are loosely coupled from the app data.

Ok, but how can I reproduce history?

Let’s say we have an app that does one thing: let’s you search GitHub users. The viewmodel for this simple app has 3 predefined states: Loading, Error and Success. Whenever user searches, we render the predictable state of Loading. If user found on GitHub, we render the Success state, otherwise something went wrong and we end up with Error state.

On the sample project, I use a cache that saves all these viewmodels and by using a slider, you can “time travel” over them.

So, we have the following View:

interface MainScreenView {
  fun searchIntent(): Observable<String>
  fun historyIntent(): Observable<Int>

  fun render(viewModel: MainScreenViewModel)
  fun renderFromHistory(viewModel: MainScreenViewModel)
}

Nothing difficult here. The searchIntent() is the Observable stream that gives us emissions of the search terms. The historyIntent() is the Observable stream from the Seekbar’s progress, which “travels” us back to previous/next states.

Our Model is the following:

data class MainScreenViewModel(
    val searchTerm: String,
    val showLoading: Boolean,
    val showFields: Boolean,
    val showError: Boolean,
    val gitHubUser: GitHubUser? = null,
    val errorMessage: String? = null
) {

  val createdAt: Long = System.currentTimeMillis()

  companion object {
    fun inProgress(searchTerm: String): MainScreenViewModel =    MainScreenViewModel(searchTerm, true, false, false)

    fun success(searchTerm: String, gitHubUser: GitHubUser) =    MainScreenViewModel(searchTerm, false, true, false, gitHubUser)

    fun error(searchTerm: String): MainScreenViewModel = MainScreenViewModel(searchTerm, false, false, true, null,
    "Houston we have a problem")
  }
}

In our example, viewmodel is a data class because we want immutability! We actually don’t want someone else touching our state! The createdAt property exists in case we want to sort these viewmodels by time.

Finally, our Presenter is nothing special as well. I removed most of the lines, in order to focus on the most significant method: render(). Whenever the response is success, we map its result with the following factory method: success(it). Whenever the response is failure (mostly 404 Http status code- user not found), we use the error() factory method. Before that we emit an item that the request is in flight, using the inProgress() factory method. We save its state on dispatchRender(). The method doOnNext() is actually very helpful for side effects like logging, so we log our render events. Note: I could use the scan() operator, but I wanted to keep it simple.

class MainScreenPresenter {

...

  fun bindIntents() {
    val searchIntent = viewRef.get()?.searchIntent()?.share() ?: Observable.empty()

    searchIntent
        .debounce(400, MILLISECONDS, AndroidSchedulers.mainThread())
        .doOnNext { Log.d("Intent", "Received Search Intent") }
        .switchMap {
          gitHubApi.githubDAO
              .searchUser(it)
              .map { MainScreenViewModel.success(it) }
              .onErrorReturn { MainScreenViewModel.error() }
              .startWith(MainScreenViewModel.inProgress())
        }
        .doOnNext { Log.d("Render", it.toString()) }
        .observeOn(AndroidSchedulers.mainThread())
        .subscribeWith(object : DisposableObserver<MainScreenViewModel>() {

          override fun onNext(viewModel: MainScreenViewModel) {
            dispatchRender(viewModel)
          }

          override fun onError(e: Throwable) {
            Log.wtf("ragment", e.message)
          }

          override fun onComplete() {
          }

        })
        .addTo(compositeDisposable)
  }

private fun dispatchRender(viewModel: MainScreenViewModel) {
  ViewModelCache.append(viewModel)
  viewRef.get()?.render(viewModel)
}

...

}

The View’s implementation is like this:

progressbar.showOrHideInvisible(viewModel.showLoading)
userName.showOrHideInvisible(viewModel.showFields)
userLogin.showOrHideInvisible(viewModel.showFields)
gitHubUrl.showOrHideInvisible(viewModel.showFields)

userName.text = viewModel.gitHubUser?.name
userLogin.text = viewModel.gitHubUser?.login
gitHubUrl.text = viewModel.gitHubUser?.url

if (viewModel.showError) {
  Toast.makeText(this, viewModel.errorMessage, Toast.LENGTH_LONG).show()
}

Actually this is the only pain-point of this pattern. You somehow need to smartly and effectively invalidate Android’s views without worrying about how many layout passes our ViewGroup has executed. In an upcoming Medium post we will discuss on how to fix these issues.

Actually that’s all! You see? Nothing too hard. The result of the above looks like this:

Debugging and testing with these reactive architectures seems to me very straightforward. By using Kotlin’s data classes or Google’s AutoValue or even your own custom implementation, you can compare these states and due to the fact that state must be immutable, you know that no one is going to change it! Also this is your single source of truth.

So, the only thing you have to emulate in unit tests are Intents. You can achieve this by mocking them with PublishSubjects. Now you can use those to “fake” user interactions and then just assert the output of your equivalent render method. Unidirectional data flow and pure functions help you a lot on this field.

As a bonus, you can have a stack of the last n rendered viewmodels. This is going to help you when reporting bugs e.g. on your Crashlytics, Bugsnag etc platform. It’s like a time travel. By feeding these last n viewmodels on the render() method you can see what led to your app crashing. That’s because you know the n-1 viewmodel and what is really going on the screen. Do you remember the doOnNext method? You can always add more info on your Observable streams, for example an Intent for infinite scroll or pull to refresh.

In more complicated apps, you can make your app’s logic look very simple. By plug-and-playing with Observable streams and with all these various Rx operators, you have the ability to achieve the most extreme scenarios. That’s very convenient because you can almost see all of the edge cases that can happen and fix them before you release your app in production. Moreover, your data flow becomes explicit. That’s because you know the exact state your screen is currently in and how a user’s action will affect its current state.

Redux works somehow on the same style. Redux introduces Reducers, Actions, Dispatchers and Store. In a nutshell, Reducers work as pure functions from previous state to the new one, Actions are what a user has done(pretty much like our Intents), Dispatchers are like an event bus for all those Actions and Store manages the state and acts like an orchestrator. Finally, there are Middlewares which let you extend Store with some additional functionality, (e.g. like what we did on doOnNext() with logging)

You can find the sample GitHub project here.

Thanks to Pavlos-Petros Tournaris, Kostas Kremizas and Stratos Pavlakis for providing me feedback for this article.