Norris is a showcase for modern and well-crafted Android code.

Here you will find a codebase powered by tests in all semantic levels (unit, integratation, acceptance) as well an architectural design that promotes discipline over state, using Kotlin Coroutines as foundation for a pragmatic unidirectional dataflow implementation.

Project Overview

This project leverages on as remote data source to implement the following use cases

  • User can search for Chuck Norris facts and share them
  • Related categories are fetched in the application boostraped and cached
  • Application will offer suggestions for queries based on categories names and track query terms provided by user as well

The code is structured in a multi-module fashion, with semantics guided by Clean Architecure; this means that high level modules (like facts or search) don't know anything about low-level ones (like networking or persistance).

The domain module defines the core protocols to be implemented by low level details, while aggregates them in high level policies like FetchFacts

A general representation of the module structure is such as follow. Beyond domain, there are modules shared between all features like navigator, shared-assets and others.


This project uses a custom implementation of unidirectional data flow in order to organise the responsabilities of abstractions on top of UI layer. Beyond the semantics of the defined protocols, we leverage a custom StateMachine that will process states and send them over a ConflatedBroadcastChannel to consumers.

The design of abstractions enforce that Coroutine's Scopes related to the emission and consumption of states are decoupled; in this way, we also have a notion of StateContainer, that will provide both the emissionScope and the Flow<T> implementation for emissions.

You may want to check the ConfigChangesAwareStateContainer abstraction, which leverages on Jetpack's ViewModel to keep the reference of the aforementioned ConflatedChannel, as well to provide the proper emission scope for states. An unbounded implementation is also defined for test purposes.

In this way, none of the ViewModels of this project derives from AAC ViewModel, but AAC ViewModel ensures the UI state persistance across device configuration changes.

Last, but not least, the choice for the Flow<T> over the conflated channel allows us to follow the reactive way for UIs without any LiveDatas. Just beautiful and simple.


This project has some remaining tasks. Follow the project board to learn about what is going on

Related blog posts

I'm writing a series of blog posts related to this project. They will explain some project decisions, as well dive into some details of implementation of this approach for unidirectional data flow, specially with learnings related to Coroutines and Channels.

Coming soon at

Building and Running

If you want a simple run, just use the companion script


It will

  • Run static analysers (Ktlint and Detekt)
  • Run all unit tests and generate all JaCoCo reports
  • Assemble the debug APK

For running acceptance tests

./gradlew connectedCheck