Android App Architecture

As opposed to classic desktop apps (think Word and Excel before Office 365), which open their default opening screen from the Start menu or desktop icon and then run as a single process, an Android app tends to contain many different components such as activities, services and broadcast receivers which we declare in the Android app's "manifest" file and it is the actual Android operating system which uses this manifest file to decide how best to integrate your app into the phone/tablet user experience.
Android App Architecture
For example, let's say your field engineer is using one of the bespoke Android apps we have developed for you and as part of the workflow he/she needs to take a photo or video which will be saved to that particular job - the steps for the Android operating system to deal with this scenario would be similar to:

At any point during the above process the user could be interrupted by a phone call or notification. After acting upon this interruption, the user expects to be able to return to, and resume, this photo/ video taking process. This app-hopping behaviour is very common so the bespoke Android app we develop for you must handle these flows correctly.

Bear in mind that Android phones and tablets have limited memory so at any time the Android operating system could kill some app processes to make room for new ones.

Given these conditions it's highly possible for various app components to be launched individually or out-of-order and the operating system (or indeed the user) could destroy them at any time. Because these events aren't under our control, we do not store any app data or state in the app components and neither do we allow app components to depend on each other.

Separation of Concerns

In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, so that each section addresses a separate concern (a concern being a set of information that affects the code of a computer program).

Unfortunately it is still very common (especially with novice developers) to write all their programming code in a User Interface UI class (e.g. an Activity or Fragment), however, these classes should only contain the logic that handles UI and operating system interactions as otherwise you risk encountering lifecycle-related problems. For example, because of low memory the Android operating system could destroy a UI Activity or Fragment and therefore it is important that the app's main logic does not depend on these UI classes.

UI Managed by Model

Models are components that are used for handling the app's data. They are independent from the other UI app components and therefore unaffected by the app's lifecycle. Ideally we should use a persistent model for the following reasons:

By basing the bespoke Android apps we develop on model classes with well-defined responsibility for the management of data, the Android apps we develop are both more testable and robust.