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.
This project leverages on api.chucknorris.io 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
search) don't know anything about low-level ones (like
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
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 ubiratansoares.dev
Building and Running
If you want a simple run, just use the companion script
- Run static analysers (Ktlint and Detekt)
- Run all unit tests and generate all JaCoCo reports
- Assemble the debug APK
For running acceptance tests