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
AndroidDataFlowthis means that if we need theContextin the ViewModel we cannot extends theAndroidViewModelbut 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.