Chapter Three

Mobile Development Frameworks

and Tools

Asrat Mulatu (PhD)

2020
 Outline
• Introduction
• Fully Centralized and Client-Server Frameworks
and Tools
• Mobile Operating Systems and Virtual Machines
• Case studies
– Java
– BREW
– Windows CE
– WAP
– Symbian EPOC

Asrat M. (PhD)
 Introduction
• It is fair to say that most of the development tools and
frameworks today are designed to facilitate writing
software for stationary and non mobile systems.
• Developing for mobile or non-mobile applications
includes similar processes of requirements gathering,
design, implementation, and testing.
• But, we repeat the question, “Can we or can we not
use the same methodologies, frameworks, and tools
for mobile application development?”
• The answer is more of a “Yes” as the software gets
closer to the hardware and more of a “No” as it gets
farther from the hardware.

Asrat M. (PhD)
• The frameworks that help us when writing software
that is “closer” to the hardware such as compilers and
assemblers focus on easing the process of
programming granular tasks such as moving bits and
bytes between memory locations and performing
additions, subtractions, and multiplications; these are
all very basic operations when looking at software
applications from the bird’s-eye view.
• However, high-level frameworks and tools such as user
interface development tools (HTML, JFC, Visual Basic,
etc.) and other component development tools
(COM/DCOM, EJB, etc.) that try to solve high-level
business logic problems do not lend themselves well to
mobile application development.
• The layers of abstraction in most of today’s frameworks
and tools have been done with a strong bias toward
developing software for stationary applications.
Asrat M. (PhD)
• These tools do not take into account the concerns,
mentioned in Chapter 2, that make mobile software
development inherently different from software
development for stationary systems.
• Frameworks and tools for mobile application development
are evolving based on the growth of architectural
techniques and innovations that accommodate the
dimensions of mobility.
• Although the purpose of any significant tool and framework
used in mobile application development should be to
reduce the complexity of the mobile application, all tools,
regardless of their implementations, attempt to address
the same issues.
• However, depending on the architectures that each may
support, their implementation and usage significantly vary.
• Therefore, it makes sense to create the taxonomy of these
tools based on the architectures.

Asrat M. (PhD)
Fully Centralized Frameworks and Tools
• Developing fully centralized mobile applications
differs from other fully centralized applications by
virtue of QOS, limited power supply, active
transactions, and location awareness.
• Fully centralized mobile applications typically
have custom-designed clients to perform specific
tasks.
• So, the user interface on the devices used to
access the centralized system is optimized to the
task being performed.
• The software on such devices is typically
embedded in nature and is designed to do only
one thing.

Asrat M. (PhD)
• Also, because of this embedded nature of fully
centralized mobile systems, resources of the device are
not a concern in software development:
– The abilities of the client are known beforehand.
• Platform proliferation, once again for the same reason,
is not a concern:
– Software systems in fully centralized mobile systems are all
about the software on the fully centralized host; the client
devices are dumb with little or no ability to perform
dynamic computing tasks and what little software exists on
them is embedded.
• Therefore, three of the dimensions of mobility, namely
– Platform proliferation,
– limited device capabilities, and
– support for a variety of user interfaces—do not apply to
fully centralized applications.

Asrat M. (PhD)
• Location sensitivity, in most fully centralized
systems, is achieved as an integral part of the
network system or hardware-based location
information on the client device (such as GPS
modules).
• The application at the central host as well as the
embedded software on the client must be
designed with QOS issues in mind.
• Because all of the software on the device is
embedded, the module handling the
communications piece can be considered tightly
coupled to the other modules on the client;
therefore, taking into account that QOS issues
become natural.

Asrat M. (PhD)
• In summary, fully centralized mobile applications
are about a monolithic layer of software from the
client to the server with very little software on
the client.
• What software resides on the client is typically
embedded, or at least highly coupled to the
device, in nature.
• Fully centralized mobile applications are the right
solutions for applications that require little to no
flexibility in changing the requirements of the
client over the lifetime of the application and that
have large development and deployment budgets
allowing for custom-designed hardware and
embedded software.

Asrat M. (PhD)
 N-Tier Client–Server Frameworks and Tools
• As discussed in chapter 2, client–server architectures allow us
to enable communication between two applications with one
application acting as the server and the other acting as the
client.
• For mobile applications, the server may have special needs, but
it is typically powerful enough to run a wide range of
applications.
• For mobile applications, there may be special logic that treats
the dimensions of mobility.
• Client applications, in the case of mobile development, are
typically those being run on mobile devices.
• Writing large applications for the devices to serve as the client
is typically not possible, primarily because of the limited
resources on the devices and the large variety of them.
• So, more often than not, mobile applications are distributed.
• The state of the art in proven distributed computing systems
are the N-tier client–server architectures.
Asrat M. (PhD)
• One of basic problems of application
development that is magnified in mobile
environments is code portability and mobility.
• The varieties of the so-called platforms
(combination of hardware and operating
systems) have prompted the creation of tools
and frameworks such as Sun’s Java Virtual
Machine and Microsoft’s Common Language
Run-time.
• The primary goal of these tools is to give code
more portability across platforms.
Asrat M. (PhD)
• The problem is magnified when considering the added factors that the
variety of mobile devices dwarfs the variety among PC and server
operating systems, that virtual machines tend to be large and require
lots of memory and CPU cycles, and that, once more, they are designed
primarily with the primary task of designing applications for stationary
computing systems.
• Here, there are two factors that are inherently opposite in nature.
• First, we need a layer of software, be it a virtual machine or otherwise,
that abstracts us away from the specificity of hardware.
• This is the only practical way to write software rapidly for mobile
systems.
• But then, as software layers are added, performance is hampered and
system requirements go up.
• This tension between these diametrically opposed factors has given rise
to the creation of numerous frameworks and tools for mobile
application design.
• More than ever, selection of the frameworks and tools depends on the
requirements of the application.

Asrat M. (PhD)
• We can address this problem in three ways:
1) Thin-Client Wireless Client–Server
• We can have some homogeneous browser
specifications and implement the browsers for each
device in a client–server environment.
• The browser can then load markup code and render it
or even load plug-ins.
• This approach would be similar to the Web-model
approach where the browsers are implemented for a
variety of operating systems so that Web developers do
not have to worry about the environment in which
those browsers run.
• this would require a persistent and stable connection to
the network and only allow for the lowest common
denominator feature set among the various platforms
and devices.
Asrat M. (PhD)
 » So, at least today, this model is implemented by having
different families of devices and platforms with one
corresponding browser for each.
• Such tools and techniques focus on building a server-
side structure that serves up the right type of markup
language to the browser that interprets it on the client.
– The Wireless Access Protocol (WAP) and its user
interface markup language of WML give us a
framework for building thin-client wireless
applications with an N-tier client–server
architecture.

Asrat M. (PhD)
2) Thick-Client Wireless Client–Server
• The client application on the mobile device may be a custom
application.
• If so, this thick client may communicate with the server, with
the client executing some tasks and the server executing the
others.
• Stationary client–server architectures using thick clients
typically use the client as a means of storing a small subset
of the data for use of the application when disconnected
from the network and performing business logic that does
not need to be centralized.
• Having thick clients for mobile devices is a bit more difficult.
• For one thing, as we have mentioned time and time again,
mobile devices have very restricted resources.
• There are those who say that Moore’s Law will eventually
eliminate any practical restrictions that affect the application
developer; however, there are other problems.

Asrat M. (PhD)
• There is the deployment and provisioning problem:
– How do you distribute software to such a wide range devices?
– How do you even write software for such a large variety of
platforms?
• The platforms that allow thick-client development for
mobile devices address this in two ways:
a) Some provide an operating system or a virtual machine that
provides the application programmers with a platform that lessens the
number of permutations for writing code.
– J2ME (Java 2 Micro Edition) allows this through a small virtual
machine that sits on top of the hardware (or the operating system
that is run on the hardware).
– Microsoft requires an installation of some flavor of Windows on the
device (such as Windows CE) that allows the application
programmer to write programs for Windows.
– Symbian also provides an operating system for mobile devices.

Asrat M. (PhD)
 b) Hardware manufacturers, such as Qualcomm and Texas
Instruments, provide programming environments directly on top of
hardware (ASIC, EEPROM, etc.).
• Qualcomm’s BREW a typical example for this.
3) Stand-alone Applications
• Lastly, we can build stand-alone applications for the devices using
those same platforms that we mentioned for the thick-client
client server-based systems.
• The only difference here is that stand-alone applications do not
really need networking components.
• For example, many of the first applications for the Palm operating
system were only downloadable through the cradle that attaches
the Palm to the serial port of the device.
• From there, you can download an application and run it with no
network connectivity.
• Building stand-alone mobile applications is somewhat of a
novelty as the mobile user needs to be able to at least
synchronize the application with some external system
periodically. Asrat M. (PhD)
• But, in the mobile world, the manufacturer’s of
devices want to differentiate their hardware from
their competitors.
• One way of doing this is by allowing the
developers to write programs very specific to the
device platforms in platform-specific languages
such as C or C++, as in the case of BREW and
BREW-like environments.

• The figure in next slide shows some of the more

popular platforms and their ability to provide
functionality based on connectivity to the
network.
Asrat M. (PhD)
Some Products in Various Categories of N-Tier Client-
Server Frameworks and Solutions.
Asrat M. (PhD)
• Today’s popular operating systems allow applications
to be written without a lot of low-level programming to
access hardware.
• Platforms like Qualcomm’s BREW present another
alternative in writing applications for the device.
• Apache’s Cocoon project and IBM’s Wireless
Transcoding Publisher – are another family of tools and
frameworks written to handle processing of data on
the server and communicating with a wide variety of
devices.
• Java offers an open and relatively mature environment
to program in the same language on any platform
making it cross-platform.
• Microsoft included such features in its Windows .NET
and CE technologies making them cross-language.

Asrat M. (PhD)
Application Development Environments and Frameworks
Asrat M. (PhD)
 Mobile Operating Systems and Virtual
Machines
• A mobile operating system is an operating system
for mobile phones, tablets, smart watches, 2-in-1
PCs (that can be convert to a laptop mode or detach
and work as a tablet mode) or other mobile devices.
• Google Android OS is the most popular open-source
software created by Android, Inc.
• If you have an android phone, you are familiar with
the Google Play (formerly known as Android
Market) where you can download ranges of apps for
free or for a fee.
• It is estimated to have 700 000 apps registered
there.

Asrat M. (PhD)
• Next to Android comes the iOS mobile
operating software. Is proprietary and used
primarily for Apple smartphones.
• The following table shows mobile operating
system market share worldwide from till
January 2020.
OS Type Market Share
Android 74.3%
iOS 24.76%
KaiOS 0.21%
Samsung 0.2%
Unknown 0.19%
Windows 0.12%
Asrat M. (PhD)
Asrat M. (PhD)
 Case Studies
– Java
– BREW
– Windows CE
– WAP
– Symbian EPOC

Asrat M. (PhD)