Mobile internet has increased at a faster rate than desktop internet did. This enormous demand has created new business opportunities to the service providers, handheld producers and independent mobile application developers. The market share of mobile operating systems is growing steadily and more IT applications are developed and deployed on mobile devices, however this also brings a new set of challenges to the application developers. The purpose of this paper is to examine the major mobile application frameworks in terms of technical strengths, interoperability, ease of use, among other factors to determine which one, if any, offers the best alternative to an independent mobile application vendor.
Introduction to Mobile Application Frameworks
Phone software can be defined as a software stack of functional layers, from bottom to top [1]:
The kernel, the core of the software which includes hardware drivers, memory, filesystem and process management.
The middleware layer, the set of peripheral software libraries which enable handset applications, but are not visible to the user. Examples are messaging and communications engines, WAP/web page renderers, multimedia codecs, security subsystem and device management.
The application execution environment (AEE), an application manager and set application programming interfaces (APIs) which allow external developers or manufacturers to develop handset applications.
The user interface (UI) framework, a set of graphics components (screens, buttons, lists, etc) and an interaction framework that gives handset applications their look & feel.
The application suite, the set of core handset applications such as the idle-screen, dialer, application launcher or menu screen, contacts, calendar, inbox, browser shell and settings screens that form the interface that the phone user experiences most of the time.
A mobile application distribution is the complete, integrated stack of software components; from top to bottom that powers a mobile handset. From this, we take the term operating system to mean a pre-integrated software stack that includes the kernel and drivers. The depth of a software stack represents a trade-off between completeness and flexibility, between time-to-market and room to add visible value.
The figure 1.1 visualizes a simplified handset software stack, and gives examples of vendors and products that deliver functionality corresponding to each layer.
Figure 1.1 Simplified mobile software stack
Web-based Mobile Access
Although the potential for the web based delivery of information through to mobile devices has existed for years, it has always been hampered by two factors; primarily, the availability and cost of bandwidth on such devices, but closely followed by the primitiveness of protocol support.
The smart-phone revolution has somewhat addressed both of these issues by forcing the carriers to offer unlimited data plans, and by providing more capable browsers. This new generation of mobile browsers is almost completely compatible with the pages served up for desktop browsers.
Today at least a significant subset of the mobile market can be targeted with generic web sites that have no particular concession to mobile browsing. However, when we move beyond basic information delivery into the enterprise space, it is unlikely that this one-size fits all approach will be successful.
On-Device, Native Mobile Access
Unlike the browser based connected mode of data access, applications that anticipate the need to operate independently from the network, or that need native services access to the device have to be written as targeted applications for a particular device. These applications may be written specifically for that device OS or for a virtual machine or other framework running on it.
The common use cases for this kind of applications are:
• Applications deployed to specialized, often ruggedized industrial mobile devices designed for offline data gathering, for example stock taking or field service applications.
• Mobile workforce applications, for example, sales enablement applications in the insurance and pharmaceutical space, which have traditionally run on commodity laptops. Because the hardware and operating system are standard in these cases, it is possible to re-use certain components from existing enterprise applications or packages for the application. Data synchronization, however, remains as the major challenge.
• Mobile applications that extends Enterprise Applications to mobile users. For example, extending the functionality of a financial application to support expenses reporting and approval for managers, on their mobile devices. Traditionally users of Enterprise Applications are expected to access these types of functionality from their desktop PC.
However, with the general availability of smart-phones and increasingly mobile work forces, users now expect certain Enterprise Application functionality to be accessible from their mobile device.
Traditionally these use cases are mostly supported through a laptop-based device. However, as smart phones and tablets become more powerful and have a richer set of capabilities such as location awareness, they are increasing capable of supporting these use cases. As matter of fact, a new class of mobile application is emerging that requires extensive integration with on-device services such as PIM (calendar, contact, etc) applications, GPS, integrated smartcard/barcode scanner, etc. Such an application allows end-user to seamlessly navigate between multiple mobile applications without losing context, and enables business applications to leverage data gathered/contained by device-native peripherals and services.
Specialty Mobile UIs
This final category of mobile interfaces encapsulates a wide range of use cases. Some of these cases may overlap with the connected / disconnected scenarios which we have already discussed, but today are all implemented as one-off and highly specialized applications. This portfolio of applications types includes:
• Games: Although gaming makes up a significant portion, if not the majority of the mobile market, it is an area which is somewhat outside of this discussion of enhancing enterprise applications with mobility.
• Widgets: In the case of widgets, the developer is tied to specific operating system APIs, as in the case of Android widgets, or to the APIs provided by an add on frameworks such as Yahoo! Widgets. Although widgets are often very small and simple applications, the correct implementation can be challenging, particularly on mobile devices where resources such as memory and CPU cycles need to be used as sparingly as possible.
• Website Implementations: On platforms like the iPhone, there has been an explosion of application development effort around creating specialize applications that implement a portion of website functionality into a native mobile applications. Many examples of this application class exist, everything from the social media application space such as Facebook, LinkedIn and Yelp, to banking and news applications. All of these applications are highly tailored to the form factor and user interaction model of the targeted device, and will almost always have some integration with device services such as GPS or camera. They often surface only a subset of the functionality of the full parent web site. This class of application provides a sticky presence for the vendor on the mobile device, which establishes a more immediate and intimate connection with the user than a simple browser bookmark. As such, the primary driver for creating these applications is not necessarily a functional one but is more of a marketing tool.
• Data Collection Applications: the newer smart-phones are beginning to penetrate into the market formally dominated by specialized industrial devices. Data entry applications using these devices will often be a combined hardware and software combination. An increasingly common example being a point of sale system implemented using a sleeve for a phone which provides both barcode scanning and card reading capabilities.
Smartphone Landscape
Relative to desktop computers, smart phones have a diverse set of operating systems (see Table 1.1). Moreover, unlike desktop operating systems, the OS in mobile computing typically determines the programming language that developers must use.
In the 1990s, a number of cross-platform desktop frameworks emerged, making it easier for companies to develop a single codebase that they could compile for each target platform (typically, just Mac and Windows). For mobile development, this is a much bigger challenge.
Table 1.1 Smartphone Operating Systems and Languages
OS
Symbian
RIM BlackBerry
Apple iPhone
Windows Mobile
Google Android
Palm webOS
Language
C++
Java
Objective-C
C#
Java
Javascript
Even focusing only on smartphones, there are four major operating systems that make up over 90% of the market: Symbian, RIM BlackBerry, Apple iPhone, and Windows Mobile, with the rest of the market shared by Linux and emerging mobile operating systems, Google Android and Palm's webOS. For most of these operating systems, there is a native development language, which is required to develop optimally for that platform, as illustrated in Table 1.1. While it is possible to develop using other languages, typically there are drawbacks or limitations in doing so. For example, you can develop a Java application for Symbian; however, several native APIs are unavailable for accessing device capabilities. Besides the differences in languages, the software development kits (SDKs) and paradigms for developing applications are different across each platform. While the device capabilities are almost identical, such as geolocation (GPS), camera, and contact management, the specific APIs to access these capabilities are different on each platform.
Current Challenges
A mobile operating system, as a mobile platform, has to provide a runtime environment for mobile applications developed by various methodologies, program languages, frameworks, and tools. Nowadays, mobile applications developed in each specific developing environment provided by platform vendors are executed only on each vendor's platform. Assad and Rosa [2] indicate that "The industry needs an open standard to integrate these application models in a device middleware that provides the application' shared components."
In addition, mobile applications have additional characteristics than wireless applications and stationary applications. In order to develop the wireless applications, the wireless device context, the wireless network context, etc. should be considered. Gaitan et al. [3] state "One of the goals of next generation wireless networks refers to the ability of services to be seamlessly transferred between heterogeneous networks." Mobility is the main characteristic by which we can distinguish the mobile applications from the wireless applications. Therefore, Mobile applications should support interoperability and mobility. We can define the interoperability as the ability of applications to be executable across diverse mobile platforms and the mobility as the ability of applications to be seamlessly transferred between heterogeneous networks.
The main problem of the device middleware is that it does not support application mobility. In order to support application mobility, there should be a component related to application mobility that communicates with the server-side component. Assad and Rosa [2] explain "Nowadays, mobile device applications operate in a virtual sandbox that runs each application in a tightly constrained environment. The application does not share code and can't communicate with each other." This means each vendor platform provides a runtime environment for the application developed by a vendor's own developing environment.
With the recent explosion in the smart-phone and mobile device market, much interest is now focused on the possibilities for both improved workflow and revenue streams that may be afforded by this growth area. In the traditional enterprise application development market, standardization has played a major part in streamlining and simplifying the production of enterprise applications. In the mobile space, however, the wide array of incompatible hardware devices and operating systems impose some significant barriers.
Some of the challenges facing developers wanting to work in this space include:
• Wildly differing device capabilities in terms of hardware features and available software APIs.
• A wide range of form factors and screen sizes.
• Variety of input methodologies and user experience expectations; for example devices using multi-touch screens vs. touch-pad driven/non-touch screens.
• Carrier specific constraints and features.
• A large array of mutually exclusive development environments and languages, often tied to specific hardware vendors, for example Objective-C used for Apple devices and Java for most but not all BlackBerry devices.
As a result of the efforts and costs inherent in addressing these challenges, organizations looking to support mobile use cases will often have to severally limit the number of supported platforms and devices.
Challenges in Developing a Mobile Strategy
The range of use cases outlined already has hinted at some of the problems inherent in establishing a common approach for all mobile development within the enterprise. For the connected browser based applications, the promise of single source application delivery is quickly dashed by the inconsistent implementation of web browser standards such as CSS, JavaScript and so forth across devices. However, more significant perhaps is the actual usability of a website designed for a large desktop browser screen on a relativity tiny display. The user will frequently have to scroll just to view the whole screen, and data entry is often painful.
The reality then for this connected mobile application use case is that significant design effort needs to be invested into the presentation of functionality to the user on that specific device. For example a single data entry form on a desktop browser may need to be drastically simplified, split up onto multiple panels or pages, and rearranged to better suit the navigation gestures on the device. Although bandwidth and data consumption is less of an issue than it was, even with 3G/4G/xG phones the download speed is a significant influence on the design and page size, as well as occasionally by lack of local caching.
One traditional approach is to leverage "trans-coding" technique that allows developers to define rules on how to split up a desktop browser page for mobile display. This approach requires the desktop browser page to be mostly static and simple, and relies on a complex and often outdated device database to determine how to split up the page. For the offline-capable and specialty use cases, the significant challenges are around the range of skills needed to create the applications, the problems of provisioning and security, and of course, data synchronization.
Multiple Devices, Multiple Programming Environments
From the development standpoint, the large range of possible mobile devices presents one of the greatest challenges. Each of the major smart-phone families uses different programming languages, APIs and development environment. This factor will generally constrain organizations into supporting only one or two device types with separate pools of highly specialized developers for each.
Proposed Solution: Cross-Platform Frameworks
The fast-growing market for applications drives the need for faster time to market. Just as market opportunities led vendors to release cross-platform applications on desktop computers in the 1990s, mobile applications are more frequently available across devices. Operating systems vendors contend for the attention of developers and application vendors, but improve their tools incrementally. Where such dramatic challenges exist in developing across multiple platforms, it is natural for third party cross-platform frameworks to emerge.
The innovation in cross-platform frameworks for smartphone applications surpasses the patterns of abstraction seen in the cross-platform desktop frameworks of the 1990s. These new smartphone frameworks are influenced by the rapid application development techniques we are seeing in web development today. There are three specific techniques in web application development that are borrowed for these non-web frameworks: 1) layout with mark-up (HTML/CSS); 2) using URLs to identify screen layouts and visual state; and 3) incorporating dynamic languages, such as Javscript, Python or Ruby.
A generation of designers and user interface developers are fluent in HTML and CSS for layout and construction of visual elements. Additionally, addressing each screen by a unique name in a sensible hierarchy with a systemized way of defining connections between them (links and form posts) has created an international and cross-platform language understood by visual and interactions designers, information architects, and programmers alike. This common language and its standard implementation patterns led to the development of frameworks and libraries that significantly speed application development on the Web.
The new cross-platform frameworks leverage these skills using an embedded web browser as the mechanism for displaying application UI. This is combined with a native application that transforms URL requests into the rendering of application screens simulating the web environment in the context of a disconnected mobile application.
New cross-platform smartphone frameworks support a trend where mobile applications, such as web applications, are a branded experience. The Web is a varied, diverse place, where the lines between application functionality, content, and branding blur. Web applications do not express the native operating systems of Mac, Windows, or whatever desktop happens to host the browser. Web applications are liberal with color and graphics, defying the UI conventions of the desktop as well as avoiding the blue underlined links of the early Web.
Most businesses simply can't afford to focus on the niche of a single operating system or device. To reach customers, more companies are developing mobile applications, and the customers they want to reach are divided across the wide array of mobile platforms. Despite the challenges, businesses are driven to communicate with their customers through their mobile phones because of the enormous opportunity presented by such connectedness.
It may be effective shorthand to say that smartphones are the new personal computer; however, in reality they represent a new communications medium.
To provide some perspective on how application interfaces vary across platform, Figures 2 and 3 illustrate how that application is realized across various platforms. This application is not implemented using cross-platform frameworks, but is included to provide context on design decisions made in cross-platform implementation. As you will see the application look quite different from each other, even on the same platform. As is typical, these mobile applications choose a color scheme that is consistent with their brand, rather than adhering to defaults provided by the smartphone operating system.
Figure 2. Facebook Application - Blackberry
Figure 3. Facebook Application - IPhone
In recent years, there has been an explosion of activity in the area of cross-platform as mobile devices become faster and more widely adopted, and particularly with a fast-growing market for applications. These frameworks fall into two categories: those that let you create a native mobile application using cross-platform APIs, and HTML/CSS/Javascript frameworks that let you build cross-platform interfaces that run in a web browser. It is common practice to combine these to create cross-platform native applications.
The rest of this paper will focus on the native cross-platform frameworks of Rhodes, PhoneGap, and Titanium. Additionally, we will cover the open cross-platform alliance called OSGI.
These are listed below along with a number of frameworks [7] that are not covered in detail on this text.
Rhodes and RhoSync from Rhomobile. Use Ruby for cross-platform business logic in this MVC framework and leverage HTML, CSS, and JavaScript for the UI. The optional RhoSync server supports synchronization of client-server data. With Rhodes, you can build applications for iPhone/iPad, Android, BlackBerry, and Windows Mobile. The client framework is MIT License; their RhoSync server framework is GPL with a commercial option.
PhoneGap from Nitobi. Use HTML, CSS, and Javascript along with projects and libraries that support native application development to create applications that run on iPhone/iPad, Android, BlackBerry, Palm, and Symbian. Open-source MIT License. [1]
Titanium Mobile from Appcelerator. Use JavaScript with custom APIs to build native applications for iPhone and Android. Titanium is an open-source framework, released under the Apache 2 license [2] .
QuickConnectFamily. Use HTML, CSS, and JavaScript to build an application that runs on iPhone/iPad, Android, BlackBerry, and WebOS. The QuickConnectFamily templates give you access to behavior normally restricted to "native" apps. You can have full database access across all the supported platforms. [3]
Bedrock from Metismo. A cross compiler converts your J2ME source code to native C++, simultaneously deploying your product to Android, iPhone, BREW, Windows Mobile, and more. Bedrock is a set of proprietary libraries and tools.
Corona. Develop using the Lua scripting language for native iPhone, iPad, and Android apps. Corona is a proprietary framework.
MoSync SDK. Use C or C++ to develop using MoSync libraries to build for Symbian, Windows Mobile, j2me, Moblin, and Android. MoSync is a proprietary framework [4] .
Qt Mobility. Use C++ and Qt APIs to target S60, Windows CE, and Maemo. Qt (pronounced "cute") is a cross-platform application development framework widely used for the development of GUI programs. The Qt mobility project moves it to mobile platforms. It is distributed as open source under the LGPL [5] .
Adobe Flash Lite. Use ActionScript, a JavaScript-like proprietary scripting language, to build cross-platform application files (SWF) that will run as applications on a variety of devices that support Flash Lite. Adobe Flash Lite is a proprietary platform [6] .
Adobe AIR. Adobe is working toward having the full features of Flash Player 10 work across a wide array of mobile devices; however, those efforts seem to be focused on web-based applications rather than native applications. Adobe AIR (as of this writing, in beta for Android) allows developers to run Flash applications outside of the mobile browser as stand-alone applications [7] .
Unity. A popular game development platform which allows you to deploy to Mac, Windows, or iPhone. Unity supports three scripting languages: JavaScript, C#, and a dialect of Python called Boo.
Rhodes
Rhodes is a cross-platform smartphone application framework developed by Rhomobile [8] a venture backed startup in Cupertino, CA. It was released in December of 2008. Rhodes is available for most major smartphones including the iPhone, Research in Motion (BlackBerry), Android, Windows Mobile, and Symbian. A key value proposition for Rhodes is the ability for a company to build and maintain a single code-base across this wide variety of device operating systems.
Rhodes allows developers to create cross-platform smartphone applications using HTML, CSS, JavaScript and Ruby programming languages. It leverages developer experience in web development to make native mobile applications, and is aimed at developers who already have a background in web development and want to create mobile applications without having to learn platform SDKs and the native languages on each mobile device platform. The Rhomobile tools and framework can be used across Mac, Windows and Linux; however, to build for specific devices, the device SDK must be installed. BlackBerry and Windows Mobile devices require Windows; iPhone devices requires Mac; Android and Symbian devices run on Java and are cross-platform.
Rhodes is targeted primarily at enterprise applications. The framework makes it easy to create applications that present a series of screens that include standard UI widgets, including common phone UIs such as mapping. It is not suitable for fast-action games and other such consumer applications with demands for rich interactive graphic interfaces or platform-specific native UI controls. A strength of Rhodes is that it makes the traditional user interface patterns commonly found in most informational applications easy and portable.
Rhodes is a commercially-supported open source product licensed under the MIT License. Those companies requiring commercial grade support can purchase an Enterprise License from Rhomobile. Because Rhodes is open source, you can examine the code and see exactly what it is doing under the covers. You can extend it, contribute improvements and fixes, or customize your own version of Rhodes if you need to.
Rhodes takes much of its inspiration from web-oriented Model-View-Controller (MVC) style frameworks such as Ruby on Rails. However, it has several simplifications, extensions, and optimizations for the mobile scenario.
Rhodes includes a local Object Relational Manager (ORM), called Rhom, and includes code to persist local data and sync remote data using RhoSync. Rhodes developers do not have to worry about writing data storage and sync logic into their applications and can focus instead on presentation and business logic.
Rhodes applications are installed and run as native applications. However, you develop using the web development paradigm. Therefore at runtime, the HTML and CSS is rendered in a native browser UI control that is embedded in your application by the Rhodes framework.
You can also add application logic to your views using embedded Ruby programming language. Rhodes will generate the complete HTML, evaluating the Ruby code before the HTML is rendered by the browser UI Control.
Device Capabilities and Native UI Elements
Rhodes provides access to device-specific capabilities such as GPS, PIM, camera, SMS, video player, accelerometer, proximity detector, and native UI controls. In some cases, the native controls are specific to the device, for example, every BlackBerry application has a menu that is invoked when you click the Berries button on the device; however, iPhone applications do not uniformly have a menu. So when you define a menu it appears on the BlackBerry, but is ignored if you were to build the same code for the iPhone.
Synchronization servers provide the ability for mobile users to access information even when the device is offline or disconnected. They can also dramatically simplify the programming model. Developers can assume the data that they need is available locally in a database instead of writing code to access the network and take apart the data from some wire format.
RhoSync
RhoSync is a new sync server framework concentrating on mobilizing applications exposing web services to smartphones. Like Rhodes, the RhoSync server is open source (but distributed under GPL), providing freedom and flexibility if needed. RhoSync is written in Ruby, but more importantly, connections to back-end services (which are pluggable extensions to RhoSync) are written in Ruby. RhoSync facilitates mobile development by providing a simple way to integrate data from external web services into Rhodes-based smartphone applications. The complexity and lines of code required to connect users to your back-end services are orders of magnitude smaller than the size and effort that has typically been associated with sync projects: for example, a basic RhoSync source adapter requires only 20 lines of easily understandable code.
The RhoSync server acts as a middle tier between a mobile application and the web service that it accesses for remote data. The RhoSync server stores information from back-end systems in its data store as object-attribute-value (OAV) "triples" capable of representing any type of arbitrary data. OAV triples allow small changes between the device and the back end to be communicated back and forth very efficiently. Because RhoSync operates on individual attribute values rather than entire objects, RhoSync handles conflicts elegantly.
Using the RhoSync server framework, you will create an application. An application consists of one or more sources, subclasses of the SourceAdapter class, each of which contains instructions for how the RhoSync server should perform synchronization operations. The source adapter contains the instructions used to populate the data store on the RhoSync server with information from a web service. When a client device synchronizes, the source adapter manages the process used to take data from the device's data store, update its own data store, then populate your back-end system.
The RhoSync server framework also manages user authentication for your application. All client applications connecting to a RhoSync server require authentication. However, if your application does not require users to authenticate individually, you can simply accept all client connections, and automatically authenticate anyone using the application.
PhoneGap
PhoneGap [9] is an open source framework for building native mobile applications using HTML, CSS, and Javascript for iPhone, Android, BlackBerry, Palm webOS, and Symbian WRT (Nokia). PhoneGap is very good for transforming a mobile web application to a native application. It is easy to use for web developers. In order to use PhoneGap, a web developer will need to learn how to build using one or more device SDKs and tools, but all the application code can be HTML, CSS, and JavaScript. In fact, a developer must be fairly expert in JavaScript to take advantage of this platform. Depending on the perspective of the developer, it is a benefit or a drawback that it provides little in the way of design patterns for mobile applications. It will not help you with an application that works off-line, which means it is possible on Android and iPhone with Webkit's Web Storage support,[] but not on BlackBerry (as of this writing).
PhoneGap provides a rich collection of client-side JavaScript APIs with a method for hosting your web application within a native mobile application. PhoneGap is a sponsored project of Nitobi [10] , a software consultancy headquartered in Vancouver BC. The framework started in 2008, and is free to use under an MIT license.
The key advantage of creating a native mobile application with PhoneGap is that you can drop in a mobile web application and build it into a native application that an end user may install (or purchase). As a native application, it can access certain capabilities not available from a web application, such as access to contacts data, geolocation, camera, and accelerometer using PhoneGap's JavaScript APIs.
To create a native application with PhoneGap, you start by writing a mobile web application using HTML, CSS, and Javascript using whatever tools you are most comfortable with. PhoneGap does not require your application to conform to any particular structure, nor does it provide any specific guidance about how to create your app. If you already have an existing mobile web application, you may be able to easily convert it to use in PhoneGap. PhoneGap works particularly well on such platforms as iPhone and Android that include the WebKit browser with the advanced JavaScript and CSS of HTML 5.
In fact, PhoneGap tracks advanced features of HTML 5 and the work of standards bodies such as the W3C Device API Group [11] that defines standards for Javascript APIs for mobile phone features. PhoneGap attempts to implement emerging APIs to interact with device services such as contacts, camera, and so forth today and make them available as part of its framework ahead of these APIs being available in mobile browsers. The goal of PhoneGap is to cease to exist once mobile browsers expose these APIs. A selling point of PhoneGap is that you are not coding to a proprietary API but instead to what may in the future turn out to be W3C standards.
PhoneGap aims to move your device to a nice first class window. It is important to note, that while PhoneGap attempts to be a non-proprietary API and tracks standards from W3C, those standards are not fully developed. PhoneGap exists to bridge the gap between the standard and what is required to build a real application, so it contains APIs that diverge from the standard.
PhoneGap is well-suited for anything anyone could do with a mobile web application. Like all of the cross-platform frameworks that leverage the browser for UI, it is not well-suited for applications that require intense math calculations or multidimensional animations. Neither is it well-suited for developers needing to write data-driven applications, like most enterprise applications, that must work offline using synchronization of local data. PhoneGap does not provide specific database support and relies on HTML5 database APIs for persistence.
The key benefit of being able to package and distribute your mobile web application is that you have a marketplace for your application, such as the Apple App Store, Nokia's OV Store, or Blackberry App World. Your application will then have screen real-estate wherever the phone installs applications and users can typically configure their phone to display the application for quick access.
When running inside PhoneGap, your application can access certain devices capabilities from JavaScript that are not otherwise available to web apps. The PhoneGap API provides access to the following device capabilities: Geolocation, Contacts, Vibration, Accelerometer, Camera, Sound playback, Device information, Click to call.
Titanium Mobile
Titanium is a commercially supported, open source platform for developing native cross-platform applications using web technologies. Source code is released under the Apache 2 license. Appcelerator, Inc. [12] , a startup in Mountain View, CA., introduced the platform in December 2008. Appcelerator has announced and will soon be releasing a version of Titanium Mobile that also works for the BlackBerry.
Titanium consists of an SDK that provides the necessary tools, compilers, and APIs for building for the target platform, and a visual environment for managing your Titanium-based projects called Titanium Developer. Titanium Developer provides a nice visual way to build your projects, but to edit them you will need to use your favorite source code editor. Titanium is available for Mac, Linux and Windows. To develop for the iPhone (or iPad), you will need to run it on Mac using the iPhone SDK. Developing for the Android requires the Android SDK and can be done using Mac, Windows, or Linux.
The Titanium API provides a platform-independent API to access native UI components including navigation bars, menus, dialog boxes, and alerts, and native device functionality including the file system, sound, network, and local database. You code in JavaScript that is compiled into native counterparts as part of the build process.
Titanium offers a free community edition that can be used to build and distribute your applications. Developers can upgrade to the Titanium Professional Edition or the Titanium Enterprise Edition that offers additional support and services. The Titanium web site includes basic documentation and training videos. Developers can pay for advanced videos and sign up for training classes on the Appcelerator web site.
The Titanium API is organized into modules. For example, Titanium.UI is the main UI module responsible for native user-interface components and interaction inside Titanium. Within Titanium UI you will find classes for Titanium.UI.AlertDialog, Titanium.UI.Button, etc. The iPhone/iPad specific UI capabilities are found within the Titanium.UI.iPhone module and the Android specific UI capabilities are found within the Titanium.UI.Android module.
Titanium Mobile Device Capabilities
The Titanium platform offers access to a rich collection of native device capabilities including: Vibration, Geolocation & Mapping, Accelerometer, Sound, Photo Gallery (View and Save To), Orientation, Camera. This includes overlays on top of the camera view surface, and Augmented Reality (combines Camera, forward and reverse Geolocation, Screenshot, Shake, Record Video, Proximity Events and Push Notifications.
These are all accessed in a platform-independent way using the Titanium SDK from JavaScript. Additionally, the platform includes wrappers that make it easy to integrate Twitter, Facebook, RSS, and SOAP APIs directly into your application, plus access to sockets, http connections, the native file system, and local database storage.
The OSGi Alliance Technology
The OSGi technology is a set of specifications that define a dynamic component system for Java [9]. These specifications enable a development model where applications are (dynamically) composed of many different (reusable) components.
The OSGi specifications enable components to hide their implementations from other components while communicating through services, which are objects that are specifically shared between components. This surprisingly simple model has far reaching effects for almost any aspect of the software development process.
Figure 4. The OSGi Layer model.
According to Gábor Pécsy (Co-Chair of the OSGi Mobile expert group), "OSGi is a technology originally created to be the core platform of home gateways, slowly it was adapted in a number of verticals, including automotive industry or enterprise applications. In 2006, Release 4 of OSGi was published, which includes support for mobile phones and other handheld devices. Based on this technology, JSR-232 defines a dynamic, manageable component platform for mobile devices. Nokia eRCP platform, which is available for E90 and some other S60 3.1 devices, is based on JSR-232. The same technology is used by the Sprint Titan platform, for which devices hit the market in 2008."
Pecsy's OSGI and Android Comparison
Both OSGi and Android define a development platform for component-based development and provide an implementation for the service-oriented architecture, within the mobile device.
The key difference between the two platform's service models is the service access. In OSGi, services are lightweight. They are accessed using direct method calls, they are easy and cheap to use. In Android, services are heavyweight. They are accessed using inter-process communication, which makes service access slower and more expensive. In OSGi, services are used extensively and they play a very important role in keeping components lightweight and loosely coupled. In Android, services are coarse grained and will likely be used much less frequently. While in OSGi services can be used as plugins to other applications, in Android they are closer to the traditional web service model.
Another important difference between the two platforms is their grounding on standards. OSGi is a standard that has been developed for ten years and reached a high level of maturity. It has been adopted by a number of JSR in JCP and there are number of independent commercial and open source implementations, optimized for different fields of use. In addition, the OSGi Alliance has very strong backwards compatibility requirements. [13]
Figure 5 Differences between OSGi and Android Models
It is proposed that adopters of OSGi technology see significantly reduced complexity in almost all aspects of development. Code is easier to write and test, reuse is increased, build systems become significantly simpler, deployment is more manageable, bugs are detected early, and the runtime provides an enormous insight into what is running. Most important, it works as is testified by the wide adoption and use in popular applications like Eclipse.
The OSGi mobile specification is the underlying technology in JSR 232, the mobile Java service platform, which was submitted to the JCP by OSGi members Nokia Corporation and Motorola. Mobile OSGi framework implementations are available for all major mobile operating systems including Android, Windows Mobile, Symbian, Brew and Linux.
In summary, the proponents of OSGi argue that Mobile OSGi enables the following use cases [9]:
Programming in a modern, robust, secure, modular, component-based service architecture
Managing software components remotely
Opening innovation on a platform level
Building a new mobile ecosystem for mobile services and APIs
Building portable, cross-platform mobile software
Conclusion
The aim of this paper was to analyze the current branded, independent and cross-platform mobile applications frameworks to try to identify the strengths and weaknesses of the different platforms through a technological and user experience comparative analysis.
There are a handful of successful initiatives like Apple's 'IOS', Google's 'Android', Blackberry's'App Framework' and Windows's 'Windows Phone', among others. In the smartphone market some of the operating systems like iPhone, Android and Blackberry are tightly connected to the business logic of the platforms, with reasonable consumer bases. For these reasons, it would be difficult, to see a winning operating system on the market.
Based on the analysis displayed on this text, the adoption of a cross-platform development framework is the preferable option to the independent software vendor to reduce the development time, cost and reach a greater market share.
