This post was written by one of our architects William.
Mobile is here to stay and offers the growing possibility of new opportunities. Application systems using mobile devices will require an analysis of architectural constraints and further considerations. Let’s take a look.
Mobile devices are small, portable, powerful machines that are usually connected to services. Still, they are limited. They are not for intensive processing. The battery is drained very easily when using features, so care must be taken to reduce resource usage. The bandwidth is limited for communications and has an associated cost too. They have limited display capabilities, memory and storage space. Any design must take these limitations into account.
A system using mobile components may have different configurations. Here are the most common ones and their implications:
- A native, standalone app — These are applications that use the mobile device’s features to its maximum and may not require much communication (internet access).
- A client-server app — These are applications that have part of the functionality in the mobile device, part in a server. They require communication and data transfer.
- A Web App — These are very common, applications written in web. The client in the mobile device is just the browser and all the functionality is on the server.
Depending on the application type, architectural considerations may vary. Also, if the application is created from scratch or if it is a mobile exposure of an old app. The following is a list of issues the architect should check or take into account when creating or adjusting the system architecture.
Communication and data transfer. This is really important when designing the app or when porting a normal app into the mobile world. Communication consumes battery and data transfer has its cost in time and money. It is advisable to keep communication to a minimum. That means aiming for minimalist interfaces on web apps. For client-server, the transferred data should be information (meaning detailed info is “cooked” in server and just the require info is sent to device). Also, review the possibility of using compression. UI should reduce the use of images and other media like video or audio.
Processing. As mentioned, the device is not a super computer. The process design should consider using the device for processing some data under a threshold, or balancing processing and data transfer with a server. Consider a charting example. The chart can be generated in the server and sent as an image, or the server can send the chart data for the device to render the chart, or even send the detailed data for the device to process and render. It depends on the amount of data, the processing power of the device and the load in the server.
Memory. When working with the native part of the app, consider macro elements and static processing. The idea is to minimize the memory use, in terms of space and allocation frequency. Consuming all the memory is one issue, consuming less memory but continuously creating objects and destroying them is also bad.
Security. This is an important issue. Using encryption in communication increases processing. Also, care must be taken when storing credentials in the device or deciding to send the credentials over the air. Consider encryption of stored data. Also consider having data backed up in the server, in case the device is stolen, lost or destroyed.
System interactions. As part of a system, the mobile device may be seen in the architecture as a process or a functional element too. It should be taken into account that the device may be offline at times, or may be lost, in which case the system should keep working, either side. Architecture must contemplate incomplete or “frozen” transactions that may occur when the device fails to complete the steps or takes too long to complete them. It must also consider mobile devices to be disconnected in any moment, and thus there should be ways to recover transactions.
A careful analysis of the goals and possibilities of mobile should be conducted, as the devices will open new possibilities but also post some restrictions and modifications to common architectures. Architect must avoid pitfalls like thinking the current server or apps can be ported as they are directly to mobile, or assuming the load of opening the server to support also mobile is manageable without proper load testing. Finally, any adjustment must be drive tested in the device, as the user experience may cause a project to fail if mobile special issues are not considered.
Every solution is different. That is why these considerations are so general. Each solution should be treated in a special way, based on the current needs.