# android-architecture Published articles for android-architecture. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Multi-Module Android Template with Kotlin Convention Plugins, Lint Rules, and Design System Tokens DevFeed: [A Multi-Module Android Template with Kotlin Convention Plugins, Lint Rules, and Design System Tokens]() Original publisher: [Read original article]() Author: Shamil Gulmetov Published: 2026-09-09T01:34:18Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [Template](), [Android](), [Architecture & Design](), [Kotlin](), [Gradle](), [Jetpack Compose](), [Dependency injection](), [Automation](), [Refactoring](), [now-in-android]() Tags: [android](), [android-app-development](), [android-architecture](), [android-studio](), [architecture](), [automation](), [best-practices](), [build](), [compose](), [dependency-injection](), [gradle](), [how-to](), [jetpack-compose](), [kotlin](), [now-in-android](), [refactoring]() ### AI overview This tutorial presents an Android Architecture Template based on patterns from Google's Now in Android repository. It describes a multi-module structure with Gradle Version Catalogs, Kotlin Convention Plugins, Jetpack Compose design tokens and dark-theme support, dependency injection, custom Lint rules, and a terminal-based renaming tool. ### Source excerpt How to streamline your development workflow with pre-configured Kotlin Convention Plugins, custom Lint rules, and unified design system tokens. Creating a new Android application from scratch in modern engineering is rarely as simple as clicking File -> New -> New Project in Android Studio. Before writing a single line of business logic, developers face hours -- or even days -- of repetitive infrastructure setup: Configuring a scalable multi-module architecture. Setting up Gradle Version Catalogs and writing custom Kotlin Convention Plugins to eliminate build script duplication. Standardizing design tokens and dark theme support in Jetpack Compose. Wiring up Hilt Dependency Injection for Coroutine Dispatchers, network, and Application Scopes. Enforcing architectural boundaries and team coding standards using custom static analysis (Lint) rules. Google's official Now in Android (NiA) repository is the recognized gold standard for modern Android engineering. However, because NiA is a full-featured showcase app with domain logic (news feeds, authors, bookmarks, offline sync), using it as a starter kit is cumbersome: developers must strip out existing features while risking breaking build pipelines. This Android Architecture Template bridges that gap: a clean, production-ready starter kit that extracts NiA's best architectural patterns into an isolated foundation. To make it enterprise-ready with zero room for error, it includes a standalone automation tool. Instead of manual refactoring, run a single terminal command to rename and brand the entire architecture in seconds. Acknowledgments & Credits Core architectural decisions, build-logic convention plugins, and static analysis infrastructure in this template are directly inspired by Google's official Now in Android (NiA) repository. Rather than reinventing the wheel, this template focuses on developer ergonomics--making Google's best practices instantly usable out of the box. 1. Modular Project Architecture The repository ## Android Architecture Patterns: A Comprehensive Pre-Interview Guide DevFeed: [Android Architecture Patterns: A Comprehensive Pre-Interview Guide]() Original publisher: [Read original article]() Author: Ishan Khanna Published: 2025-03-18T20:01:26Z Content type: tutorial Language: en Sources: [Ishan Khanna]() Topics: [Android](), [Architecture & Design](), [mvc](), [Mobile](), [Jetpack Compose]() Tags: [android](), [android-architecture](), [architecture](), [code](), [comparisons](), [examples](), [guide](), [interview](), [mvc](), [patterns]() ### AI overview A pre-interview guide to Android architecture patterns. It explains why architectural patterns matter and covers MVC, MVP, MVVM, MVI, and modern Jetpack Compose implementations, with code examples and comparisons. ### Source excerpt Looking to brush up on Android architecture patterns before your next mobile interview? This guide covers everything from traditional MVC to modern Jetpack Compose implementations, with code examples and comparisons of MVC, MVP, MVVM, and MVI patterns. ## Android Architecture: Runtime Centric Thinking DevFeed: [Android Architecture: Runtime Centric Thinking]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2021-11-08T00:00:00Z Content type: opinion Language: en Sources: [SystemDotRun]() Topics: [Android](), [Testing](), [Test automation]() Tags: [android](), [android-architecture](), [architecture](), [blog-post](), [complexity](), [production](), [test-automation]() ### AI overview This blog post presents a high-level overview of a runtime-centric architecture for Android applications. Drawing on the author's experience using it in two production projects, it discusses Android component lifecycles, instantiation, test automation, threading, fragments, and ways to reduce run, build, and test-time complexity. ### Source excerpt For at least 7 years I have been playing with "alternative" Android architectures in a professional context. This blog post is a brief overview to an architecture I have been using for the last two production projects for which I was Android Lead and outlines a high level introduction to a production-level runtime-centric application. I will note at the start I am not attempting to persuade anyone to use this approach over any other, but rather: Understand my own thoughts better through writing Share something which has worked well for me which others may find interesting I imagine it may raise more questions than it answers, and if so please leave a comment and I can expand any concepts if desired. Motivation My original motivation to think about alternative Android architectures was due to me often feeling there were personally unexplored and advantageous ways to structure certain types of applications on an OS like Android, which has a number of idiosyncrasies including application component lifecycles, application component instantiation, difficulty in test automation and so on. In the 12 years I have been a professional Android developer I have seen some common examples of where complexity has been layered on top of some of these areas in the aim of making them easier to deal with on a day to day basis when often an arguably simpler divergent approach has been overlooked. For some quick fire examples I would include here: Test time OS level faking frameworks vs OS abstraction at build time Complex lifecycle aware asynchronous view-level listeners as opposed to rendering immutable states Complex 3rd party dependencies utilised for threading purposes as opposed to thread abstraction Fragments vs thin views cough I found that there were often common solutions to common problems but which often came with an additional baggage of increased run / build / test time complexity. Instead of thinking in terms of surface level solutions my mind kept wondering back to think ## Debugging LiveData changes made easy DevFeed: [Debugging LiveData changes made easy]() Original publisher: [Read original article]() Author: Chao Zhang Published: 2021-04-08T21:16:44Z Content type: tutorial Language: en Sources: [Stories by Chao Zhang on Medium]() Topics: [Android](), [debugging](), [Logging](), [Android Studio](), [App]() Tags: [android](), [android-architecture](), [android-studio](), [architecture-components](), [bytecode](), [class](), [debugging](), [gradle](), [java](), [jetpack](), [livedata](), [logging](), [refactoring]() ### AI overview This tutorial examines the difficulties of debugging LiveData changes in larger Android applications. It compares breakpoints and logging, explains why both become less effective as observing chains grow, and identifies minimal code changes and historical state information as key requirements for a better approach. ### Source excerpt Photo by Markus Spiske from Unsplash Have you ever got frustrated to debug LiveData changes by adding numerous log statements or breakpoints? As the core data structure of Android Architecture Components, LiveData is used widely in many apps to hold observable data. However, its debugging experience could still be a pain point after these many years. Observing LiveData changes at scale There are two traditional yet powerful methods for observing LiveData changes: Debugging and logging. When it comes to debugging, we mostly interact with our IDE and do not need to touch any code. We can simply click "Debug" or "Attach Debugger to Android Process" in Android Studio and expect the process to be paused at the preset debug breakpoints. Debugging in observers In terms of logging, we can add logging statements to our observers to know when they are called. When we rerun the app, we should be able to view those log statements through Logcat while interacting with the app. https://medium.com/media/bd34828e0230fe59c141c0e820c7436e/href Both debugging and logging are effective when we have simple LiveData observing chains. While we are iterating our app with new features and business logics, we may find it necessary to scale up our app into the recommended app architecture illustrated below. As you can tell, LiveData becomes more universally used as the data holder type across different components. In other words, LiveData observing chains merely get longer and more complex. App Architecture using LiveData When debugging our app at scale, logging might be less effective, because we do not want to change code at multiple places to debug. Alternatively, we could also build an abstract class LoggingObserver : Observerthat adds log statements in onChanged(data: T) , and require all observers to inherit from LoggingObserver. This plausible approach is cumbersome since it requires large-scale refactoring of our app code. Using debugging may not be effective either: We need to ## Communicating with your Lifecycle Owner using RxJava DevFeed: [Communicating with your Lifecycle Owner using RxJava]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2020-09-08T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Android](), [Jetpack](), [RxJava](), [Coroutines](), [Development]() Tags: [android](), [android-architecture](), [android-development](), [architecture](), [coroutines](), [development](), [google](), [jetpack](), [kotlin](), [libraries](), [livedata](), [main-thread](), [reactive](), [rxjava](), [subscription](), [viewmodel]() ### AI overview This tutorial explains LiveData in Android Jetpack, including lifecycle-aware observation, event handling, and use in the data layer. It compares LiveData with RxJava and Kotlin Flow, then describes a reactive RxJava approach for state observation and lifecycle-managed subscriptions. ### Source excerpt Google introduced Jetpack, a family of opinionated libraries to make Android development easier a few years ago. One of the core classes in Jetpack is LiveData - an observable, lifecycle aware data holder. The typical use case is having a ViewModel that exposes LiveData as a property, and observing it from your lifecycle owner, a Fragment or an Activity. A typical usage would look like this: data class MyState(val value: String) class MyViewModel : ViewModel { private val _state = MutableLiveData() val state: LiveData get() = _state } class MyFragment : Fragment { val viewModel by viewModels() override fun onViewCreated() { viewModel.state.observe(this, Observer(::handleState)) } private fun handleState(state: MySate): Unit = TODO() } There are multiple benefits of using LiveData: Your observer is notified when the data changes The observer is only notified of changes when it's active Observers are notified when they become active again, like entering into foreground etc Check the LiveData docs for all benefits. LiveData and Events In situations like showing a Snackbar/dialog or navigating to a different Activity/Fragment the ViewModel also needs to notify the LifecycleOwner. A plain old LiveData doesn't work well here because it caches the last item. As a workaround, in the official Android architecture samples there is a SingleLiveEvent implementation of LiveData. Data Layer But what about the rest of the app? You can use LiveData in your data layer, in fact Room, the persistence library from Jetpack, support LiveData as the return type natively. However while using LiveData across all the layer in the app is possible, it is less than ideal. The operations are always executed on the Main Thread and it comes with limited number of transformation functions compared to RxJava or Flow. To fix this problem LiveData comes with adapters for both RxJava and Flow from KotlinX Coroutines. This means developers can use RxJava or Flow in their d ## Introducing 🌈RainbowCake DevFeed: [Introducing 🌈RainbowCake]() Original publisher: [Read original article]() Author: Márton Braun Published: 2020-06-29T15:00:00Z Content type: release Language: en Sources: [zsmb.co]() Topics: [Android](), [Framework](), [Jetpack](), [Development](), [Coroutines](), [business logic](), [ui]() Tags: [android](), [android-architecture](), [business-logic](), [coroutines](), [development](), [framework](), [jetpack](), [kotlin](), [marton-braun](), [open-source](), [ui](), [viewmodel](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview The article introduces RainbowCake, an Android architecture framework that builds on Jetpack and provides tools and guidance for structuring modern Android applications. It describes layers including Views, ViewModels, Presenters, and Interactors, with goals such as separation of concerns, state management, graceful handling of configuration changes and process death, and background work. ### Source excerpt RainbowCake is an Android architecture framework, providing tools and guidance for building modern Android applications. ## Handling Media Files With MediaFacer Library For Android DevFeed: [Handling Media Files With MediaFacer Library For Android]() Original publisher: [Read original article]() Author: M.N Emmanuel Published: 2020-04-27T07:45:41Z Content type: tutorial Language: en Sources: [Android & Tech News -- Medium]() Topics: [Android](), [Android Library](), [Library](), [Code]() Tags: [android](), [android-app-development](), [android-architecture](), [androiddev](), [code](), [library](), [manifest](), [programming](), [software-development]() ### AI overview This tutorial introduces the MediaFacer Android library for querying media files through MediaStore with less cumbersome code. It discusses Android 10 Scoped Storage, support for internal and external storage, and the permissions required to use the library. ### Source excerpt Querying media content on android with ease using the MediaFacer class library Continue reading on AndroidPub " ## Android CPU, Compilers, D8 & R8 DevFeed: [Android CPU, Compilers, D8 & R8]() Original publisher: [Read original article]() Author: Yonatan (Yoni) Levin Published: 2019-03-18T06:27:24Z Content type: tutorial Language: en Sources: [Stories by Yonatan V. Levin on Medium]() Topics: [Android](), [R8](), [Compiler](), [Gradle](), [cpu](), [C](), [C++](), [Arm](), [x86](), [Qualcomm]() Tags: [android](), [android-architecture](), [android-development](), [androiddev](), [arm](), [bytecode](), [c](), [c-plus-plus](), [compilers](), [cpu](), [development](), [gradle](), [jit](), [qualcomm](), [r8](), [x86]() ### AI overview A tutorial introducing Android CPUs, the JVM, bytecode, the Android build system, AOT and JIT compilation, and Google's R8 compiler improvements. It also discusses CPU architectures and the challenges of compiling native code for different devices. ### Source excerpt Imagine you have an important space mission ahead. You need a spacecraft that won't get you into much trouble on the way. You may opt in a regular YT-1300 freighter. It's popular and you know the basics of its operation. However, you've always dreamed of maneuvering like a pro. You are ready to practice a lot and learn various stuff. Millenium Falcon is what you actually want. But this upgraded spaceship will require that you master it like Han Solo! Lately, I've been inspired by the Google effort to improve compilers, such as the development of R8 or speeding up the Gradle builds. So I guess this is the right time to dig in and talk to you about those improvements. But first, let me guide you through the basics. When you reach the end of this article: You'll know about JVM and its relation to Android. You'll be able to read Bytecode. You'll get an idea of the Android Build System. You'll learn what AOT and JIT stand for and how they are connected to the new R8 compiler. And also a little bit about Star Wars :) So grab a large cup of good coffee, the lightsaber, cookies, and prepare for a read :) CPU & JVM In every device, there is a CPU. It's a tiny thing responsible for every single calculation in your app. In the beginning, the CPU could tackle only with basic math operations such as addition, subtraction, division, and multiplication. Over the years it has evolved into a complex mechanism that can be tailored for specific needs like Image Processing, Audio Decoding with a smart caching mechanism. The most known CPU is Snapdragon by Qualcomm. But there are others. Some of them use the same CPU architecture as Qualcomm, while some don't. And here I say 'Welcome to hell.' If you've ever developed C++/C, you know that your native code should be compiled to every supported CPU architecture: ARM, Arm64, x86, x64, MIPS. As an Android developer, you have to support CPU architectures for all the variety of devices. Basically, this means multiplying your .so files by the ## An Early Look at ViewModel SavedState DevFeed: [An Early Look at ViewModel SavedState]() Original publisher: [Read original article]() Author: Márton Braun Published: 2019-03-14T20:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Android](), [Code](), [Library](), [Kotlin](), [configuration](), [Processes](), [data]() Tags: [android](), [android-architecture](), [code](), [configuration](), [data](), [kotlin](), [library](), [marton-braun](), [process](), [viewmodel](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview A tutorial on the early SavedState support for AndroidX ViewModel, showing how to configure a ViewModel, store and retrieve supported key-value data, and preserve state through process death. ### Source excerpt A quick preview of the new SavedState support for Android Architecture Component ViewModels. ## Building An Application With MVVM DevFeed: [Building An Application With MVVM]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2018-10-28T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Development](), [LineageOS](), [Mobile](), [App]() Tags: [android](), [android-architecture](), [android-development](), [architecture](), [architecture-pattern](), [building](), [patterns]() ### AI overview This tutorial introduces the MVVM architecture pattern for Android application development. It explains the roles of the Model, View, and ViewModel components, including how the ViewModel maintains state, interacts with the data source, and handles relevant business logic. It also compares MVVM's communication flow with MVP. ### Source excerpt This is the second post in what will be an ongoing series to demonstrate a few different architecture patterns that are used for Android development. You can find the code for each of them, often appearing before the blog posts, by following this repo. Give it a star! In our previous post we discussed the MVP architecture for building an app. This time, we're going to check out MVVM. ## Using Android Architecture Components with Firebase Realtime Database (Part 3) DevFeed: [Using Android Architecture Components with Firebase Realtime Database (Part 3)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2017-12-22T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Android](), [Realtime Database](), [Firebase](), [Database]() Tags: [android](), [android-architecture](), [architecture-components](), [best-practices](), [firebase](), [net-conf](), [optimization](), [performance](), [realtime-database](), [threading](), [viewmodel]() ### AI overview This tutorial explains how lifecycle-aware Android Architecture Components work with Firebase Realtime Database. It focuses on LiveData and ViewModel, threading for expensive data manipulation, and the performance cost of removing and re-adding database listeners during Activity configuration changes. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Using Android Architecture Components with Firebase Realtime Database (Part 2) DevFeed: [Using Android Architecture Components with Firebase Realtime Database (Part 2)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2017-12-20T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Realtime Database](), [Firebase](), [Android](), [Database]() Tags: [android](), [android-architecture](), [architecture-components](), [best-practices](), [database](), [firebase](), [realtime](), [realtime-database](), [sdk](), [tutorials]() ### AI overview This tutorial shows how to use Android Architecture Components with Firebase Realtime Database to map database snapshots into application objects and keep database-specific logic out of an Activity. It uses transformations so UI-facing objects are ready for display and the app can later switch database implementations with fewer Activity changes. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Using Android Architecture Components with Firebase Realtime Database (Part 1) DevFeed: [Using Android Architecture Components with Firebase Realtime Database (Part 1)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2017-12-15T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Android](), [Firebase](), [Realtime Database](), [Database](), [SDK]() Tags: [android](), [android-architecture](), [best-practices](), [database](), [firebase](), [memory-leaks](), [realtime](), [realtime-database](), [sdk](), [tutorials](), [unit-tests]() ### AI overview This tutorial series explains how Android Architecture Components can work with Firebase Realtime Database to manage lifecycle-aware data listeners. It describes how this approach can reduce boilerplate, improve testability and readability, and help avoid data and memory leaks. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Doppl Updates - Kevin Galligan DevFeed: [Doppl Updates - Kevin Galligan]() Original publisher: [Read original article]() Published: 2017-10-20T15:31:18Z Content type: release Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [iOS](), [RxJava](), [reactive](), [Mobile](), [Swift](), [Xcode]() Tags: [android](), [android-architecture](), [architecture-components](), [build-system](), [built-by-touchlab](), [code-sharing](), [droidcon](), [framework](), [ios](), [press](), [reactive](), [rxjava](), [swift](), [updates](), [xcode]() ### AI overview Doppl updates include approval of the Droidcon 2017 app on Apple, an iOS project using a reactive architecture with RxJava 2 and Android Architecture components, and updates to those components. The article also describes a simplified Xcode build system and planned documentation assistance from Mark Murphy. ### Source excerpt We've been super busy updating lots of stuff after Droidcon, and since nothing is ever really "done" I wanted to share a few big things... ## Getting Started With Room Persistence Library DevFeed: [Getting Started With Room Persistence Library]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2017-06-10T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Library](), [Persistence](), [Database](), [SQLite](), [Development](), [To-Do]() Tags: [android](), [android-architecture](), [android-development](), [architecture-components](), [code](), [component](), [database](), [dependencies](), [google](), [interface](), [kotlin](), [library](), [list](), [migrations](), [persistence](), [published](), [room](), [rxjava](), [sqlite](), [tutorial]() ### AI overview This tutorial introduces Android's Room Persistence Library, an abstraction layer over SQLite, and demonstrates building a todo list with Room and RxJava. It covers project setup, entities, DAOs, CRUD methods, RxJava integration, and the AppDatabase class. ### Source excerpt This year at Google I/O, the Android team announced Android Architecture Components a combination of new, helpful libraries for Android development. One that particularly interested me was the Room Persistence Library, which is an abstraction layer of SQLite designed to make database access and creation a lot easier. Right off the bat it reminded me of Realm, which I learned about at Droidcon NYC and really admired, so I decided to dive in and build a todo list using Room & RxJava. ## Android Architecture: Introducing Pilot DevFeed: [Android Architecture: Introducing Pilot]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-10-01T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Android](), [mvc](), [Dagger]() Tags: [android](), [android-architecture](), [architecture](), [architectures](), [controllers](), [dagger](), [fragments](), [lifecycle](), [mvc](), [mvvm](), [project](), [repo](), [view]() ### AI overview This article introduces Pilot, a work-in-progress abstract application stack for Android. It discusses managing presenter lifecycles, application flow, data scoping, and architectures based on views or a mix of fragments and views, while relating the approach to MVC, MVP, MVVM, and Dagger custom scopes. ### Source excerpt An abstract application stack for Android Motivation There are some common questions that keep popping up on the interwebs around the current collective thought on Android Architecture. Some of these questions are: What approach can I use to handle my Presenters Lifecycle? How can Presenters control the flow of an application? How can I scope data within my application? What architecture could I use to support a View only based architecture (or a mix of Fragments / Views) ? The above questions are not easy ones to address and by no means am I suggesting the below is the only solution to these common issues. I have started using a simple abstract application stack which for the kind of applications I have been developing allows a clean & structured base for them to sit on top of. This post and supporting repo is definitely a work-in-progress but Im hoping it will spark some discussion which can be fed back into the project so it's something that is useful to others also. I have been tempted to not write anything about this until I have answered all the pending questions I have myself but I feel more may be gained by publishing early and often. It is probably worth mentioning that if you are not currently using some kind of Presenter / Controller / distinct view logic abstraction in your application at present you probably will not have come across (or asked yourself) some of these questions. The same goes for Dagger (& Dagger Custom Scopes) and View only view implementations. If you have been playing with some of this stuff you may find the below more applicable. In this post I will briefly expand on the above questions and introduce the project. Preliminaries A Note on terminology Presenters are all the rage in the Android world at present. Some call them Presenters, Controllers, ViewModels, PassiveView etc and they are used as part of MVC, MVP, MVVM (with DataBinding), MVA etc and all these terms overlap and have differnt meanings and implementations depending on w ## Android Architecture: Introducing Dynamo DevFeed: [Android Architecture: Introducing Dynamo]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-04-03T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Dynamo](), [Library](), [Development](), [Code]() Tags: [android](), [android-architecture](), [app-architecture](), [asynchronous](), [code](), [dynamo](), [libraries](), [lifecycle]() ### AI overview This introductory post presents Dynamo, a small library and wiki for Android application architecture. It focuses on managing application state and asynchronous code, including their interaction with the Android lifecycle, and aims to decouple UI behavior from core application logic. ### Source excerpt Dynamo has been superseded by Pilot Welcome, welcome. Come in, it looks mighty cold out there. The code is laying heavy across the hills, disorder rules the day and the nights are long. We yearn for a day where the suns shines forth once more. This is post #2 of my very short Android Architecture series (can two be a series?). Post #1 was a primer for this post. It contained A brief outline of the problems when defaulting to stock Android architecture. An overview of common general architectural concepts. This post is really a short intro to a small library + Wiki I have created. This library fills an architectural hole which I see in the Android dev world. There is no unified approach to generic Android app architecture and this creates a vacuum which sucks in well meaning devs and results is messy codebases strewn across the land. It is also my reponse to the many MVP blog posts out there, which have really helped me think about this issue but also I have my own take on. Plus, I feel sorry for new Android devs who are turning up later to the party and are overwhealmed by the Android ecosystem and need to get up to speed quickly on what these issues are before even getting to the point of thinking about potential solutions. Some of the issues addressed by this approach are solved by fantastic existing libraries, but again, I think for a large chunk of devs these can be difficult concepts to grasp and get running with. These are mentioned in the projects wiki for further reading. In my experience at least there are two core ideas around the center of most apps codebases. From the codebases I have seen & inherited both ideas seem to have too few brain cycles spent on them. 1. State Most apps and views are state-based however the spaghetti-level that captures the state logic is generally very high. 2. Asynchronous code Pretty much every app involves some asynchronous code. Pretty much every app allows this to touch the Android lifecycle. This always leads to sadness.