Playing with pokemons and unidirectional data flow.
Data is fetched from PokéAPI
The repo follows the recommended architecture from Google following the MVI architectural presentation pattern using Uniflow . Even if we do not implement Use-Cases we stick as much as possible with the Clean Architecture principles.
Since we are using Uniflow, Jetpack Compose was the obvious choice rather than standard layout files, because we can seamlessly react to the "STATE" without having observers such as onState
and Uniflow intergrates perfectly well with it (check Uniflow and Compose).
The navigation is perfomed with Compose Navigation in beta, we could have used the stable Jetpack Navigation, but this would have meant mixing fragments with Compose adding complexity that we wanted to avoid for a this playground project.
While we could have re-implemented the MVI logic manually, it would have been a lot of boilerplate so we can pick one ot the existing frameworks, for example:
We went with Uniflow since it is a compromise between the complexity and the amount of boilerplate code that needs to be written. Two things that we are not fond of:
- Uniflow uses
observeAsState()
. This means that we depend on LiveData i.e. from the Android Framework. The library could use Flow instead as Orbit-MVI does. - The ViewModel must extend an
AndroidDataFlow
this means that if we need theContext
in the ViewModel we cannot extends theAndroidViewModel
but need to find a workaround.
For loading images we were using Coil because it supports Compose out of the box and has a very nice API. Sadly there is a very bad glitch with Compose Lists (LazyColumn
): this issue on coil repo describes the problem.
So we moved to Glide, but glide has no support for Compose, besides from a nasty workaround, so finally we decided to go with Landscapist.