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.
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:
Our Android app requests the camera to take a photo or video and the Android OS then launches the device's camera app to handle the request.
At this precise point in time your user has actually left the bespoke Android app we developed for you, however, their experience is still seamless (as far as they are concerned they are still on our app).
The device's camera app might allow users to do other tasks (e.g. launching the file chooser) which will launch yet another app.
In the end (i.e. when your user has taken their photo or video), he/she returns to our Android app and can see the photo or video they just took listed on say their job screen.
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:
- Your users don't lose data if the Android operating system destroys your app to free up resources.
- Your app continues to work in cases when a network connection is unreliable or not available.
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.