Developing Mobile Applications


Developing Mobile Applications










PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download.

Developing Mobile Applications

by Lynn Greiner

Copyright 2017, Faulkner
Information Services. All Rights Reserved.

Docid: 00021113

Publication Date: 1709

Report Type: TUTORIAL

Preview

What is the fastest, lowest risk path to IT support for mobile
business processes? The answer: developing mobile apps. Mobilizing
business processes lets you be more responsive to your customers by
empowering frontline employees to innovate, to solve problems as they arise,
and to use time and resources more efficiently.

Report Contents:

Executive Summary

[return to top of this report]

Mobilizing
business processes lets you be more responsive to your customers by
empowering frontline employees to innovate, to solve problems as they arise,
and to use time and resources more efficiently. 

Related
Faulkner Reports
Mobile Enterprise Application
Platforms Tutorial
AJAX Web Development
Techniques Tutorial
Microsoft .NET
Technology
Tutorial

At less than the cost of many business laptops, small, mobile devices like smartphones, tablets or netbooks can host powerful, effective business support
applications which dramatically lower the cost of equipping a mobile
workforce and compress service delivery timelines. However, in several
important ways, developing mobile applications differs from developing
desktop or web applications.   

First, a
variety of devices host mobile apps: Mobile phones, PDAs,
tablets and netbooks (netbooks, however, are virtually obsolete,
supplanted by Ultrabooks) are all considered ‘mobile devices’, in the
sense that they are small, ultra portable and connect easily to
wireless networks.  Depending on which you choose as a host
platform, application development times and costs can vary
dramatically.  In general, phone based development will be most
costly and risky, but apps will enjoy maximum connectivity and ‘always
on’ availability. On the other hand, netbook hosted mobile apps often
benefit from legacy code bases ( Windows or Linux ), which means
deploying good mobile business process support can be accomplished by
porting existing applications’ business logic and retrofitting UI
components appropriate to small screens. Another class of device, the Ultrabook, combines the
battery life and light weight of a netbook with the computing power
and larger screen of a laptop, but it comes at a premium
price. Using this approach, success and cost control are chiefly a
matter of carefully selecting from legacy applications. Depending
on their platform OS, tablets contain the best (or worst) of
both worlds, with the added wrinkle of touchscreens. The best legacy candidates will have most of
these features:

  • Application design uses separation of concerns
  • User experience is not highly dependent on detailed
    graphics

  • Apps can accept asynchronous data updates
  • Full time connectivity is not required
  • Employs a very flat, simple navigation hierarchy
  • Use cases for ambient lighting are known and predictable

Description

[return to top of this report]

There
are three basic approaches to mobilizing business processes:

  • Develop mobile apps entirely from scratch,
    choosing the ideal platform and tools for the project.
  • Use mobile devices to put new
    ‘skin’ on cloud based enterprise infrastructure and assets.
  • Port legacy apps to mobile platforms to
    operate as standalone or connected business process tools.

Developing
platform specific mobile apps from scratch is justified if innovation results
drive your budgeting and staffing.  Think prototyping groups, solution designers, R&D and academic
settings.  Enterprise and
institutional IT groups are better suited to one of the other approaches,
because timeline, budget and results are easier to predict.  In either case, the first step toward
mobilizing the business process concerns choice of mobile platform.

Which ‘Mobile’ Platform?

Perhaps the only broad
brush statement it is easy to make about the mobile device space today is
that it is experiencing a time of turmoil. There are two basic classes of
mobile application platforms: Smartphones and Ultrabooks. Tablets
can be considered large screen smartphones or keyboardless
Ultrabooks, depending on whether they run a phone operating system,
like iPads, or desktop-class OS.  For smartphones, three major
enterprise competitors comprise the short list when selecting a platform for
mobile business apps: Apple, Google, and Microsoft; Apple, Google
and Microsoft all have tablets based on their mobile OS. Microsoft’s Windows Phone OS has not
landed on a tablet, but full Windows 10, with its touch-friendly user
interface, is on multiple devices from both Microsoft and its partners.
Windows 10 is attempting to remedy this, with a single OS traversing PC,
tablet, smartphone, and specialized devices such as HoloLens. However, here are
some caveats:

  • Each vendor uses distinct software architecture. 
  • No single player is strong enough to dominate the niche
    for enterprise smartphones, so it is unlikely that any overarching standards
    will emerge.
    However, Android and iOS have the largest market share; the challenge
    with them is embedding enterprise-friendly features, especially
    security (most Android devices do not receive
    regular security updates from their vendors so are inherently insecure
    to begin with; exceptions are Google Nexus and Pixel, BlackBerry’s Android
    phones, and some Samsung models).

  • Since well over half of all mobile workers choose and
    purchase their own phones, these devices will likely all play a role
    in an enterprise mobile application environment. 

For these reasons, in the
near term, mobilizing business processes using phone based apps comes with
risk that may be unacceptable. In addition, users within an
organization may prefer different, incompatible phone platforms,
requiring multiple development streams to accommodate them.  However,
this still leaves lots of good mobility options in Ultrabook class platforms,
as well as convertible tablets that can be docked to a keyboard.
Netbooks, although durable,
low cost devices that delivered many of the good features of both phones and laptops,
quickly fell out of favor and
have disappeared from store shelves.

In addition, even though
designing and coding for tablet class devices can be very much
‘mobile application development’, a school of software
engineering that is somewhat specialized, it is seldom as arcane as smartphone programming.  More
programmers can do it well, since it is essentially a matter of targeting  versions of Linux or Windows
on devices with small screens.  As a result, labor costs are lower and recruitment is less difficult.

To mitigate this situation, tools are emerging that allow cross-platform
development. Windows 10 apps will span devices, and thanks to Visual Studio 2015
and higher can be developed using the same tools. Microsoft acquired
cross-platform development tool maker Xamarin to allow multiple smartphone OSes
to be targeted using Visual Studio 2015; the tools are integrated into later
versions of Visual Studio

Low Risk Starting Points for Mobile App Development

In many ways, mobile
application development is very different from software development targeting
wall powered devices connected to corporate networks, defended by firewalls
and layers of privacy created by physical facilities’ security. Aside from the demands of
programming for a battery powered, resource constrained, intermittently
connected device, additional  considerations apply:

  • Mobile apps can open security holes in many ways that in-house,
    networked apps do not.

  • Intermittently connected devices can be difficult to
    update and manage.

  • Loss or failure of mobile workflow support tools and
    software can be catastrophic to the business process if there aren’t
    contingency procedures in place.

In short, ultra portable
business tools pose new risks, so it makes sense to start slowly and proceed
incrementally, choosing business processes that are easiest to mobilize, will
probably be the least expensive and will leverage existing expertise, infrastructure
and codebase. 

Start
by defining ‘mobility’ for purposes of achieving the business
objective. When
identifying good candidates for mobile app development, look for business
scenarios where Ultrabooks, smartphones or tablets can contribute something that
standard laptop
computers can’t provide:

  • Lower
    device cost
  • Longer
    battery life
  • Device
    flexibility and customization opportunities
  • Touchscreen functionality
  • Ultra
    portability contributes to productivity, profitability or service levels

Porting
legacy code or skinning cloud services using a tablet or Ultrabook as a viewer will
probably be cheaper, faster and subject to less life cycle obsolescence than
targeting a particular smartphone. Increasingly, Windows tablet class devices are built on
Intel’s Core processors (or occasionally
Atom), which are directly compatible with the
world’s largest code base, the x86
legacy, and Ultrabooks contain the latest Intel Core processors. 
This means that, in many cases, enterprise and institutional IT
strategists looking to extend the reach and flexibility of existing
business process tools and support will need to have good reasons not
to target Intel powered devices, or to take
advantage of the computing power and long battery life of an Ultrabook.

  • Existing client components of client/ server apps will, in many
    cases, port easily to tablets
    or Ultrabooks, given
    appropriate UI modifications
  • Both Linux and Microsoft OS apps offer a mature, robust, fully integrated security model,
    making them enterprise ready mobilization platforms.
  • Extensive reuse of existing
    code and security models translates to accelerated mobile app
    development cycles, reduced testing costs and rapid deployments.
  • Porting proven x86 legacy
    apps is the most fiscally conservative path for mobilizing business
    processes.

Targeting a smartphone platform
will provide ubiquitous connectivity, allows for scheduled updates and
maintenance and allows for ‘push’ content distribution. 
While tablets
and Ultrabooks are an ideal solution
for achieving business process mobilization where instantaneous communication
isn’t always critical, they often fall short in one respect: Ubiquitous,
instantaneous connectivity.  Only
a smartphone (some tablets and Ultrabooks offer
cellular connectivity as an option) can provide a computing platform that also offers immediate, one
touch access to the world phone network.  Some mobilization strategies demand this kind of immediate “always
on, always connected” availability:  Think market reporting and trading,
emergency response, live negotiations and field operation coordination and
control.

Current
View

[return to top of this report]

It All
Comes Down to Power Management

After the strategic decisions are made about what business
processes to target for mobilization and what app development architecture
best matches the needs of the given scenario, it’s time to write ( or possibly
rewrite) some mobile application code.  Whether the project is a tabula rasa, fresh start or a port of tried
and true legacy code, and whether the device is a smartphone,
tablet, or Ultrabook,
the one big difference between mobile app development and any other kind is
this:  Batteries.

Mobile applications must use power sparingly and wisely.
The rules for accomplishing this, thankfully, are simple and general.  The same techniques and coding
practices that stretch the life of a smartphone battery apply as well to
tablets and Ultrabooks.  Being conversant in
these will help IT managers intelligently guide the application requirements
and specification process.  Here
are the key things to know about battery powered devices as application
platforms:

Certain application behaviors that are standard
practice on the desktop are inappropriate to battery powered devices.  Specifically, any application that
keeps the processor from stepping down to idle state is prohibitively
power-expensive. A good example of this behavior is where a client repeatedly
polls a server to request updates.  The client must set a timer; repeatedly check the timer to see
when  to poll the server;  and at polling time, send a stream of
queries which usually provides nothing useful in response.  In addition, the client has to open,
manage and close the connection to the server.  A mostly fruitless process like this
one is called ‘spinning’ the CPU, and while it isn’t
particularly harmful in a wall powered application, it will dramatically
reduce battery life in a mobile device.  Explained in this way, this is an obvious example, but programmers
without small device or embedded systems experience have to master many power
management subtleties to deliver usable mobile tools.  Here are some best practices for coding
to small, mobile battery powered devices.

If dynamic update is required, it is much more
power efficient to set the process up as a “push” from the server
end than as a “pull” from the client end.  Define procedures that ensure timely update of tablet
and Ultrabook based mobile apps.

Use all device hardware resources conservatively.  Powering the antenna, running the
processor, and drawing the display are the biggest power consumers.  Design apps to operate in an
unconnected state, and you may be able to double battery life.  Limit screen backlighting to as low a
level as possible.  If the app is
used in poor ambient lighting conditions or glare, this may be difficult to
enforce, although some newer devices contain ambient light sensors
that compensate for lighting conditions automatically.  Do big connected jobs
like downloads as quickly as possible in order to step the processor down to
a lower power state.

If the application uses images, do everything
possible to reduce file sizes.  Doing so
reduces image load times, and local storage overhead, which in turn improves
power performance.  Many good open
source utilities do this job.  .

Where possible, use optimized vector graphics
instead of bitmaps. Bitmapped graphics may not produce aesthetically pleasing images when
simplified and scaled down to the extent necessary for very small
screens.  Also, locally caching
bitmap images can tremendously inflate local storage overhead.  Though optimized vector graphics must
be redrawn every time they display, they result in more
“readable” image display for users and can readily be scaled to
fit on the visible portion of screen.

Unroll loops if they are deterministic.  Most business logic code is full of
do-while constructs, or “loops”.  Loop code performs the same job over
and over again, for example reading all of the user input from the fields of
a form.  If the exact number of
times a task is going to happen is known in advance, the loop is said to be
‘deterministic’. Loop code is commonly used both because it is convenient and
because it tends to prevent errors due to typos. “Loop unrolling”
means that instead of using the shorthand for ‘do a job x times
then stop’, there are actually x instances of the implementing
code. Most optimizing compilers have a switch you can set to achieve this
result transparently.  While
loop unrolling produces larger code, it reduces the processor utilization
significantly. Loop unrolling reduces the number of instructions executed by a given
passage of object code by up to one half.

Use integer math instead of floating point math. When evaluating code for
porting, analyze all numeric data structures to see where you can eliminate
the use of floating point data.  Integers require far less storage and incur much less processing
overhead, creating both power consumption and runtime performance wins.

In addition, be conscious of operations that could be expensive from a
connectivity point of view. Whether it is a smartphone, a tablet, or an
Ultrabook, if it is connected to a cellular network, large transfers can be
costly. Apps should, where possible, detect whether they’re connected via
cellular or WiFi, and give users the option to defer network-intense operations
until they’re connected via WiFi.

Outlook

[return to top of this report]

The slow consolidation around programming standards for smartphones is reflective
of the fact that the mobile application space is in a state of very rapid
evolution. Microsoft has taken steps to unify Windows programming
across devices with Visual Studio 2015 and up and Windows 10, as has Apple, with its new Swift programming language
for iOS and OS X, but both are newer initiatives. In addition,
cross-platform tools such as Xamarin, now owned by
Microsoft and incorporated into Visual Studio, allow developers
to create apps
for multiple OSes with much less effort.

In contrast to
laptops, which are basically first cousins of wall powered computers, mobile
devices are defining new lifestyles and workstyles.  Taking this into account when
architecting business solutions requires thinking about application design in
new ways and taking advantage of new capabilities and opportunities.

  • Location awareness can
    change, influence and enhance mobile business opportunities    .  It can also profoundly increase
    service levels, and provide important tool for building business
    relationships. However, its use must be tempered by awareness
    of applicable privacy legislation.
  • Use onboard camera,
    microphone and speakers     to improve and enrich communication among team
    members, and use built-in sensors gather data and intelligence from the field and connect with
    customers. Again, sensitivity to privacy is
    key.
  • Design applications to be
    interruptible    .  Mobile business processes are
    inherently intermittent. Structure the user experience in a way that
    allows working as much or as little as desired, gracefully resuming
    where they left off or lost connectivity. 
  • Consider changing screen
    orientation    .  Most tablet screens are too
    short to display a typical web page well, and users find it extremely
    frustrating to have to scroll a portion of a page into view in order to
    use the content.  Develop
    strategies for portrait mode screen layouts, using mouse or touch pad to
    control application behavior. Accommodate devices
    that can change orientation on the fly, simply by turning the
    device.
  • Leverage the devices’ touch
    capabilities.     With any keyboardless device, the user
    interface needs to be designed to accommodate fingers of
    all sizes. This means bigger buttons, and possibly use
    of an onscreen soft keyboard for text entry.
    Developers should accommodate convertible devices which may offer
    both keyboard and touch interactions.
  • Design for the modern environment. Today’s
    users need to access the same apps on smartphones and tablets and
    Ultrabooks; devices with different-sized screens and different
    capabilities. Apps need to adapt to the device on which they’re
    used.
  • Include security and privacy in the
    design    . No app can be properly secured, or respect user
    privacy, if these considerations are afterthoughts. They must be
    included in the design of the app from the beginning to be
    effective.

Recommendations

[return to top of this report]

The
temptation to dive in, target low cost mobile devices, and reap big benefits
is huge.  A fast port of
‘low hanging fruit’ mobile business solutions is not unrealistic,
given careful choice of porting candidates and proper respect for the real
differences between the UI of a typical desktop computer, and that of a small
screen, battery powered mobile device.  Before selecting mobile app development candidates from an
existing codebase, ask this question:

Does
the legacy code implement separation of concerns, so that user facing
elements can be cleanly detached from business process logic and backend
infrastructure?  In a best case scenario, well
chosen legacy code will port cleanly to a mobile device if it rigorously
observes separation of concerns.  If the  presentation
layer is completely separate from business logic, making necessary
modifications to the UI will be far simpler and faster. Vendors such
as Citrix offer software development kits to help developers create
mobile user interfaces for legacy apps.

Also, recognize that there are very real cognitive differences
between a small screen like that of a smart phone, or tablet and a large one, like on a desktop or
standard laptop, and between devices with touch input, and those with
keyboards. Physiologically
and psychologically, people see these differently, and mobile UI designs must
take this into account to provide a good user experience and useful business
tools. 

A successful mobile app UI must:

  • Display only what the user needs to see, but all of what
    they need to see

  • Keep controls visible on the screen at all times by coding
    their positions relative to an edge or center point

  • Adhere to the
    UI conventions of the mobile OS in use to avoid user confusion

  • For mobile apps that target more than one platform,
    establish and enforce a minimum screen size, or adapt the user
    interface to be suitable to available screen real estate. Merely
    shrinking the display will not work; the UI has to be rethought.

  • Take into account the cognitive effects of small screens,
    including slowed rates of reading, reduced reading comprehension; and
    tendency for users to become lost in hierarchical navigation.

  • Don’t assume that components such as autoplay
    videos will be practical or desirable; give users the choice of
    viewing such bandwidth-heavy items.

[return to top of this report]

About the Author

[return to top of this report]

Lynn Greiner is Vice President, Technical Services
for a division of a multi-national corporation, and also an award-winning
computer industry journalist. Ms. Greiner is a regular contributor to
Faulkner Information Services and a member of the Advisor Panel.

[return to
top
of this report]