These days almost everyone has one or more mobile devices, ranging from Smartphones to tablets. From a business perspective, widespread use of mobile devices is useful, as it allows immediate access to information for employees who work remotely and/or travel frequently. Customers also have easy access to information about products and services.
While the “App Stores” offer thousands of mobile applications, employees need mobile applications that will integrate with line-of-business (LOB) applications and unstructured information. Mobile applications built for customers, must help them in their relationship with the company by informing them about the status of purchases, providing information about products and allowing customers to ask questions or place orders.
Developers who work with RPG or COBOL on IBM i servers will find building applications for mobile devices a very different experience. Mobile devices are smaller, operate on a limited power supply, store much less data on the device and human interaction is touch. The devices have additional capabilities including cameras, location awareness and gyroscopes. Mobile applications can be browser based, native to the mobile device, or a hybrid of both. Native applications written for mobile devices don’t use RPG or COBOL as the development language, and the device constraints require different application architectures and design principles.
What’s different about mobile devices?
To understand the differences between 5250 and mobile applications, we need to compare the characteristics of the servers that run 5250 applications and the devices on which mobile applications run.
IBM i servers and 5250 applications
The IBM i has had several name changes, but the way applications work has remained much the same for 20 years. The servers are mature, stable, reliable, housed in a fixed location, fed with a constant power supply — and have an almost unlimited upgrade capacity.
Text-based 5250 applications operate in a stable environment and run in a way that prevents users from interfering with the application. They control the database, business logic and user interface. Users may operate the applications, but have no control over how or where the applications run. In addition, 5250 applications can close gracefully when a user shuts down a terminal or emulation session unexpectedly.
Mobile devices
Mobile devices have been on the market for a relatively short time, and have experienced rapid growth in numbers — together with constant change in capacity and capability. In contrast to the IBM i, mobile devices are many and varied in both manufacturer and operating system. On mobile devices the user is in control.
The significant differences between 5250 and mobile applications are:
| Screen size | The screen area is smaller than laptop and desktop devices. The implication is that applications can show less information in one view. |
| Touch | Users interact with mobile devices by touch, where different gestures control actions like scrolling and selecting. |
| Keyboard | Keyboards are small or are on-screen touch keypads, unsuitable for sustained content creation and data manipulation. |
| Power | Battery capacity limits the processing power and the period of operation. A mobile application that uses constant polling to a server will quickly drain a battery. |
| Storage | Memory capacity and storage is limited when compared with IBM i servers. |
| Communications | The bandwidth of mobile connections is less than fixed-line connections; the network latency is longer and availability is variable. |
All of these factors suggest that mobile applications need to be small, agile and focused on discrete tasks — minimising the number of screens, local storage requirements and communications traffic.
Architecture and design considerations
The following suggestions will help to reorient your approach to application architecture from a mindset that expects almost unlimited resources, to more modest and constrained resources available on mobile devices. When designing applications for mobile devices, architects must consider the limits of the devices and the effort required from users to perform tasks. Don’t transfer a server or desktop application to a mobile application; instead think about how best to use the resources on mobile devices.
Storing information on mobile devices
The storage capacity on servers, desktop and laptop computers is large. Mobile devices offer limited storage capacity. Use the centralised browser application design pattern for mobile applications that need access to large amounts of information. For applications that operate when disconnected, optimise information stored on the mobile device and ensure that your application monitors and manages out-of-storage conditions.
Coping with power constraints
Mobile devices have a limited power supply and batteries will discharge quickly when mobile applications use power-intensive features of the mobile device. Examples are heavy processor use, excessive graphics activity and constant communication with servers over 4G networks. Design mobile applications so that they minimise power usage.
Designing for reduced memory and processor speed
Complex applications requiring a large memory and high-speed processors will produce a less than acceptable performance. Design mobile applications that are modular and focus on discrete tasks. Every second counts, so mobile applications should return information to the user in the least possible time, and also provide updates on progress when users have to wait while an application completes a task.
The user experience
The screen size of mobile devices limits the information mobile applications can display. Scrolling from screen to screen can become confusing with a large number of screens. Typing information for long periods on small keyboards is both cumbersome and tiring. Mobile device users expect immediate response from mobile applications, with information that is understandable in one view.
Architects ought to design mobile applications that accomplish one, or a few, discrete tasks. Small mobile applications with the minimum number of steps in a task will run quickly, consume less power and simplify designing the user interface.
To make your mobile applications easy to use, follow the conventions and display rules inherent in the operating system on mobile devices. It’s worth reading design guides published by manufacturers, and following their advice will produce a better user experience from your mobile application.
Communications and networks
Design mobile applications to use communications services in short bursts and avoid extended sessions. Network activity should be assigned to a separate thread to avoid locking the user interface and inhibiting other applications.
Mobile device management
A discussion of issues about deploying mobile applications, version management, device management and how to secure corporate data on mobile devices is a story for another day.
How to decide what the first application will do?
Once you decide to build applications for mobile devices, how do you choose an appropriate first application? One idea is to build the “Hello World” application. While this application may see a quick result, it does little to help business activity — and its simplicity will not enhance developers’ knowledge about building applications for mobile devices. The choice of a mobile application ought to be a business requirement that uses features of mobile devices to gather new information and/or improve business processes. Choose an application that is not mission-critical, but will produce a useful business outcome – this choice will also provide developers with a more realistic development experience.
The take-out message is to think about how a mobile application can do more than a 5250 or web application — responding to the needs of the device owner and providing an improved customer service.
