Skip to content

Latest commit

 

History

History
118 lines (71 loc) · 8.04 KB

README.md

File metadata and controls

118 lines (71 loc) · 8.04 KB

  Android Template

This is a opinionated template for new Android projects used and open sourced by Monstarlab.

💻 Techstack

  • 100% Kotlin
  • 🔄 Kotlin Coroutines for async operations
  • 🚀 Jetpack Architecture Components
  • Jetpack Compose ❤️
  • ☁️ OkHttp and Retrofit for networking
  • 🔗 Kotlin Serialization as primary JSON (de)serialization tool
  • 🗡️ Dagger / Hilt for Dependency Injection
  • Spotless for code-format control
  • 🔍 Detekt for static code analysis
  • 🌐 Chucker - network traffic logger
  • 🐤 LeakCanary - memory leak detection

Table of contents

  1. Before you start
  2. Template Structure
  3. Architecture
  4. Flavours
  5. Tools

⚠️ Before you start

Before you start using the template, you probably want to install the Jetpack Compose UI Architecture Plugin on Android Studio.

This plugins facilitates the work when creating new Compose screens.

After installing, creating new features in the correct template structure should be as easy as doing the following:

1 - Select the "New feature" option

2 - Name your new feature

3 - The correct folder structure should be created for you

Project Structure & Modules

Android template project has a modular structure and has following modules: :core, :designsystem, localization and :app. The intention is to make this template as flexible as possible by introducing shared modules while having the all the features reside in :app module. In case project grows, this allows to easily decouple features from :app module and/or introduce new features as part of separate module.

build-logics module

Build logics module contains all the build logic that is shared across the project. That includes min sdk, target sdk, compose setup, and so on. This module provides convention plugins that are used in other modules to apply these common settings.

core module

Core module is meant to be Domain-agnostic. It means that it should never reference anything project specific. Instead, it serves as a home for components that can be part of any project. This includes extensions on Kotlin Classes, Utility classes, Base classes, Compose layouts and Compose Effects and Modifiers that are behavioural rather then UI emitting

designsystem module

The design system module contains the building blocks for your application's UI. The main thing you will find here is Theme. This template is using custom Theme provider for Jetpack Compose while having Material Theme as its foundation. This allows to tweak Colors and Typography so it reflects actual Design System that is used on the project and supply custom properties like Dimensions

Another part of the design system are components. Examples of designsystem components are Buttons, TopBars, TextFields and so on. The template provides AppButton AppTextField and AppTopBar that you can modify and tweak and use throughout the project.

localization module

Localization module contains NStack configuration and Translations.java file so that all localization is in one place. This module is meant to be used in the app module to prvoide translations for the app and designsystem module to provide translations for the design system components (such as accesaibility labels) The NStack is configured in its build.gradle.kts and initilized using androidx Startup library.

app module

This is a main modules that contains feature packages - the meat of any project. A Feature typically contains all the necessary code, resources and assets required to implement a specific application functionality, such as a login screen, shopping cart, or authentication. It may also have its own sets of dependencies, like third-party libraries or other features.

Feature modules

While the template doesn't really have feature modules and every feature is part of the :app module, it is adviced to make use of feature modules in case the you see there is good candidate for it. It will especially benefit mid to large sized projects under active development

Each feature (module or not) is following Clean Architecture Principles and has a three-layer split

Architecture

Template implements Clean Architecture and follows best practices provided by Google with some tweaks here and there

Presentation layer

In our Android world, the Presentation layer or UI Layer is our Activities, Fragments, Jetpack Compose UI screens and components and ViewModels. The Presentation layer interacts with Domain Layer where our business logic happens.

Domain layer

The domain layer contains the application's business logic. This layer should only work with abstractions and as such it would never know about how different layers look like. It shouldn’t know about any Databases, APIs, or even Android Framework.

Data layer

The data layer is where the actual interactions happen between different data sources. This layer “implements” parts of the Domain layer and communicates with the APIs, Databases, and other services and SDKs.

Flavors

  • Dev: Intende for developers use only. Usually will have the same endpoints as staging. This have LeakCanary to help detect leaks.
  • Staging: Intended for QA and internal testing. This usually have api endpoint for a testing server.
  • Release: Intended for release. This version usually have live endpoint and signed builds.

Tools

These are the tools used in the template, to improve the development, that you should be aware of:

Spotless is a Gradle plugin used to format source files. You can use it running the following Gradle commands:

./gradlew spotlessCheck - Checks the style formatting and displays any issues

./gradlew spotlessApply - Same as above but automatically try to fix most of the issues. If for any reason it can't, then a list of problems is displayed.

Chucker is a HTTP inspector to help check the api calls when the app is being executed, this is helpful for both devs and QAs to analyse the trafic data. It should show as a notification when the app is ran. Note that is uses an Interceptor in the OkHttpClient to get the data, so if you need to create a new OkHttpClient for any reason, remember to also add the Chucker's Interceptor.

LeakCanary is a memory detectiong library that will automatically run in devDebug builds. It will automatically detect memory leaks and in case anything is found a notification will be shown. After that the details of the leak can be viweed both by clicking the notification on in the Logcat. This is intended for devs to spot and fix any leaks as early as possible.