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

Other recent news...

Microsoft highlights .NET 8 Hardware Intrinsics features
Additional hardware functionality via APIs so the bespoke web apps we develop can take advantage of users' underlying hardware, e.g. WebAssembly support so that core algorithms can...
11 December 2023
Google launches Gemini AI model
Gemini was designed for flexibility, so it can run on everything from data centres to mobile devices. It's been optimized for three different sizes: Ultra, Pro and Nano (for on-dev...
6 December 2023
Apple launches release candidate versions of iOS 17.2 & iPadOS 17.2
Developing and testing our bespoke Apple iOS apps on beta versions of iOS 17.2 & iPadOS 17.2 allows our app developers to confirm that the apps we develop will work as expected...
5 December 2023
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...