What are keyboard layers?

When you press the A key of your keyboard you see an ‘a’ appear on your text editor. However, if you hold one of the Shift keys and the press A, what you get is a capital ‘A’. If you hold Shift and press 2, you see ‘@’ instead.

What I have just described is the behavior of the Shift Layer. In essence, the Shift key activates a layer that changes the output of many other keys.

What is a modifier?

Shift, Control and Alt are referred to as modifier keys. This is simply because they modify the behavior of other keys. That not always means emitting a different character, as in the previous example. It can also result in a action taking place. For example, holding Control and the pressing C will commonly copy the selected text; holding Alt and then pressing Tab will allow you to change the focus to another application.

What are home row modifiers?

The row at the center of a keyboard, where your fingers are meant to rest, is commonly called a Home Row. Of course, there are no modifiers on the Home Row row of a standard keyboard, all we see are characters. We cannot replace them with modifiers because we need all characters to be able to type.

But what if we could have both? After all, there is a clear difference between how we use modifier and a character keys: we hold the former and tap the latter. For example, when we tap D, we get a ‘d’, but if we held D, then tapped M and got capital ‘M’, that would mean D behaves as Shift while held.

Why would we want to do this?

Having quick access to modifiers and being able to press a combination of them without having to contort our hands in an awkward way can result in improved efficiency and ergonomics, also encouraging us to learn more shortcuts and key combinations that can increase our productivity.

How can we achieve this?

There are many tools that can modify the behavior of a key to achieve this to some extent. However, there are a few important gotchas to bear in mind:

• If you are typing and roll a key, meaning that you press a key before releasing the previous one, you may accidentally activate a modifies (e.g., roll from D to M and get ‘aMire’ instead of ‘admire’).
• To determine whether you intend to press or hold a key, we need to wait untill either the key is released or another key is pressed. That means we won’t immediately see the characters we intend to type and we will perceive a delay or lag that can be distracting.

Unfortunately, many of the Home Row Modifier (HRM) implementations you may find out there do not address these problems effectively. But worry not, there are some excellent free and open source tools that can do this properly and you can use them right now. We’ll get to that soon.

Custom Layers

We now know we can use HRMs to access layers, like Shift and AltGr, without moving our hands away from the center of the keyboard. What if we could have other layers that would allow us to reach, for example, Escape or the arrow keys without moving our hands? The same tools used to implement HRMs can also help with that.

The main types of custom layers you may want to consider are:

• Navigation/editing (also known as Extend)
• Functions, numbers and symbols.

Layered Keyboard Layouts

Putting all of these together you get a layered keyboard layout. You can find many samples on keymapdb.com, including Kenkyo, the layout I put together during my journey learning all the concepts discussed in this article. There you will find examples on how to properly implement HRMs, using software like Kanata and keyd, as well as opinionated implementations of the aforementioned custom layers, which you can use as is or as inspiration for your own layers.

I hope you have found this article useful. Thank you for reading.

What?

10 keys for each of the 3 rows at the center of the keyboard plus a space-bar (or thumb key) is all you need, which makes it 31 keys.

How?

By using a couple of patterns, namely Home Row Modifiers (done properly) and SpaceFN, as well as a couple of layers: Extend (navigation and editing) and Fumbol (functions, numbers and symbols).

Why?

• So you can touch-type all keys, not just letters and basic symbols;
• So you don’t have to move your hands much and can make better use of your stronger fingers;
• So you can transition to a split, column-staggered, ergonomic, 34-key keyboard (or anything in between) and still be able to use your laptop’s keyboard with ease while remaining productive.

Interested?

Check out the Kenkyo keyboard layout.

Long version

I have earned a living as a software developer for 15 years and have used computers, and therefore keyboards, for about 30. But I had never questioned the design and format of keyboards until the pandemic hit. It was a time of introspection and learning. This is the story of how I have used the knowledge I gradually acquired since then to put together my 31-key, layered keyboard layout: Kenkyo.

The Extend Layer

I came across it while looking at DreymaR’s Big Bag of Tricks a few yeas back. That was the first time I heard about layers. I thought it was a great concept, but I did not try it straight away. It was after learning about kmonad that I remembered it and attemped to implement my own variant for the first time. Following the Colemak community’s guidelines, I chose to bind it to the CapsLock key.

My Extend layer has gone through many changes, but I have found it so intuitive and useful that it has never crossed my mind to let go of it.

The Fumbol layer

Once you learn about layers, one of the first things many of us think about is making one that can host keys like functions, numbers and symbols. I know because I have found online all sorts of creative takes on that same problem. I decided early on I just wanted to keep it simple and intuitive:

• The top row would contain the function keys;
• the home row would become a number row;
• and the bottom row would host other symbol keys that were hard to reach… and some media keys just because there was some spare room.

I also wanted to be able to stay on the layer temporarily in order to type sequences of numbers, and sometimes symbols. It became clear that I had to bind it to the only proper thumb key available on a standard keyboard: the space-bar. I later learnt this pattern was once known as SpaceFN. But it turns out it is not a trivial pattern to implement and presents similar challenges to those of the pattern we will discuss next.

Home Row Modifiers

As the name implies, home row modifiers (or HRMs) put keys like Ctrl, Shift and Alt/Option on the home or center row of the keyboard. They achieve this by distinguishing between taps and holds, which would result on a character being emitted or a modifier being activated respectively.

Sounds easy? Well, it’s not. Many of us are faced with a daunting sense of frustration when we try to put them in practice for the first time and abandon them early on. Unfortunately, the are many barely usable implementations out there that have given HRMs a bad reputation. But if done properly, HRMs can become an essential tool. It took me a while to figure out what makes a good implementation:

• Prior idle time: make sure you HRMs are skipped if a key or sequence of them has been pressed recently. This is how you can avoid misfires while you are in the middle of typing. This will also drastically reduce the perceived lag when you are typing as no evaluations are taking place and the key codes are emitted immediately. Good keyboard customization tools can do this: kanata with switch and key timings; keyd with overloadi; ZMK with require-prior-idle-ms; and finally, as I found out on the day I’m typing this, QMK with the Tap Flow module.
• Trigger on release: another technique that can also prevent misfires caused by key-rolls is to only activate an HRM if the modified key is both pressed and released before the HRM itself is released.

There are other interesting techniques, like Bilateral Combinations, but I believe that applying the precautions explained above and adjusting the timings to suit the typing style and speed of the user are sufficient to minimize frustrations and rip most of the benefits of HRMs.

31 keys

I went through many iterations to integrate the patterns described above into my layout. I only managed to reduce the number of keys to 31 after I realized I did not really need to make the CapsLock key useful. Many will passionately tell you how it is in a privileged location and it does not deserve it. However, if you turn it into something too useful instead, it will be your pinky finger who will suffer.

Therefore, I decided to try binding the Extend layer to the space-bar. After all, I knew it was the layer I use the most. But how could I access the Fumbol layer quickly and easily when I needed to?

As I had now plenty of unassigned keys on the left side of the Extend layer now (my pinky had been stuck on CapsLock so I could not reach them in the previous arrangement), I used one to swap the Extend layer for the Fumbol layer until I released the space-bar. This was great for when I needed to stay on Fumbol to type a series of numbers and/or symbols, but it felt like too much work when I just wanted to enter a single symbol or press a function key.

Then I remembered a technique some use to cope with their frustration with HRMs: Bottom Row Modifiers (BRMs). After some trial an error, I placed a pair of Fumbol Layer Modifiers on the V and M keys of the bottom row. While I was at it, I added an AltGr and a redundant Ctrl modifiers as well, which permitted me to perform all sorts of key combinations not only on the main layer, but on the Fumbol layer as well.

And that is how Kenkyo ended up only requiring 31 keys to do it all.

Conclusion

There is something about being able to rely solely on motor memory that makes typing pleasurable.

I used to think that using a tiny keyboard was an extravagant thing to do and wasn’t really practical. But I can now see that, if done right, most of the things one may do with a traditional keyboard can be done more efficiently and comfortably with a proper layout and way fewer keys.

I have recently acquired my first 36-key keyboard and transitioning to it using Kenkyo couldn’t have been easier. My new keyboard supports QMK, but I can’t find the motivation to go through the learning process that would lead me to replicate my layout using firmware because, even if I get it right (which is not certain), I won’t be able to make use of it with my laptop’s keyboard.

I hope some of you find this interesting and useful. Thank you for reading.

Imagine you are about to type the acronym UNRWA on a physical keyboard:

1. You hold the shift key with the pinky finger of your left hand
2. Press U and N using your right hand
3. Wish you had activated caps-lock
4. Proceed to awkwardly stretch the fingers of your left hand to type R, W and A while struggling to still hold the shift key

Now think of the same scenario, but this time the shift key has swapped places with the space-bar:

1. You hold the shift-bar with one or both of your thumbs
2. Type the letters with the fingers of both hands
3. Release the shift-bar and live a happy life

Isn’t that great? Well, except that now, to enter a space before each word, you have to constantly slide your pinkies outwards like you were a DJ or a percussionist.

Now, what if your space-bar could do both?

• When you press it, you get a space, as usual
• When you hold it, it acts as a shift key

That would solve the problem, right? Yes, although I would not recommend replacing your shift keys with it but rather have it as an available alternative. There are many pieces of software (e.g., keyd, Kanata, KMonad, Karabiner Elements, etc.) that allow you to achieve this behavior on all major operating systems. But let’s go a bit further.

In technical terms, the shift key activates a keyboard layer in which letters become capitalized and symbols change into other symbols. Although a seemingly useful feature, once you realize you can create your own personalized layers using the aforementioned software, you may decide that you don’t want to use your space-bar just as a glorified shift key.

You see, the space-bar has some very unique and important characteristics. It’s the only key designed to be:

1. Pressed by your thumbs and
2. Accessed by either of your hands.

Your thumb is also a special kind of “finger”, so much so that it is believed opposable thumbs gave us a crucial evolutionary advantage leading to us becoming the dominant species on the planet.

In regards to typing, the most interesting advantage of using your thumb to hold the space-bar is that, while doing so, your fingers are still able to reach the rest of the keyboard with relative ease.

Going back to our original example, picture the following sequence:

1. Hold a shift key
2. Hold the space-bar 📌
3. Release the shift key
4. Type the acronym
5. Release the space-bar

When you hold the shift key (1), the shift layer is activated, as usual, but with a particular difference: while active, holding the space-bar (2) effectively pins the shift layer. After you lift your pinky (3), shift remains active while you continue to type (4). Releasing the space bar (5) unpins the layer deactivating shift.

I call this technique keyboard layer pinning (or anchoring). I personally use it with my layers which enables me, for example, to pin one of them (e.g., functions, numbers, symbols) and then activate another one on top (e.g., shift, shortcuts) by holding a different key.

I have been a PC user for about 30 years now and a software developer for around half that time and I wish I had access to these tools a long time ago. I hope you find this approach as useful and impactful as I did when designing the keyboard layout that suits you best.

(…) [a flow whose] active instance exists independently of the presence of collectors (…)

For those of us coming from the world of Reactive Streams (RxJava in my case), these would be the equivalent to Subjects and Processors.

The reason I am glad we have hot flows, in the form of SharedFlow and StateFlow, is that I can replicate my previous implementation of uni-directional data flow with RxJava using coroutines and flows instead.

Let’s code

To demonstrate my approach I will use the same example I used for the RxJava version of this solution. However, I will introduce some improvements to how the model for this application will be defined.

The Event and State definitions will stay the same:

sealed class CoinTosserEvent {
    object Toss : CoinTosserEvent()
    object Heads : CoinTosserEvent()
    object Tails : CoinTosserEvent()
}

data class CoinTosserState(
        val isTossing: Boolean = false,
        val isHeads: Boolean = false
)

But instead of using a Reducer class I will simply use a function:

fun reduce(
        state: CoinTosserState,
        event: CoinTosserEvent
) = when (event) {
    CoinTosserEvent.Toss -> state.copy(
            isTossing = true
    )
    CoinTosserEvent.Heads -> state.copy(
            isTossing = false,
            isHeads = true
    )
    CoinTosserEvent.Tails -> state.copy(
            isTossing = false,
            isHeads = false
    )
}

And finally, I will introduce a new concept to handle side-effects. Enter the Reactor:

class CoinTosserReactor() {

    suspend fun react(
            event: CoinTosserEvent
    ): CoinTosserEvent? = when (event) {
        is CoinTosserEvent.Toss -> {
            delay(1000)
            when {
                Math.random() < .5 -> CoinTosserEvent.Heads
                else -> CoinTosserEvent.Tails
            }
        }
        else -> null
    }
}

I chose the term Reactor for this component to evoke the phrase “every action has a reaction”. The react method takes and Event and may or may not produce an Event in return.

In essence, here we can declare all our side-effects (e.g., network requests, database queries). If an Event produces no side-effects or if it is of no consequence to the logic of our application (e.g., logging), we just return a null value. Why am I not using a pure function for this as well? Because it is very likely I will need other dependencies for my side effects, like repositories or interactors.

StateFlow and SharedFlow

Now let’s get to the core of this solution and re-implement the ViewModel for our example app:

class CoinTosserViewModel : ViewModel() {

    private val events = MutableSharedFlow<CoinTosserEvent>()
    private val state = MutableStateFlow(CoinTosserState())

    val liveState: LiveData<CoinTosserState> = state.asLiveData()

    private val reactor = CoinTosserReactor()

    init {

        viewModelScope.launch {

            launch {
                events.mapNotNull(reactor::react)
                        .collect { launch { events.emit(it) } }
            }

            launch {
                events.map { reduce(state.value, it) }
                        .collect(state::emit)
            }
        }
    }

    fun onToss() {
        viewModelScope.launch { events.emit(CoinTosserEvent.Toss) }
    }
}

At the top we have defined our streams of events and states. Next we expose the state to the view as LiveData and instantiate our reactor.

Now, what is happening inside the init block? We are basically doing 2 things:

First, we start collecting the events, mapping the non-null values through our reactor. If our reactor produces and event (i.e.: Heads or Tails in this example), we emit that event back into the event stream. Basically, side-effects are now being handled. Notice we launch a new coroutine to emit an event back into the same flow (not doing so would cause issues).

Second, we start collecting changes to our state by mapping new events through our reduce function and emitting the resulting state back into the state flow.

Finally, we have a public method which emits Toss events into the events flow. And that is it!

Conclusion

I hope this example helps you structure your applications making use of coroutines and flows. I am still refining the approach, so please get comfortable with it before using it in production. I am sure you will find ways to improve on it and adapt it to your own coding style.

You can find the source code for the example here.

I have often had the feeling it was not clear to me what the Model was in my apps. While applying the Model-View-Presenter pattern, I implemented View interfaces and Presenter classes, but there was no explicit Model in my code.

A while ago, I took a break from Android development and decided to learn React and CycleJS. It took me some time to get my head around these different ways of structuring front-end applications.

A few months later, back in the Android realm, I started looking into the new ViewModel and LiveData classes of the Architecture Components library. I decided to put in practice the concepts I had learnt by using the aforementioned Javascript libraries: I would represent the Model in my Android apps as a State, Events and Side-Effects.

The State

What is the State? The dictionary says it is “the particular condition that (…) something is in at a specific time”. For our purposes, that “something” will be the View.

Events

What is an Event? Again, the dictionary says it is “a thing that happens or takes place”. I would add that, in the context of an application, an Event has the potential to change or modify the State.

Side-Effects

According to the dictionary definition, a Side-Effect is “ a secondary, typically undesirable effect of a drug or medical treatment”… Well, I guess the dictionary definition will not help us this time.

A Side-Effect, in the context of our Model, is something that happens as a consequence of an Event. For example, in the Event of a user pressing a button, a Side-Effect could be the execution of a network request or database query. These Side-Effects could produce a result in the form of an Event (e.g.: Success, Error, etc.).

Show me the code!

In a previous article I provided a very basic example on how to represent streams of State and Events in the context of a ViewModel using RxJava.

As a consequence of spending time applying the approach and refining it, I wrote a very small Android library called RxModel. It is so small you may as well copy and paste the code into your project. In this article I will provide an example of how to use it to structure the Model in your apps.

Coin Tosser

For this example, we are going to build an application consisting of a screen with a TextView and a Toss Button . When the Button is pressed, it becomes disabled and the TextView reads “Tossing…” for a second. After that, the Button is re-enabled and the TextView reads either “Heads” or “Tails”.

I made a GitHub repository with the implementation of the following example, in case you would like to check it out.

Let’s begin by modeling the Events for this use-case:

sealed class CoinTosserEvent {
    object Toss : CoinTosserEvent()
    object Heads : CoinTosserEvent()
    object Tails : CoinTosserEvent()
}

I have used a sealed class to define 3 types of Events. This way I ensure the application is only going to expect a finite set of Event types.

Next, we will represent the State for the same use-case:

data class CoinTosserState(
        val isTossing: Boolean = false,
        val isHeads: Boolean = false
)

I used a data class to represent the different properties of the State. The State is immutable: you cannot modify its properties. But how are we going to update the State after an Event occurs? We will we make a copy of the State and change only the properties we need to change (data classes count with a very handy copy(...) method that makes this easy).

Which takes us to the following step: defining a Reducer (if you haven’t already, you will need to add RxModel to your project to move forward).

object CoinTosserReducer : Reducer<CoinTosserState, CoinTosserEvent> {
    override fun apply(
            state: CoinTosserState,
            event: CoinTosserEvent
    ) = when (event) {
        CoinTosserEvent.Toss -> state.copy(
                isTossing = true
        )
        CoinTosserEvent.Heads -> state.copy(
                isTossing = false, 
                isHeads = true
        )
        CoinTosserEvent.Tails -> state.copy(
                isTossing = false, 
                isHeads = false
        )
    }
}

The Reducer consists of an object with a single function which takes the current State and an incoming Event and returns a new updated State.

So far we expressed what the Model of our app is in a declarative manner. But I purposely introduced a requirement in the specification of the use-case:

When the Button is pressed, it becomes disabled and the TextView reads “Tossing…” for a second.

What the statement above implies is that some work is going to be done in the background for some time and it will eventually produce a result. We are now dealing with asynchrony, which is what RxJava is meant to help us with. Triggering this asynchronous work is what I call a Side-Effect.

Let’s define a concrete Model and declare its Side-Effects:

class CoinTosserModel
    : StateEventModel<CoinTosserState, CoinTosserEvent>(
        CoinTosserState(),
        CoinTosserReducer
) {
    private val tossEventsObservable = eventObservable
            .ofType(CoinTosserEvent.Toss::class.java)

    private val tossSideEffect = Single
            .timer(1, TimeUnit.SECONDS)
            .map {
                when {
                    Math.random() < .5 -> CoinTosserEvent.Heads
                    else -> CoinTosserEvent.Tails
                }
            }

    override fun subscribe() = publish(
            tossEventsObservable.flatMapSingle { tossSideEffect }
    )
}

Notice CoinTosserModel extends from StateEventModel, which takes the initial State of the View and a Reducer as its constructor’s parameters.

And now I will explain what is probably the most complex part of this article: binding Events to Side-Effects and Side-Effects to Events.

• The first thing we do is obtaining an Observable of a specific Event type (Toss in this case).
• Then, we define the Side-Effect to be triggered by that Event type and make sure its possible results are mapped to Events (Heads or Tails in this case).
• Finally, we bind the Event to the Side-Effect and publish the resulting Event back into the Event stream.

The definition of our Model is complete. We can now use it in our ViewModel:

class CoinTosserViewModel : ViewModel() {
    private val model = CoinTosserModel()
    private val disposable = model.subscribe()

    val liveState: LiveData<CoinTosserState> =
            LiveDataReactiveStreams.fromPublisher(
                model.stateObservable.toFlowable(
                    BackpressureStrategy.LATEST
                )
            )

    override fun onCleared() {
        super.onCleared()
        disposable.dispose()
    }

    fun onToss() {
        model.publish(CoinTosserEvent.Toss)
    }
}

We expose the State to the View as LiveData so we do not have to deal with the intricacies of the Activity (or Fragment) life-cycle. We subscribe to the Model and dispose of the subscription when the ViewModel is cleared to avoid leaks that could be produced by ongoing asynchronous work related to the Side-Effects we trigger.

The onToss() method will be called by the View as you can see below:

class CoinTosserActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_coin_tosser)

        val viewModel = ViewModelProviders.of(this)
            .get(CoinTosserViewModel::class.java)

        viewModel.liveState.observe(this, Observer {
            it?.apply {
                statusTextView.text = when{
                    isTossing -> getString(R.string.tossing)
                    isHeads -> getString(R.string.heads)
                    else -> getString(R.string.tails)
                }
                tossButton.isEnabled = !isTossing
            }
        })

        tossButton.setOnClickListener { viewModel.onToss() }
    }
}

The View observes the State and updates accordingly. When the Toss button is clicked, it lets the ViewModel know.

That’s it! The cycle is complete. I hope this approach opens up more possibilities to what you can achieve in your apps. Happy coding!

I would like to begin with BaseViewModel class to get some concepts out of the way from the start:

abstract class BaseViewModel<State, Event>(
        state: State,
        reducer: (State, Event) -> State
) : ViewModel() {
    val liveState: LiveData<State>
    val events: Observer<Event>
    private val disposable: Disposable

    init {
        liveState = MutableLiveData<State>()
        events = PublishSubject.create()
        disposable = events.scan(state, reducer)
            .subscribe({ liveState.value = it })
    }

    override fun onCleared() {
        super.onCleared()
        events.onComplete()
        disposable.dispose()
    }
}

ViewModel is a class from the Architecture Components Library for Android. It was created to solve a common issue with the platform: surviving configuration changes (e.g.: rotating the device). They are meant to be used to hold the State of our View (Activity or Fragment). The way we expose the State is by publishing it using LiveData: a sort of Observable that is aware of the life-cycle of our View.

The State is not static. It will change after certain Events occur. We can represent this fact as function: f(old_state, event) = new_state. This type of functions are commonly referred to as Reducers. What the scan operator does is to take the latest State and pass it through the Reducer to obtain a new State every time an Event occurs.

Do not worry too much if you do not fully understand the code above. What BaseViewModel allows us to do is focus on the three main concepts mentioned before: State, Events and Reducer. Next, we are going to define the State of a counter:

data class CounterState(val count: Int)

For such a simple example, we just need to keep track of the current count so we can display on screen. Notice count is immutable, meaning you cannot assign a different value after State has been instantiated.

We are now going to define a few Events that can alter the State of our counter:

sealed class CounterEvent {
    object Increment : CounterEvent()
    data class Add(val quantity: Int) : CounterEvent()
}

We defined only two of the possible events. Increment does not carry any parameters, so we declare it as an object. Add, on the other hand, carries a quantity to be added to the counter, so we declare it as a data class.

By using Kotlin’s sealed class we can define a finite number of well-known Events that can occur. This is important for when we write the Reducer function for our ViewModel:

class CounterViewModel : BaseViewModel<CounterState, CounterEvent>(
        CounterState(count = 0),
        { state, event ->
            when (event) {
                is CounterEvent.Increment -> state.copy(
                        count = state.count + 1
                )
                is CounterEvent.Add -> state.copy(
                        count = state.count + event.quantity
                )
            }
        }
)

For brevity, I declared the Reducer in the constructor. All we are doing is specifying the initial state, making sure count is 0 to begin with. When an increment occurs, we copy the previous State and add 1 to count . When an addition happens, we also copy the previous State and add the quantity determined by the Event into count. It is important to copy the previous State because sometimes an Event modifies only part of it and we want the rest to remain the same.

As an exercise you can try to add the Decrement and Substract events and let the Reducer update the State appropriately. It is now time to put our new ViewModel to use:

class CounterActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_counter)

        val counterView = findViewById<TextView>(R.id.counter)

        val viewModel = ViewModelProviders.of(this)
                .get(CounterViewModel::class.java)

        viewModel.liveState.observe(this, Observer {
            it?.let { (count) ->
                counterView.text = "Count: $count"
            }
        })

        findViewById<Button>(R.id.increment).setOnClickListener({
            viewModel.events.onNext(CounterEvent.Increment)
        })
    }
}

When we create our activity we subscribe to liveState and populate the TextView with the new count every time there is an update. As an example, I implemented a Listener for the increment Button so it submits a new CounterEvent.Increment when clicked.

Conclusion

The approach I described above is not new. The goal is to have a single flow of events and states, forming a cycle that makes it easier to predict how the view is going to behave. By using ViewModel and LiveData we abstract away the complexity of the Activity and Fragment life-cycles, which could potentially introduce issues when handling events and subscriptions.

There are many things which haven’t been covered and I will leave it to the reader to experiment with the approach. However, it is important to mention that Events are not only user actions. In this example, events is and Observer. Therefore, it can be subscribed to other Observables, regardless of if they are bound to click events or network requests, as long as they return (or are mapped to) an expected Event type.

I hope this work serves a starting point for those of you trying to make your Android applications more reactive.

Let’s begin by creating a new application using Android Studio’s wizard, making sure we select Empty Activity as the template for the project.

Next, let’s create a custom Application class:

class MyApplication : Application()

And then add a reference to it in our AndroidManifest.xml:

<application android:name=".MyApplication" ... />

Now we need to add Dagger as a dependency in our app module’s build.config file:

...
apply plugin: 'kotlin-kapt'
...
dependencies {
    ...    
    implementation 'com.google.dagger:dagger:2.13'
    kapt 'com.google.dagger:dagger-compiler:2.13'
    implementation 'com.google.dagger:dagger-android:2.13'
    implementation 'com.google.dagger:dagger-android-support:2.13'
    kapt 'com.google.dagger:dagger-android-processor:2.13'
}

We can now create a Component for our Application:

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        DaggerMyApplication_Component
            .builder()
            .create(this)
            .inject(this)
    }

    @dagger.Component
    internal interface Component : AndroidInjector<MyApplication> {
        @dagger.Component.Builder
        abstract class Builder 
            : AndroidInjector.Builder<MyApplication>()
    }
}

I decided to include the Component as an internal interface of MyApplication for convenience, but you may want to extract it into its own file. All we are doing here is declaring a Component that is able to inject our Application class. However, we still have not added any Module so there is nothing to inject it with.

It is time to add a Module to our application which will provide an Injector for our Activity:

class MyApplication : Application(), HasActivityInjector {
    @Inject
    lateinit var dispatchingActivityInjector :  
        DispatchingAndroidInjector<Activity>

    override fun activityInjector() :
       AndroidInjector<Activity> = dispatchingActivityInjector

    ...

    @dagger.Module
    internal abstract class Module {
        @ContributesAndroidInjector
        abstract fun mainActivity(): MainActivity
    }

    @dagger.Component(modules = arrayOf(Module::class))
    internal interface Component : AndroidInjector<MyApplication> {
        ...
    }
}

We have just added a module to our Component, which will provide an Activity Injector, and implemented the HasActivityInjector interface to let Dagger know the Application exposes it. With all this in place, we can now inject MainActivity:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        AndroidInjection.inject(this)
        setContentView(R.layout.activity_main)
    }
}

All we have done so far is create a Component for our Application and let Dagger generate a Subcomponent (which is the Activity Injector) for our Activity. We are ready to introduce the Architecture Components library. Let’s add the required dependencies:

dependencies {
    ...
    implementation "android.arch.lifecycle:extensions:1.0.0"
}

Next, we are going to create a ViewModel for our Activity and a Module to provide it:

class MainActivity : AppCompatActivity() {
    @Inject
    internal lateinit var viewModel : ViewModel

    ...
    internal class ViewModel :
         android.arch.lifecycle.ViewModel()

    @dagger.Module
    internal object Module {
        @JvmStatic
        @Provides
        fun viewModel(
            activity: MainActivity
        ) = ViewModelProviders
            .of(activity)
            .get(ViewModel::class.java)
    }
}

All that is left is to bind the new Module to the Activity Injector. For that, we need to update the Application Component:

class MyApplication : Application(), HasActivityInjector {
    ...
    @dagger.Module
    internal abstract class Module {
        @ContributesAndroidInjector(modules = arrayOf(
            MainActivity.Module::class
        ))
        abstract fun mainActivity(): MainActivity
    }
    ...
}

Congratulations! Your Activity now has its own ViewModel. It doesn’t do much at the moment but it means we are ready to introduce LiveData into the mix:

class MainActivity : AppCompatActivity() {
    ...
    internal class ViewModel(
            greeting: MutableLiveData<String>
    ) : android.arch.lifecycle.ViewModel() {
        val greeting: LiveData<String> = greeting
        init {
            greeting.value = "Hello world!"
        }

        class Factory @Inject constructor(
                private val greeting: MutableLiveData<String>
        ) : ViewModelProvider.Factory {
            override fun <T : android.arch.lifecycle.ViewModel?>   
                create(modelClass: Class<T>) = 
                    ViewModel(greeting) as T
        }
    }

    @dagger.Module
    internal object Module {
        @JvmStatic
        @Provides
        fun greeting() = MutableLiveData<String>()

        @JvmStatic
        @Provides
        fun viewModel(
            activity: MainActivity
        ) = ViewModelProviders
            .of(activity, factory)
            .get(ViewModel::class.java)
    }
}

There are a few things to consider here. As an example, we assign an initial value to our LiveData object when the ViewModel is initialized. The Activity Module now provides LiveData of String. Also, in order to let the Architecture Components library inject the LiveData into the ViewModel through its constructor, we need to add a Factory class and pass it as a parameter to theViewModelProviders.of() method.

Finally, we are going to bind the LiveData from our ViewModel to the view in our Activity:

class MainActivity : AppCompatActivity() {
    ...
    private lateinit var greetingView: TextView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        AndroidInjection.inject(this)
        setContentView(R.layout.activity_main)
        greetingView = findViewById(R.id.greeting)
        viewModel.greeting.observe(this, Observer { greeting ->
            greetingView.text = greeting
        })
    }
    ...
}

We can now say we have a working Hello World app using Dagger, ViewModel and LiveData. But there is one more thing I want to mention. Every time we call AndroidInjeciton.inject() we are actually recreating the object graph for the Activity. This means every time we rotate the screen and the activity is created again, we get a new instance of the LiveData object which is injected into yet another new Factory object.

The fact is the ViewModel outlives the Activity. Therefore, the second time ViewModelProvide.of(activity, factory) is called, the whole Factory object is ignored. That is a lot of wasteful memory allocation we would like to avoid. I came up with the following solution:

class MainActivity : AppCompatActivity() {
    ...
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        try {
            viewModel = ViewModelProviders
                .of(this)
                .get(ViewModel::class.java)
        } catch (e: Throwable) {
            AndroidInjection.inject(this)
        }
        ...
    }
    ...
}

Basically, attempting to retrieve the ViewModel without providing a Factory will throw an error the first time, in which case we will execute the injection. After that, we will be able to retrieve the ViewModel without the need of a Factory. Of course this approach can only be taken if the Activity is kept as dumb as possible and no other objects need to be injected to it.