06
Sun, Oct
2 New Articles

Building Business Applications for Mobile Devices

Development Tools / Utilities
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Let's examine what needs to be taken into consideration when designing, developing, and managing business applications for mobile devices.

 

These days almost everyone has a mobile device, ranging from iPhone, Android, BlackBerry, Symbian, or Windows phones to tablets such as Apple iPad, Motorola Xoom, or Samsung Galaxy. How do you design mobile applications, and what tools do developers need? Will the existing methodology for application life cycle management be adequate for mobile applications? This article is a primer on designing, developing, and managing business applications for mobile devices and suggests issues to consider.

 

 

Native Mobile Applications

Centralized Browser Applications

Hybrid Browser Applications

Cross-Platform

Least potential for cross-platform portability. Development and testing is needed for each mobile device type and version.

Cross-platform operation, provided the application runs in a browser available on the mobile device.

Cross-platform operation, provided there is a container app available for the mobile devices you wish to use.

Data—External

Yes, when connected.

Yes, when connected, which is the only option.

Yes, when connected.

Data—Local

Yes, local data access.

No local data.

Yes, local data access via the container.

Access to OS and Hardware

Yes, can access OS and hardware such as camera and GPS.

No direct interface, except for services provided by the browser.

No direct interface, except for services provided by the container.

Application Deployment

Requires download to and installation on the mobile device.

No deployment is required, except for a browser (already installed on the device).

Requires download to and installation on the device.

Development Cost

Relatively high, especially when the app needs to run on multiple types of devices.

Relatively low. Development occurs only once, with some additional work to ensure the app works with each browser.

Moderate. Development occurs only once. The additional work is packaging the app into the container and testing it on each mobile device.

Development Tools

Development tools are specific to the mobile device and operating system. Also, programming languages vary, e.g., Android uses Java and iOS uses Objective-C.

No development tools are required for the mobile device. Only Web development tools on the server.

No development tools are required for the mobile device. Developers build the application using Web development tools and use a container to package the app for each device type.

 

To develop an application for multiple types of devices you need to either: (a) Build a native application for each device; (b) Use a multi-platform application framework that generates a native application for each device; (c) Build the application to run in a browser. Building native applications that are portable across platforms can be a lot of work, due to multiple development tools/languages and few standard APIs.

Not Connected

Native applications can operate when the device is not connected to a network, especially when the data the application uses is stored on the device.

Browser applications operate only when the device is connected to a network.

Hybrid browser applications can operate when the device is connected to a network and also when disconnected.

Mobile Devices Are Different

Corporate applications have been around for a long time. They typically run on servers that are mature, reliable, housed in a fixed location, fed with a constant power supply, and have an almost unlimited upgrade capacity (memory, processors, and storage).

 

Mobile devices have been on the market for a relatively short time. They have experienced rapid growth together with constant change in capacity and capability. Mobile devices are many and varied in both manufacturer and operating system. Examples of manufacturers are Apple, HTC, LG, Nokia, RIM, and Samsung. Operating systems include Android (Google), Bada (Samsung), BlackBerry OS (RIM), iOS (Apple), Symbian (Nokia), and Windows Phone (Microsoft).

 

The many combinations of devices and operating systems complicate mobile application development. One of the major obstacles is that development tools for native applications are incompatible across mobile devices. Should you develop for all devices, or just a few, and, if just a few, which ones?

 

These are some of the physical characteristics that make mobile devices different from laptops, desktops, and servers:

  • The screen size is smaller. Therefore, you can't show as much information, and you must provide a simple method for moving around the display area.
  • Keyboards and on-screen touch keypads are small and unsuitable for sustained content creation and data manipulation.
  • Processing power and the duration of operation are limited by battery capacity. Constant polling to a server will quickly drain a battery.
  • Memory capacity and local storage are limited.
  • Communications are slower and uncertain.

Mobile Applications Are Different

The physical characteristics described above suggest that mobile applications need to be small, agile, and focused on discrete tasks to minimize the number of screens, local storage requirements, and communications traffic.

 

Mobile applications can be browser-based, native to the device, or a hybrid of both.

 

Native mobile applications run directly on a mobile device's operating system, are fast, and have access to all hardware features.

 

Native applications can operate connected and disconnected from a network. Several of the features that make mobile devices unique (e.g., location awareness) require a network connection. Building an application that uses these features will need thoughtful design when disconnected operation is a requirement.

 

Native applications that collect data to send to server-based applications and additionally operate in disconnected mode must synchronize the data periodically with the server-based applications. This requirement adds to the complexity of the mobile application.

 

You should use a native application when (a) you need access to hardware features on the mobile device; or (b) the application needs to run in disconnected mode or use local storage; or (c) communication costs are high.

 

Centralized browser applications are typical Web or rich Internet applications. This style of application is server-centric, as the database, business logic, and Web serving is managed by one or more servers. The browser manages the user interface with HTML, JavaScript, and CSS. These applications have no direct interface with the mobile device hardware or operating system, except for services provided by the browser.

 

Browser applications designed for larger screens may "work" on a mobile device, but they become unwieldy when viewed on a small screen. In such cases, you need to design the user interface for a small screen.

 

You should use a centralized browser application when you wish to offer the widest reach across devices with the least development effort.

 

Hybrid browser applications are browser applications packaged into a container (or framework) that is a native application on the mobile device. The browser application runs in the container using HTML, JavaScript, and CSS like a typical browser application. In contrast to server-centric browser applications, hybrid browser applications can run when devices operate in disconnected mode, as the container provides access to local storage.

 

Hybrid browser applications do not require the server-side infrastructure of server-centric browser applications.

 

You should use a hybrid browser application when developers are more skilled with HTML, JavaScript, and CSS than with development tools available for native mobile applications.

Design Considerations

When designing mobile applications, architects must consider the limitations of the device and the effort required from users to perform tasks with the device. Think about how to best use the device resources.

 

Limited local data storage: You should use the centralized browser model for mobile applications that need access to large amounts of data. When disconnected operation is required, minimize and optimize the information that's stored locally. Also, ensure that your application manages out-of-storage conditions.

 

Power constraints: Avoid power-intensive features, such as excessive graphics activity and constant communication with servers. Design for minimal power usage.

 

Reduced memory and processor speed: Design mobile applications that are modular and focused on discrete tasks. Information should be returned to the user in the least possible time, and progress updates should be provided while the user waits for completion of a task.

 

The user experience: Scrolling from screen to screen is confusing, and typing information for long periods on small keyboards is cumbersome. Users expect immediate response from mobile applications, with information that is understandable in one view. Architects should design mobile applications that accomplish one, or at most a few, small discrete tasks. Single-task-focused applications will run quickly, consume less power, and simplify the user interface.

 

Follow the conventions and display rules inherent in the operating system. Also, it's worth reading design guides published by the device manufacturer.

 

Communications and networks: Although wireless communications have increased in speed over the past few years, they offer lower data transfer rates and are less reliable than fixed networks. Wireless networks face variables, such as transmitters and receivers on the device and geographic coverage of mobile networks.

 

A mobile application that expects a synchronous-like connection to a server will fail when reception is intermittent or poor. Continuous polling to servers will drain the battery quickly and may incur excessive communications costs.

 

Design mobile applications to use communications services in short bursts. Network activity should be assigned to a separate thread to avoid locking the user interface and inhibiting other applications.

Your First Mobile App

Once you decide to build applications for mobile devices, how do you choose an appropriate first application? The choice of a mobile application ought to be a business requirement that uses features of the device to gather information and improve business processes. Choose an application that is not mission-critical but will produce a useful business outcome and a realistic development experience.

 

Duplicating existing functionality is the easiest transition into mobile application development, but try to improve on it by taking advantage of the mobile device's features. For example, a restaurant chain can provide a list of locations on its Web site and customers can use their mobile device to view that list. From a business perspective, this functionality provides limited incentive to encourage customers to come to a restaurant. A mobile application with access to the GPS for location awareness may direct the customer to the nearest location, show what's on special, and offer a discount. The extra features are more likely to drive customers to the restaurant chain.

 

The take-away message is to consider how a mobile application can respond to the needs of the user and provide improved service.

Ongoing Management

In addition to issues associated with developing applications for mobile devices, you must plan for the ongoing management of both the mobile devices and applications. Deployment and ongoing management costs will be a significant proportion of the overall cost of mobile applications. Some of the contributing factors are who owns the mobile device, security requirements, information protection, support, configuration and application deployment, and communication costs.

 

Ownership: The first policy to determine is whether the company supplies mobile devices to employees or allows employees to bring their own mobile devices. When a company owns the mobile devices, it can control and lock down device features. With a bring-your-own policy, IT administrators lose control of when operating system upgrades occur and what other applications are installed on the device. You need to weigh the pros and cons of each option as it applies to your context, especially for data security.

 

Security is a primary concern when mobile devices carry sensitive corporate information. Mobile devices are easily lost or stolen. So a security plan must include facilities to remotely destroy or lock information. Two of the tools available are remote wipe and remote lock. Remote wipe is an appropriate action when the company owns the mobile device. However, since remote wipe will remove the employee's personal information as well, that may cause problems. The situation is even more complicated when employees purchase devices that do not have a remote wipe feature.

 

To avoid this problem, do not store corporate information on mobile devices. Instead, use centralized browser applications. The trade-off is that these applications are unavailable when the mobile device is not connected to a network. The sensitivity of the information will determine how drastic a measure you need to take to secure corporate data.

 

Support costs: Mobile applications and mobile devices will increase the workload and cost of IT support. Support costs are likely to be more manageable when IT administrators have control of and can limit the range of devices and operating systems.

 

Deploying applications: Especially in the case of native apps, configuration and application deployment require careful planning to avoid excessive cost and to ensure the current version of an application is in use. The complexity of the deployment task increases with the range of mobile devices and operating system versions a company has to support.

 

Communications and network costs are more predictable when mobile devices operate on unlimited data plans or when using public or private Wi-Fi. However, telecommunications companies seem to be moving away from unlimited data plans and, as a consequence, communication costs may increase. The administrative overhead of examining monthly bills to separate company usage from private usage may be prohibitive. Companies may bear the full communication costs or may determine a policy to reimburse a fixed amount or percentage of the monthly bill.

 

This article is an excerpt of a white paper that can be found at http://www.lansa.com/resources/whitepapers.htm.

Richard Lancaster

Richard Lancaster is Product Manager at LANSA's Product Center in Sydney, Australia.

 

Richard is LANSA's Technology Evangelist with a deep understanding of development and integration technologies on the IBM i, Windows, UNIX, and IBM mainframe platforms. With over 30 years of experience in the technology industry, Richard previously worked as a solutions architect for systems integrators Aspect Computing and the KAZ Group, and he held a range of roles from Computer Operator to Systems Development Manager at various banks and insurance companies.

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: