catalinghita8 / android-compose-mvvm-foodies

Android sample app following best practices: Kotlin, Compose, Coroutines and Flow, Hilt, JetPack Navigation, ViewModel, MVVM, Retrofit, Coil
469 stars 89 forks source link
android android-application android-compose android-development compose google-material hilt hilt-dependency-injection hilt-dependency-injection-android kotlin kotlin-coroutines kotlin-flow material-ui mvvm

Foodies - Modern Android Architecture

Foodies is a sample project that presents a modern approach to Android app development.

The project tries to combine popular Android tools and to demonstrate best development practices by utilizing up to date tech-stack like Compose, Kotlin Flow and Hilt.

The sample app layers its presentation through MVVM presentation pattern. Additionally, the application features animations like expanding and collapsing row items or other effects like collapsing toolbar.

Description

Presentation patterns layers

As the presentation layer is defined with MVVM, there are a two core components described:

Every screen/flow defines its own contract class that states all corresponding core components described above: state content and effects.

Dependency injection

Hilt is used for Dependency Injection as a wrapper on top of Dagger.

Most of the dependencies are injected with @Singleton scope and are provided within the FoodMenuApiProvider module.

For ViewModels, we use the out-of-the-box @HiltViewModel annotation that injects them with the scope of the navigation graph composables that represent the screens.

Decoupling Compose

Since Compose is a standalone declarative UI framework, one must try to decouple it from the Android framework as much as possible. In order to achieve this, the project uses an EntryPointActivity that defines a navigation graph where every screen is a composable.

The EntryPointActivity also collects state objects and passes them together with the Effect flows to each Screen composable. This way, the Activity is coupled with the navigation component and only screen (root level) composables. This causes the screen composables to only receive and interact with plain objects and Kotlin Flows, therefore trying to be platform agnostic as much as possible.