AppLounge is not hudge but is a complex app : a rich UI with 10 - 15 screens, long running tasks, recurring background task, and 5 backends to speak with. It followed the [_Packaging by Features_ approach](https://phauer.com/2020/package-by-feature), but then fell into having too much layers, and at the same time to much lack in single responsibility principle. The following rules, reviewed by the main maintainers of the project, will be the guide for future features implementations, bug fixes and refacor to improve maintainability and reliability of App Lounge.
App Lounge target is under refactoring to follow a clean architecture. 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.
It relies on the following file tree organisation:
### Domain module
*foundation.e.apps.domain*
It is designed to facilitate unit testing, and to work only on safe and sanitized data (the entities). It helps focus on the tasks, making complex tasks readable. This module doesn't have dependencies on other module, but declare Interfaces of the surrounding modules it may need.
**Entities**
The Domain module contains **entities**: the data classes used across all the app. Types, nullability should be chosen to help usage in algorithm in the usecases. Feeding usecases with validated data is the task of other modules. The data classes of the entities are dispatched in feature (business features) related packages: foundation.e.apps.domain.entities.*feature1*.EntityClass
**Usecases** : where the logic of the DeviceManager is implemented. The goal of this architecture is to have easily unit-testable usecases, and then to put as much logic and knowledge as reasonable in te usecase.
The usecase is responsible to chose the coroutine scope and the thread (dispatcher), on wihch the work is done. It is typically a initialization parameter of the UseCase class.
The UseCase handle a whole (little) feature : it can have many methods (not the usecase.invoke() pattern).
The class of the usecases are dispatched in feature related packages: foundation.e.apps.domain.usecases.*feature1*.Feature1UseCase
### Data module communicating with backends
Abstracts the communications with the backends for the UseCase methods. There is **at most two layers** in this modules: Repository and DataSources.
* The DataSource hold the backend-specifics elements, and have to map the communications as domain entities. It can rely on reftrofit, GPlayApi lib.
* A Repository may be use in some cases, to handle complex backend logic (like take care of fresh auth token before doing a request)
App Lounge is an open-source application that allows you to install Android apps on your device quickly and easily. It is licensed and distributed under [The GNU General Public License v3.0](https://www.gnu.org/licenses/gpl-3.0.en.html).
## Project Structure
App Lounge use the _Packaging by Features_ approach for packaging the code. A really good explanation for this approach can be found on Philip Hauer's [Package by Feature](https://web.archive.org/web/20211025104408/https://phauer.com/2020/package-by-feature/) blog post.
<details><summary>Click to expand</summary>
```
./root
├── api
│ ├── cleanapk
│ │ ├── blockedApps
│ │ └── data
│ │ ├── app
│ │ ├── categories
│ │ ├── download
│ │ ├── home
│ │ └── search
│ ├── database
│ ├── ecloud
│ │ └── modules
│ ├── exodus
│ │ ├── models
│ │ └── repositories
│ ├── fdroid
│ │ └── models
│ ├── fused
│ │ ├── data
│ │ └── utils
│ └── gplay
│ ├── token
│ └── utils
├── application
│ ├── model
│ └── subFrags
├── applicationlist
│ └── model
├── categories
│ └── model
├── di
├── home
│ └── model
├── manager
│ ├── database
│ │ └── fusedDownload
│ ├── download
│ │ └── data
│ ├── fused
│ ├── notification
│ ├── pkg
│ └── workmanager
├── purchase
├── receiver
├── search
├── settings
├── setup
│ ├── signin
│ │ └── google
│ └── tos
├── updates
│ └── manager
└── utils
├── enums
└── modules
```
</details>
## API
App Lounge use the following APIs to offer applications:
@@ -80,6 +12,7 @@ App Lounge use the following APIs to offer applications:
## Development
-[Development guidelines and targete architecsture](./DEVELOPMENT.md)
- Documentation regarding development can be found on this repository's [wiki](https://gitlab.e.foundation/e/apps/apps/-/wikis/home)
- A the list of contributors can be viewed on this repository's [contributors graph](https://gitlab.e.foundation/e/apps/apps/-/graphs/master).
