iamvolkanhoturcci / base-mvvm

Base Android Structure with MVVM and Architecture Components

Kotlin Android side project with Kotlin

This is a side project for Kotlin Android. And it presents a modern approach to Android application development using Kotlin and the latest tech-stack.

The goal of the project is to recreating Kotlin Android with best practices, provide a set of guidelines, and present modern Android architecture that is modular, scalable, maintainable, and testable.

Design

App support different screen sizes and the content has been adapted to fit for mobile devices and tablets. To do that, it has been created a flexible layout using one or more of the following concepts:

• Use constraintLayout
• Avoid hard-coded layout sizes
• Use the smallest width qualifier
• Use the available width qualifier
• Add orientation qualifiers

In terms of design has been followed recommendations android material design comprehensive guide for visual, motion, and interaction design across platforms and devices. Granting the project in this way a great user experience (UX) and user interface (UI). For more info about UX best practices visit link.

Architecture

The architecture of the application is based, apply and strictly complies with each of the following 4 points:

• Android architecture components, part of Android Jetpack for give to project a robust design, testable and maintainable.
• Model-View-ViewModel (MVVM) Pattern facilitating a separation of development of the graphical user interface.
• S.O.L.I.D design principles intended to make software designs more understandable, flexible and maintainable.
• Modular app architecture allows to be developed features in isolation, independently from other features.

Architecture components

Ideally, ViewModels shouldn’t know anything about Android. This improves testability, leak safety and modularity. ViewModels have different scopes than activities or fragments. While a ViewModel is alive and running, an activity can be in any of its lifecycle states. Activities and fragments can be destroyed and created again while the ViewModel is unaware.

Passing a reference of the View (activity or fragment) to the ViewModel is a serious risk. Lets assume the ViewModel requests data from the network and the data comes back some time later. At that moment, the View reference might be destroyed or might be an old activity that is no longer visible, generating a memory leak and, possibly, a crash.

The communication between the different layers follow the above diagram using the reactive paradigm, observing changes on components without need of callbacks avoiding leaks and edge cases related with them.

Build variants

The application has different product flavours: QA, PROD. Each variant has a specific target environment

Tech-stack

This project takes advantage of many popular libraries, plugins and tools of the Android ecosystem. Most of the libraries are in the stable version, unless there is a good reason to use non-stable dependency.