The purpose of this base architectural project is to load it with all the latest components and libraries, So it becomes a reference for all kinds of Android projects
This document will help us in developing an android app using the best approach towards setting up the configuration, design pattern and technologies in the upcoming projects.
Project should be configured to these settings following the recommendations from Google and market requirements:
- Language: Kotlin
- minSdkVersion: 19
- targetSdkVersion: 30
- Kotlin Style Guidelines
This section describes all the libraries/frameworks to be used.
Android Jetpack Libraries will be used for a cleaner and efficient approach in laying down the foundation.
This section intends to provide some guidance and foundation for the app’s architecture where the main goal is to produce SOLID, clean and testable code following two common architectural principles:
- Separation of concerns
- Drive UI from a model
It's impossible to have one way of writing apps that works best for every scenario. That being said, this recommended architecture is a good starting point for most situations and workflows.
MVVM separates your view (i.e. Activities and Fragments) from your business logic. MVVM is enough for small projects, but when your codebase becomes huge, your ViewModels start bloating. Separating responsibilities becomes hard.
MVVM with Clean Architecture is pretty good in such cases. It goes one step further in separating the responsibilities of your code base. It clearly abstracts the logic of the actions that can be performed in your app.
Here business logic is completely decoupled from the UI. It makes the code very easy to maintain and test. This design pattern is based on the following three android architectural components:
- View Model
- Live Data
- Room
There is a little bit change in approach how UI communicates with the ViewModel, instead directly calling its methods or properties, there are States and Events which makes the code more readable and structured. Please checkout MVI demonstration in my branch MVI_Kotlin_Flow of this repository
View related classes should be organized as a packe-per-feature. This means, all the adapters, activities, fragments etc should not be in a single package for all of those. Instead, there should be a separate package for each feature containing all the related classes inside. This makes the code easier to navigate through and also easier for new people to find specific classes when working on a specific feature.
We will be following this below given structure depicting the Note Application:
- endpoints
- service
- network
- utils
- ui
- logging
- model
- utils
- datasource
- model
- repository
- usecase
- base
Retrofit will cover the network layer for fast and easy operations on fetching and parsing JSON data.
Koin is used in the base branch that uses Kotlin’s DSLs to lazily resolve your dependency graph at runtime. Please checkout Hilt demonstration in my branch Hilt of this repository
Firebase Crashlytics will be used for this purpose.
Timber will be used for this purpose, It helps us managing how logging will work depending on the build type (debug/release) and also contains some other helpful features like not needing to indicate the log tag because Timber automatically detects which class is logging.
Coroutines/RxJava will be used for this purpose.
Glide will be used for this purpose.
ThreeTen wil be used for this purpose.
This is the initial version, In next versions I will try to upgrade this repository with MVI, Hilt, Kotlin Flow and many new stuff.