Skip to content
/ PracticalApp Public template

Sample app architecture for commercial/outsource development.

Notifications You must be signed in to change notification settings

zakrodionov/PracticalApp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

10757e4 · Jun 28, 2023
Apr 28, 2023
Aug 17, 2021
Jun 9, 2023
Jun 9, 2023
Apr 28, 2023
Dec 5, 2022
Mar 29, 2021
Mar 25, 2023
Apr 28, 2023
Mar 10, 2021
Jun 28, 2023
Nov 14, 2022
Mar 29, 2021
Apr 28, 2023
Mar 2, 2021
Mar 29, 2021
Mar 2, 2021
Jun 24, 2021

Repository files navigation

PracticalApp - Compose Build

PracticalApp is an application architecture example for commercial/outsourced development. Main goals: efficiency, ease of maintaining the code, the use of tools that do not require long study (Android Architecture Components, Koin, Coroutines). The principles of Clean Architecture are followed, but without strict fanaticism, not at the expense of performance (without abstractions for the sake of abstractions).

  1. Interfaces must be written on the repository
  2. The interactor is used only if you need common logic on several screens, and not just duplicate the repository call
  3. If the model used in the UI layer, for example, in the Rv-adapter, is the same as in Domain / Data, then it can be marked with annotations from Moshi / Gson / Room in the same place so as not to duplicate it and do not create an extra mapper.

For convenience, the :common module has been added, which contains utilities, extension functions and custom views / classes used in most projects and the :coreui module which contains themes, styles, colors for the project. If 1-3 people are working on the project, feature modules can be left out and written as usual, in the main module.

Code debugging/development

For the convenience of debugging code during development, several libraries are used: Flipper (replacing Stetho), Hyperion, Timber, LeakCanary. Flipper, Hyperion allow you to intercept network calls, view the contents of SharedPrefernces, DataBases, have built-in layout inspectors, color pickers and other tools for developers.

Compliance with code-style

Detekt, Ktlint libraries are used to maintain a uniform code style. Before pushing, you should check the new code for compliance with the rules using the ./gradlew ktFormat && ./gradlew detekt command, or configure task in Android Studio. CI is also configured with Detekt, Ktlint to check the project with Push, Pull Request.

Code cleanliness

Android Studio has a pretty good built-in linter, launched using the ./gradlew lint command. Allows you to identify Deprecated APIs, unused resources, security, performance, usability, accessibility issues, etc....

Stack

• Android Jetpack + Compose

• Kotlin

• MV/I/VM

• Retrofit, Coroutines, Moshi, OkHttp

• Android ViewModel

• Voyager

• Koin

• Coil

• Desugar Jdk (Java 8 time)

• Flipper, Hyperion, Timber, LeakCanary

• Github Actions

• Gradle DSL

• Gradle Modules

What the sample looks like:

Пример, как выглядит сэмпл