# Android Architecture: Runtime Centric Thinking

DevFeed: [Android Architecture: Runtime Centric Thinking](<https://devfeed.tech/articles/android-architecture-runtime-centric-thinking-26034.md>)

Original publisher: [Read original article](<http://doridori.github.io//Android-Architecture-Runtime/>)

Author: SystemDotRun

Published: 2021-11-08T00:00:00Z

Content type: opinion

Language: en

Sources: [SystemDotRun](<https://devfeed.tech/sources/systemdotrun.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Test automation](<https://devfeed.tech/topics/test-automation.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-architecture](<https://devfeed.tech/tags/android-architecture.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [production](<https://devfeed.tech/tags/production.md>), [test-automation](<https://devfeed.tech/tags/test-automation.md>)

## 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