This is an Android project for Tellerium. This project include frequently used libraries and architecture we have decided to adopt for developing Android apps. This document describes the various processes and guidelines that the android team will use for consistency across board.
These instructions will give you heads up on how to get started, architecture flow, implementations using in this project.
We decide to adopted Clean Architecture
for our development because of it allow decoupling different units of your code in an organized manner. That way the code gets easier to understand, modify and test. Read more about this here
- MVVM architectural approaches for the Presentation layer
- Persistence is handled using Room
- Dependency injection using Dagger Hilt
- Orchestration of data flow using RxJava looking to move to Kotlin Flow soon
- Network operations with Retrofit
- Unit testing using Mockito
- Espresso UI tests
- Push Notifications with Firebase Cloud Messaging
- Managing work is done with WorkManager
Our gitflow runs in a similar manner to that described in this Atlassian doc. Feature branches and PR's are made off and into the Deploy branch. We should embrace a naming convention that describes the feature or bug fix being implemented. So for features we could have the branch name as feature/user-login
or f/user-login
and bug/cors-issue
or b/cors-issue
for bug fixes. PR's are made for each task or feature implementation, this with the branch naming convention ensures that it would be easier to isolate issues introduced to develop branch or production and restore to working condition without affecting other features.
Once you have pushed to a feature branch, you are required to create Pull Request to the deploy
branch which will be reviewed by other engineers on the team.
We also use Tag for release versioning on Git.
Variable , methods & Classes names must be self descriptive also in camel case. e.g
PostActivity
for class namefragment_post
layout file nametvPostTite
View id referenceperformLogin()
method name
We use docs blocks to write description documentation and comment for classess and methods. This should clearly describe it functionality and logic executions.
Linting is handled byktlint. Click here to see common use cases of how to structure your code.
- Clone this project from Bitbucket to your machine
- Import project to Android Studio preferring from v4.0 and above
Practicing test driven development helps to ensure quality and reliable functionalities. Though we are not writing tests yet, these are the test we should look forward to:
- Unit Test(logic test): This involves testing your logic on the remote, cache, data and presentation layer using Mockito and JUnit.
- Instrument test(UI test): This involves testing the UI components(activty & fragments) using Espresso.
Deployment is handled differently based on build variant.
- Debug: Apk is sent via Firebase App Distribution to tester
- Release: Apk is sent via Firebase App Distribution to fields agents to download via a link
- Migrate from RxJava to Flow.
- Writing Unit Tests
- Branch out from the develop branch to your feature branch
- Create Model classes for the feature if needed.
- Add the use case to the neccessary repository interface.
- Create Usecases for the feature in the
interactors
- If the Usecase needs any data to carry out any operation provide a nested param class.
- Add remote and cache operations to the
Cache
andRemote
interface. - Add the cache or remote interface implementation to its correct data source classes.
- Add the implmentation of the domain interface repository in the data
- Update use case implementaion in the ViewModel classes
- Add your UI Implementation as specified in the design
- Use viewmodel to interact with the other layers of the application.
- Kingsley John
- Kingsley Usoro
- Edidion Ekong
- Ememobong Akpanekpo
Clean Architecture from Buffer Clean Architecture - Getting started