Google issues Android app architecture guide to Android app developers
(14 December 2021)

Other recent news...

Google Announces Flutter for Windows
Flutter 2.10 enables the development of high-quality Windows apps that also run as native apps on Android and iOS devices as well as web platforms - all from the same codebase!
4 February 2022
Docker supporting COVID-19 genomic monitoring
The efficient nature of Docker containerisation has transformed how public health disease monitoring is performed and grown the scale of the viral monitoring effort.
26 January 2022
Google launches new Bumblebee version of Android Studio
Android Studio is the officially supported IDE for developing Android apps and building app packages for installation on Android devices.
25 January 2022
Google issues Android app architecture guide to Android app developers
New Media Aid have been Android app developers since 2009, when the Android OS was first launched. Our Android app development team, with decades of software engineering experience, knows that an app should always be developed to allow the app to scale up to many more users than was first envisaged when the client first asked New Media Aid to develop a bespoke Android app for them. Google just released their Android app architecture best practice guide to help Android app developers choose the correct architecture for the Android apps they are developing.

Getting an app's foundations right from the outset is essential to improving the bespoke Android app's quality, scalability, robustness, and make it easier to test. Our Android app development team will use a robust app architecture that defines the boundaries between parts of the Android app and the responsibilities each part should have. Our Android app developers therefore use a "separation of concerns" principle when planning the app architecture for your bespoke Android app. Separation of concerns (SoC) is a design principle for separating a computer program (in this case a bespoke Android app) into distinct parts where each part addresses a separate concern (e.g. defined functionality). This also facilitates code maintenance for our Android app development team.

Mobile devices have limited memory (e.g. little CPU compared to a PC) so at any time the Android operating system might kill some app processes to make room for new ones and therefore our Android app development team will code your bespoke app so no application data is kept in memory or session state in case these events are destroyed by the operating system.

As seasoned app developers, New Media Aid uses industry best practice by applying a three-layer architecture to your custom-made Android app: UI layer, domain layer and data layer.

UI layer
The UI (user interface) layer displays your Android application data on the screen and is also the main point of interaction with your app's users. Whenever data changes, e.g. due to user interaction (swiping a screen or pressing a button) or due to external input (data updating from a cloud API), the UI should update to reflect those changes. The UI layer is a pretty visual representation of app state data retrieved from the domain layer.

Domain layer
The domain layer is the layer that sits between the UI layer and the data layer and holds the complex business logic and algorithms coded by New Media Aid's Android app development team. By using a domain layer our Android app engineers can avoid code duplication and improve the testability of the app thereby making the initial Android app development cost lower as well as reducing the cost of maintaining the app (e.g. enhancing functionality) as the code can be used on multiple screens and share information between different parts of the app.

Data layer
The data layer contains the Android application's data and generic business logic not held in the above domain layer. This determines how application data must be created, stored and changed in your bespoke Android app developed by New Media Aid. The data layer will deal with things like:
  • Making network requests: e.g. pushing or pulling data from a cloud API
  • Saving and retrieving data from disk: e.g. saving data for offline use and allowing querying in a local SQLite database so users can use the app even without an internet connection
  • Scheduling tasks using WorkManager: e.g. allow the Android app to fetch data from a cloud API regularly and automatically under defined conditions, perhaps only when connected to WiFi and not via a data SIM to avoid data charges

more news...