91 lines
3.4 KiB
Markdown
91 lines
3.4 KiB
Markdown
# AdvancedPrivacy Development Guide
|
|
This guide contains development related information to help a developer in getting better understanding of project structure.
|
|
|
|
## Architecture
|
|
The architecture of AdvancedPrivacy is based on [clean architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html). For presentation layer, we use a MVVM design pattern,
|
|
with a unique StateFlow<UiState> for each screen to simplify coherence. Our android app is having single activity multiple fragments, using Android Navigation component.
|
|
|
|
The project has 2 flavors :
|
|
- eOS: for /e/OS devices, with OS specific signatures, system priviledges and persistent flag
|
|
- standalone: for app's stores, without any priviledges.
|
|
|
|
Most of the differences between the 2 flavors are separated in distinct modules like :
|
|
- permissioneos / permissionstandalone
|
|
- trackersserviceseos / trackersservicesstandalone
|
|
|
|
### Clean Architecture
|
|
|
|
Clean architecture is the building block of AdvancedPrivacy. It is now a common way of organizing project,
|
|
so it helps newcomers. It gives a framework to apply Single Responsibility Principle, having a testable project
|
|
and keep files with a decent length.
|
|
|
|
|
|
The detailed file tree:
|
|
|
|
**Domain**
|
|
|
|
- entities : data classes, with no logic
|
|
- usecases : most of the logic, with no external dependencies
|
|
|
|
**LocalRepositories**
|
|
|
|
Repositories of data, that use local datasources, like sqlite database, sharedpreferences or in memory objects.
|
|
|
|
**NetworkRepositories**
|
|
|
|
Repositories of data, which fetch and push data to some remote servers.
|
|
|
|
**InterfaceAdapters**
|
|
|
|
All the glue to abstract Android framework (and also all it's supported versions) from the domain layer.
|
|
|
|
- services: Android Services
|
|
- broadcastreceivers: Android Broadcast Receivers
|
|
- Android Interfaces : abstraction of framework interfaces, like private and priviledges specific API.
|
|
|
|
**UI**
|
|
All the UI related code, with MVVM pattern.
|
|
|
|
## Good practices
|
|
|
|
### Use hidden-apis-stubs
|
|
|
|
Reflexion is avoided. We use an [hidden-apis-stub](./permissionseos/libs/hidden-apis-stub) project to make Android hidden APIs available for development and compilations.
|
|
Each stubed API should be documented with link to the source code they stub, for each targeted Android version.
|
|
|
|
### Use Coroutines and Flow
|
|
|
|
We use Coroutines and Flow for asynchronous tasks. The previous technologies (RxJava, LiveData) to do that are not welcome :)
|
|
|
|
### Use Koin for dependency injection
|
|
|
|
The project use Koin for "DI". It's flexibility is helpful to cleanly separate the flavored modules.
|
|
|
|
|
|
## OrbotService development and maintenance
|
|
|
|
The IpScrambling relies on a fork of OrbotService, which is a module of Orbot, the Tor proxy for Android. It lays as a submodule to help fork upgrade and patching. More here: [orbotservice/README.md](orbotservice/README.md)
|
|
|
|
## Code Quality and Style
|
|
|
|
It use ktlint through spotless. The specific rules are defined in [.editorconfig](./.editorconfig).
|
|
|
|
To run code style check and formatting tool:
|
|
```
|
|
./gradlew spotlessCheck
|
|
./gradlew spotlessApply
|
|
```
|
|
|
|
If spotlessApply fails, let's discuss to relax the ktllint rules.
|
|
|
|
## State-of-The-Art
|
|
|
|
This document present the objectives for the project, some area may still have legacy code organizations.
|
|
|
|
### Todo/Improvements
|
|
- [ ] Add unit tests and code coverage.
|
|
|
|
# References
|
|
1. [Kotlin Flow](https://kotlinlang.org/docs/flow.html)
|
|
4. [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
|