A case study on the viability of cross-platform mobile ...krogstie/project-reports/2010/Ubiquity-juell.pdfA case study on the viability of cross-platform mobile ... save time otherwise

Project UbiquityA case study on the viability of cross-platform mobile development

Martin Andreas Juell

Norges Teknisk-Naturvitenskapelige Universitet

Abstract

This report seeks to assess whether using a cross-platform mobile development tool is

a viable alternative to traditional mobile application development for Inspera AS, a

Norwegian software company that makes cross-media publishing tools geared towards

education. Based on input from Inspera, it outlines a series of criteria for selecting

the optimal framework to use, focusing on development language, supported phone

capabilities, and appealing UI controls. A series of di�erent alternatives are reviewed,

and Appcelerator Titanium is eventually selected as the optimal choice. Titanium is

then used to develop a prototype, a mobile application for Creaza.com, one of Inspera's

major current projects. Both the development process and the completed application

are then compared to native development, providing both an Android developer's

perspective and that of a web developer, with little experience in mobile development.

As it turns out, cross-platform development tools can save vast amounts of time

in several ways. Not only does the developer not have to develop one version for

each platform, but he could also save time otherwise spent learning a required new

programming language. In addition, some often implemented functionality is also very

easily available in Titanium, possibly saving even more time. The main drawbacks are

feature set, debuggability, and dependence on the framework used.

The last part of the report readresses the question of platform choice, in light of the

experience gained from prototype development in Titanium and the surfacing of Adobe

AIR for mobile devices, seeing bene�ts to di�erent approaches, and recommending

several for further experimentation, particularly AIR, which is a great �t for Inspera.

i

Preface

This report is a documentation of work performed as a specialization projectin computer science in the fall of 2010 by Martin Andreas Juell. The projectis completed in the �rst term of the �nal year of the 5-year integrated MScprogram in Computer Science at the Norwegian University of Technology andScience (NTNU), and its scope is 15 units (half of the normal workload for halfan academic year).

The assignment has been de�ned in cooperation with Inspera AS and super-visor John Krogstie at the department of Computer and Information Science(IDI). The project examines various aspects of cross-platform mobile develop-ment in general, and Appcelerator Titanium speci�cally, an attempt to de-termine to what extent Inspera can bene�t from using these tools. In a veryfragmented market of mobile devices and platforms, harnessing these tools couldbe a critical factor in market survival, and they could lower the cost for smallbusinesses to enter the application scene.

I extend my thanks to my supervisors at Inspera, Sondre Bjørnebekk, BjørnRustberggard and John Arne Skjervold Pedersen, as well as my supervisor atIDI, John Krogstie, for providing invaluable feedback throughout the writingprocess.

ii

Contents

1 Background and objective . . . . . . . . . . . . . . . . . . . . . . 11.1 The problem with platforms . . . . . . . . . . . . . . . . . . . . . 11.2 Inspera AS, Inspera Content Server and Creaza . . . . . . . . . . 11.3 Objective of project . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Outline of report . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Choice of platform . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Final Consideration . . . . . . . . . . . . . . . . . . . . . . . . . 103 Development work . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1 Prototype: Creaza for Titanium . . . . . . . . . . . . . . . . . . . 113.2 Inspera Content Server API . . . . . . . . . . . . . . . . . . . . . 144 Di�erences in Development Process . . . . . . . . . . . . . . . . . 154.1 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Debugging and Testing . . . . . . . . . . . . . . . . . . . . . . . . 174.3 Overall Time Spent . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Di�erences in Completed Application . . . . . . . . . . . . . . . . 206 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.1 Choice of platform revisited . . . . . . . . . . . . . . . . . . . . . 217 Conclusions and future work . . . . . . . . . . . . . . . . . . . . 26References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27A Key Android terms explained . . . . . . . . . . . . . . . . . . . . 28

iii

iv

List of Figures

1 The Camden Fringe, developed in PhoneGap for iPhone and An-droid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Existing Creaza application for Android . . . . . . . . . . . . . . 113 Creaza prototype implemented in Titanium . . . . . . . . . . . . 134 Error message generated by Titanium . . . . . . . . . . . . . . . 185 Log output generated after closing of the Gallery picker activ-

ity, before starting an actual upload, showing large amounts ofmemory being allocated, forcing garbage collection several times. 20

6 Orbium, a game developed in PhoneGap. Available for iOS, An-droid and Palm. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7 ExplorAmaze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

v

Abbreviations

AIR Adobe Integrated Runtime

AJAX Asynchronous Javascript And XML

AMF Adobe Message Format

API Application Programming Interface

ARM Advanced RISC Machine

AS Aksjeselskap (Limited Company)

ASP Active Server Pages

BREW Binary Runtime Environment for Wireless

CMS Content Management System

CSS Cascading Style Sheets

DSL Domain-Speci�c Language

GPS Global Positioning System

GTK+ Gimp ToolKit

GUI Graphical User Interface

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IDE Integrated Development Environment

IDI Institutt for Datateknikk og Informasjonsvitenskap (Department of Com-puter and Information Science)

J2ME Java 2 Micro Edition

JS JavaScript

JSON JavaScript Object Notation

MDA Model-Driven Architecture

MXML Macromedia eXtensible Markup Language

NTNU Norsk Teknisk-Naturvitenskapelig Universitet (Norwegian University ofTechnology and Science)

OS Operating System

OSS Open Source Software

PIM Platform-Independent Model

PHP Hypertext Preprocessor

vi

PSP PlayStation Portable

REST Representational State Transfer

RIA Rich Internet Application

RISC Reduced Instruction Set Computer

RIM Research In Motion (Makers of the BlackBerry)

SD Secure Digital

SDK Software Development Kit

SOAP Simple Object Access Protocol

UI User Interface

URL Uniform Resource Locator

XML eXtensible Markup Language

XSL eXtensible Stylesheet Language

XSLT XSL Transformation

1 Background and objective 1

1 Background and objective

1.1 The problem with platforms

Sophisticated portable devices capable of running third party applications (e.g.smartphones) are rapidly becoming widespread, and the market for such appli-cations has matured. However, these devices operate on vastly di�ering plat-forms, and to develop an application for iOS, Android, Palm WebOS, WindowsMobile, Symbian OS, Samsung Bada, and BlackBerry, one must write the sameapplication seven times, and maintain all seven codebases separately. Expensesrelated to development, testing, bug �xing and maintaining security can quicklyoutweigh the value the application provides.

The concept of platform fragmentation and the desire to develop softwareacross the boundaries that are set by each platform was not born with mobiledevices. Operating systems and programming languages for conventional com-puters also di�er substantially, both in terms of syntax and features, and bestpractices tend to vary. [7] One general way to mitigate this is by using a model-driven architecture (MDA). The MDA approach is based around expressing thefunctionality of software as a platform-independent model (PIM), written in aformal, domain-speci�c language (DSL). Using standardized, platform-speci�crules and tools, the PIM is then translated into platform-speci�c models in acomputer-assisted process. The aim is to increase software quality, developmentspeed, portability and reusability. [14]

Modern desktop applications wanting to reach both the Mac OS, Linuxand Windows platforms have the same problem, and can solve it in severalways. Using a programming language like Java leverages the fact that almostall necessary platform adjustments are done in the Java implementation foreach platform, and the application developer does not have to think much aboutthem. One example of such an application is Eclipse (www.eclipse.org), the IDEused for development in this project. Another approach is to use a languagelike C or C++ for development, and either make manual adjustments for eachplatform or use libraries that present some generic functionality to the developer,and handle the implementation speci�cs di�erently for each platform. One suchlibrary is GTK+ (www.gtk.org), a multi-platform user interface library used inmany open-source applications, such as the vector drawing program Inkscape(www.inkscape.org).

Mobile platforms often use di�erent programming languages, but there aresoftware kits available that let developers write one codebase in a meta-language,and then build this code into applications for several di�erent platforms. Someparticular components may still have to be developed speci�cally on a per-platform basis, but there is still great potential to save on development andmaintenance time and costs. There are several di�erent approaches to how thiscan be done, which will be discussed in section 2.

1.2 Inspera AS, Inspera Content Server and Creaza

This project is conducted in collaboration with Inspera AS, a Norwegian technol-ogy company that makes cross-media publishing tools geared towards education.Inspera has a variety of customers and projects, however they are all based onInspera's key product, Inspera Content Server. Inspera CS is a web-based soft-


ware platform built to handle and present rich media for use in education andcommunication. Content is stored in an XML format, independently of its use.This allows great �exibility in composition and presentation. Content can becombined hierarchically, forming structures, virtual documents containing sev-eral elements of potentially di�erent types. This approach can handle a varietyof di�erent types of content, including portals, learning materials, tests and ex-ercises, documentation, promotional materials, presentations and publications.Its current uses include Nasjonale prøver (national standardized aptitude testsfor all school children in Norway), Lokus (e-learning portal for Aschehoug, amajor Norwegian publisher), and Creaza (explained below). Inspera anticipatesincreasing demand for mobile applications in future projects, and would bene�tgreatly from having one standard framework for devices to communicate withthe system.

Creaza (www.creaza.com) is a suite of web-based creative tools directed atstorytelling. It features a sophisticated timeline based video editor, an audioeditor, a mind mapping tool, and a cartoon creation tool. It is directed towardseducation, and comes with a rich library of media that users can mix withtheir own content to create video, soundscapes, and cartoons. It is marketedtoward learners, and a signi�cant portion of the content can be related to schoolcurriculum in subjects like history and geography.

1.3 Objective of project

The objective of this project is to determine the viability of developing Inspera'sfuture mobile applications using a cross-platform mobile development toolkit. Itdetails the development of a proof-of-concept prototype application using cross-platform tools, and then tries to assess how great the time- and e�ort-savingadvantages of using these tools are. It also examines whether there is a substan-tial di�erence in the quality of the generated device code versus handwrittencode and whether there is a noticeable di�erence in performance, stability, andoverall user experience. If cross-platform tools prove to be valuable, then a gen-eral framework can be built based on the application-independent componentsof the application. This can form the basis for future applications, reducingthe amount of application-speci�c code as well as that of platform-speci�c code.If successful, this would minimize development and maintenance costs, whileallowing rapid protoyping, development and deployment of new applications.

1.4 Outline of report

• Section 2 addresses the challenge of determining what tool to use basedon a set of criteria, and also �nding the set of criteria that will best suitInspera.

• Section 3 details the prototype implemented as well as the changes madeto the server side to accommodate this and future projects.

• Sections 4 and 5 describe the di�erences and tradeo�s between native andcross-platform development.

• Section 6 revisits the question of platform choice, and discusses the conse-quences of choosing (or not choosing) to develop mobile applications using


multiplatform tools.

2 Choice of platform 4

2 Choice of platform

One of the most critical choices one must make when attempting cross-platformdevelopment is the decision of what tool to use. As there is no o�cial registryof what tools are available for this task, a list of what were perceived to bethe best and most widely known frameworks was assembled using web searchesand reading articles. After constructing a list of criteria, a quick evaluation ofeach candidate was performed in order to narrow the �eld, followed by a deeperanalysis of the top contenders.

2.1 Criteria

A good cross-platform framework should have the following properties:

• Support for several platforms

� Android and iOS support is a necessity

� BlackBerry RIM, Palm, and Windows Mobile support is bene�cial,or might be required, depending on target market

� Any further platforms supported can also be useful. (BREW, Sam-sung Bada, Nokia Maemo, Symbian OS)

• Should produce applications that are appealing and easy to use

• Should support phone features, the most prominent of which are:

� Media capabilities

� Camera

� Accelerometer

� Geolocation

� Vibration

� Contacts

• Should produce code of comparable quality to native apps with regard toperformance, stability, and resource usage.

• All other things equal, a free (or cheap) alternative is better than a costlyone, and an open source alternative would be better than a proprietaryone.

In addition, to speci�cally suit Inspera, the tools should:

• Allow Inspera's developers to write apps in a language they are somewhatfamiliar with

� HTML/CSS/Javascript is OK

� Flex is OK

� Java is OK

� Most other languages are unfavorable.

• It is bene�cial if code from desktop/web applications can be reused inmobile applications

� Flex: Would allow reuse, to an undetermined extent, of code in RIAs,such as Creaza's MovieEditor, Cartoonist, and ExplorAmaze.

� HTML/CSS/Javascript: Would allow reuse, to some extent, of webcomponents.

� Java: Might allow some reuse, although Java is mostly used on theserver side.

� Most other languages are not a good choice in this regard.

• Allow the produced applications to look branded and polished, while main-taining consistency with each platform (i.e. the apps should not look likeweb pages or apps for another platform).

2.2 Reviews

Table 1 contains a quick comparison of the frameworks examined. Because ofthe nature of the assignment, a number of the candidates were not analyzeddeeply, due to biases in the criteria making them very unlikely to be selectedfor the task. These will only be mentioned in brief at the end of this section,along with the reason why they were disregarded from consideration early.

PhoneGap

PhoneGap allows a developer to use web standards (HTML5/CSS/JS) to de-velop for a variety of mobile platforms. It uses a native WebView on each plat-form, and displays the application UI inside that view. TheWebView is wrappedinside a PhoneGap container which allows access to native phone features viaJavascript calls, combining the familiarity, versatility, and wide deployability ofweb apps with the extended functionality of mobile apps. It is open source, andhas received a lot of praise from reviewers. This sounded promising to someextent, however, given the focus on nativity in the criteria, it seemed necessaryto test a couple of sample apps in order to judge whether there was a signi�-cant di�erence in user experience. The PhoneGap showcase contained mainlyiOS apps, however there were two applications that were built for Android, andavailable in Norway1. Of the two apps tested (on Android), one (Mavericks)looked like a web page and the other (the Camden Fringe) like an iPhone ap-plication (Fig. 1). The Camden Fringe also used the Android hyperlink-stylefocus and pushdown e�ects on buttons (rather than button-style), and the backbutton quit the application entirely, rather than moving back one level as isthe standard on Android. On iOS, this is normal behavior, and iPhone usersexpect to use the back button the application provides to navigate inside theapplication, but to an Android user this is unnatural. This might be somethinga skilled PhoneGap developer with more attention to Android might be able

1 At the time of testing, only free applications were available on the Android Market in

Norway. Orbium, which is mentioned later, costs 10 SEK and was not available during eval-

uation.

5


Tool Platforms Language Look &Feel

Phonefeatures

License

PhoneGap All major HTML/CSS/ JS

Web-like Acc, Geo,Vib, Cam,Sound,Contacts

OSS

MoSync All major+ more

C/C++ Unknown Geo,Cam,Sound

Free forOSS use,commerciallicensesavailable

OpenPlug Mostmajor (noRIM)

Flex Decent Most Proprietary,expensive

RhoMobile All major HTML/ JS /Ruby

Prettygood

Most/All Free forOSS use,commerciallicensesavailable

Titanium iOS, An-droid,(WinMo+ RIM indev)

HTML5/CSS/ JS

Like na-tive

Most/All OSS, paidplans avail-able

WidgetPad �Smart-phones�

HTML5/CSS/ JS

Unknown Unknown Free

BedRock/Metismo

All major,NintendoDS, PSP

Java/J2ME

Intendedforgames

Unknown Unknown

AirPlay All major C++ CustomUI kit(looksgood)

Unknown Unknown

AlcheMo Mostmajor (noRIM)

J2ME Unknown Most Unknown

MotherApp Android,iOS, RIM

CustomHTML

Native,appeal-ing

Cam,Geo, etc.

Unknown

Tab. 1: Overview of the frameworks examined


(a) iPhone-like menus displaying on An-

droid

(b) Android hyperlink-style focus e�ect on

the iPhone-style top menu bar

Fig. 1: The Camden Fringe, developed in PhoneGap for iPhone and Android

to get around, but it was still considered a detriment. PhoneGap does not ac-commodate Inspera in their desire for a native experience, but remains a viableoption.

Appcelerator/Titanium

Titanium, like PhoneGap, uses HTML/CSS/Javascript2 as its development lan-guage, however there are a few key di�erences between the two. The developershave put a lot of e�ort into making the apps feel native, even with customized UIcontrols, and judging by the example apps and videos posted on their website,they have been quite successful. Rather than using a web view to simply displaythe web code, it features a Javascript-to-native bridge, which maps UI elementsand Javascript calls to native APIs, creating a user experience that appears tobe indistinguishable from one written natively. Titanium also features out-of-the-box support for services such as Facebook, Yahoo, Twitter, Maps, and email,as well as a built-in analytics tool, and support for SOAP and RESTful webservices. Its major weakness is that it only supports Android and iPhone/Padat the moment, however APIs for BlackBerry RIM and Windows Mobile arein development. According to www.appcelerator.com on December 9th, 2010,

2 Current versions of Titanium use Javascript almost exclusively.


Titanium has almost 90,000 registered developers, who create over 1,000 newapps monthly.

OpenPlug

OpenPlug uses Flex (MXML and ActionScript 3) as its metalanguage, whichis desirable for Inspera, who use Flex heavily to create rich web applications.A framework that uses Flex would allow reuse of Flex code in releasing theseapplications for mobile devices such as the iPad. It would also allow Inspera'sFlex developers to develop mobile apps the way they develop web and AdobeAIR apps, using Flex Builder with the OpenPlug plug-in. It supports a varietyof operating systems, devices and features, and generates decent-looking GUIcontrols. One of the reasons OpenPlug was considered a top contender earlyon was because Apple has no plans to let Flash run on its mobile devices theway it runs on computers[13]. Before September 9, 2010, there were also strictguidelines on what apps were allowed to be published to the app store. Applesaid they would not allow apps whose code was created with a translation tool,unless they had explicitly approved that tool. During the �nal consideration ofthe frameworks, Apple relaxed these restrictions[11], and shortly after, Adobeannounced[10] that it would resume development of a tool to translate Flashand AIR applications to native iOS code. This means that Inspera's Flash/Flexdevelopers would be able to use this tool to deploy Flash-based applications toiOS regardless of which platform was chosen. On September 1st, 2010, Open-Plug was acquired by Alcatel-Lucent. It is not clear what this would mean forInspera if they chose OpenPlug as their framework.

Adobe Flash/Flex/AIR

In October 2010, Adobe launched a new version of its Flex SDK and FlashBuilder, dubbed �Hero� and �Burrito�, respectively. This release is intended toallow developers to use Flex to develop for mobile devices the same way theycan currently develop for the browser and desktop (using Adobe IntegratedRuntime, AIR). This approach requires the AIR runtime to be installed on thetarget device, which is currently only available for Android. Adobe has saidother platforms will be supported in the future[2]. �Hero� and �Burrito� werenot available during the consideration phase of this project, and as a resultwas not considered as a development tool for the prototype. However, Adobe'splatform does bring great promise for cross-platform applications. ChristianCantrell at adobe has demonstraed its potential in a demo titled �One app, �vescreens�[1]. It uses the AIR runtime for mobile devices, the packager for iOS,the AIR desktop runtime and Flash player to make the same ActionScript coderun on the desktop in Windows, MacOS and Linux, a browser, and also as appson the Android, iPad, and iPhone.

RhoMobile/Rhodes

Among the ones tested, the Rhodes platform is the only one that uses Ruby.RhoMobile has created a unique set of tools including a sync server (RhoSync)for synchronizing data and accessing it while o�ine. It supports a wide varietyof phone features, and its generated UIs look fairly appealing. For Inspera,


the choice of language is a deal breaker, however, organizations with Rubydevelopers might want to look into using Rhodes.

WidgetPad

WidgetPad is a �collaborative development environment for developers to de-velop fully-interactive, stand-alone, downloadable Smartphone applications inHTML5, CSS3 and Javascript�. All project management, source code edit-ing, debugging, collaboration, versioning and even distribution is done in thebrowser. This is intriguing, but not what Inspera is looking for.

BedRock/Metismo

Metismo is a tool heavily directed towards game development, and featuressuch as native-feeling GUI do not seem to be prioritized. This, coupled withthe slightly poor choice of language and the many other options available led toMetismo being cut from consideration relatively early on.

AirPlay

AirPlay is an intriguing option. It features a sophisticated UI framework, com-piles to native ARM code for performance, supports a wide variety of platforms,and features a simulator that runs on the desktop, but responds to touch/ac-celerometer/other events from a physical device. However, coding in C++ willnot be practical for Inspera.

AlcheMo

The sales pitch on AlcheMo's website primarily brags about AlcheMo's abilityto port existing J2ME applications to modern smartphone platforms. Thereis not much detailed info regarding what its generated GUIs look like. J2MEseems like a relatively poor choice of language for a company with no legacyJ2ME applications to port. With no samples available and many other goodcandidates, AlcheMo was not chosen.

MoSync

MoSync uses C++ as its development language and because of the bias againstC++ in the criteria and the plentiful supply of other options, it was not chosen.It did, however, look like an excellent choice for an organization that uses C++in its projects.

MotherApp

MotherApp is di�erent from all the other tools in its methodology. The de-veloper creates a version of his website that produces MotherApp compatibleHTML (The actual source could be PHP, Java, Ruby, ASP, etc). Then, Mother-App will read the HTML from its server, generate and compile the source foreach platform in its cloud, and deliver the binaries to the developer (The binariescommunicate with the developer's website, not at all with MotherApp once theyare completed). This is an original twist, however, the developer not having any


control over the compilation, generated source, and tool chain is de�nitely sub-optimal. If MotherApp becomes hugely popular, its communication channelsmight congest completely and its ability to handle requests from developers willdrop to unacceptable standards (In order to obtain a binary, developers have tocontact MotherApp via their contact form, which seems unpractical).

2.3 Final Consideration

Of the ten frameworks considered, all that did not use either web technologiesor Flash/Flex as their metalanguage were eliminated as candidates, as none ofthem seemed to o�er anything of enough value to Inspera to warrant the dis-advantage brought about by the language choice. In addition, WidgetPad andMotherApp were dropped from consideration as they did not provide enoughcontrol over the source code and the processes applied to it. PhoneGap mighthave been the winner for another organization, however, when compared along-side Titanium, it became clear that PhoneGap's strengths were wide platformsupport and HTML5 features, while Titanium o�ered native interaction. Sincenative interaction was more of a priority, PhoneGap was dropped from consid-eration as well.

On the Flash-based side, OpenPlug lost a lot of its appeal. While it doessupport Windows Mobile and Symbian OS and none of the others do, it is anextra proprietary layer on top of Adobe Flex, which would soon be viable byitself. Also, OpenPlug PRO costs ¿1399 a year, OpenPlug PREMIUM costs¿3499[12], and the free version of OpenPlug includes an advertisement bannerin applications.

In the end, Titanium was selected. It is free and open source, and thus easyto experiment with. It has an active community, promises great user interactionwith little e�ort, and is based on open web technologies. However, to learn aboutthe potential of AIR as a mobile development tool, Inspera's �ash developerslater started piloting AIR mobile development in a separate project.

3 Development work 11

(a) Dashboard (b) Upload screen

Fig. 2: Existing Creaza application for Android

3 Development work

This chapter describes the development of the prototype applications with ac-companying API changes.

3.1 Prototype: Creaza for Titanium

Inspera is just getting into mobile applications, and the �rst and only applicationproject that is underway is an Android application for Creaza.com (Fig. 2).The app's primary purpose is to allow a user to upload �les from their phoneto their Creaza account, and allow users to view completed productions fromtheir account on their phone, making Creaza more ubiquitous. The goal ofthe prototype is to create an alternative written in Titanium. The Androidapplication has been under development for quite some time, leverages a numberof Android speci�c features, and it is not desirable to make a complete copy ofit. The goal of the prototyping, however, is to probe what the capabilitiesof Titanium are, and what challenges it introduces. Using this approach it isalso a goal to infer something more general about when to use Titanium, ormulti-platform tools in general, and when they should be avoided.

The prototype should contain the same main functionality as the Androidimplementation, but it need not be implemented in the same detail. The maingoals for the original application were that it should allow the user to uploadand download/view content on a device, and the primary goal is to do this onTitanium as well. While it would be natural to compare the two on technical


details, it also makes sense to primarily judge how hard it is to make good enough

functionality, and where applicable, how hard it is to make particularly greatfunctionality where useful. In a real scenario, only one version will be developed,and if it is a cross-platform app that works well enough, the hypothetical featuresof a possibly way more expensive native app might not be missed at all.

The prototype source code is included on a CD-R accompanying the paperedition of this text. During development and testing, the app was run on aGoogle Nexus One, accessing an instance of Inspera Content Server runninglocally on the development machine using 802.11g Wi-Fi. Since the changesto the API on which the app depends have not been deployed to any otherenvironment, and may never be in their exact current form, the application hasnot been altered for delivery in order to work in any other setting.

Upon starting the application, the user is presented with the dashboard, amain menu displaying the application's main functions, which are �Homepage�,�My Media�, and �Upload Media�. They allow the user to see his basic pro�leinfo and �nished productions, see the raw media �les in his user folder, andupload �les from his device to that folder, respectively. All of these actionsrequire the user to log in, however, he is allowed to see the dashboard to get abetter idea of what the application will o�er once he has taken the time to enterhis credentials, or create an account if he does not have one.

Logging in is done by making a request exactly like what a browser wouldsend to log into the web version, then storing the cookie received and sendingit with each subsequent request, mimicking the behavior of the web browserto minimize the need for redundant code. The cookie is stored using Tita-nium.App.Properties, which is essentially a dictionary structure whose valuespersist across applications sessions, so the user will remain logged in even if heexits the application. The Android equivalent is com.android.content.SharedPreferences,which will be used in the same fashion in the Android application once it con-verts to the new API, discussed in section 3.2 .

The homepage screen displays the user's pro�le more or less as it can beseen by other users (in a web browser, visiting other users in the applicationis outside the prototype scope), including a list of publicly available �nishedproductions. The my media screen displays the content of the user's folder as alist, showing the name of each element as well as a thumbnail. The uploader isimplemented di�erently than in the Android version, which uses MediaStore, adatabase maintained by the Android system containing metadata on all media�les residing on the device. Titanium does not provide access to the MediaStore,so it was necessary to look for other options. Walking the directory tree of theSD card is an option, however, Titanium does allow launching the Gallery appli-cation to pick an image or video clip, which is returned to the invoker througha callback. When the user selects �Upload media�, the gallery application islaunched (Fig. 3b), and when the user clicks a thumbnail, that �le is uploadedto his folder in Creaza. The user may then upload another �le, or return to themain menu. This is not as convenient for bulk uploading, but has the addedbene�t of allowing the user to click the camera button within the gallery app,take a picture and upload it directly, without purposefully leaving the Creazaapplication. It doesn't allow queueing a long series of uploads, but it doesn'trequire implementing much custom UI, and it still gets the job done. One couldsay it is good enough, and a good way to exploit the inherent functionality inTitanium.


(a) Main menu (b) Gallery application invoked to select an

image to upload

Fig. 3: Creaza prototype implemented in Titanium


3.2 Inspera Content Server API

Due to demand from customers and own needs, Inspera has decided to createan API that is accessible to applications outside the CMS itself, e.g. mobileand desktop apps and Rich Internet Applications (RIAs). The API shall con-tain most of the functionality currently used by Flex applications, and it willsupport both the Adobe Message Format (AMF) used by Flex and AIR applica-tions, and Javascript Object Notation (JSON), which will be used by AJAX andmobile applications. Unfortunately for this project, it is scheduled for releasewith Inspera Platform 9.0 sometime in 2011, which is outside the timeframe ofthis project. In order to develop the prototype, the following operations wereimplemented in a prerelease version of the API, all using JSON for informationexchange:

• Getting metadata for current user (i.e. the user's pro�le information)

• Uploading a �le to the CMS, and storing it in current user's folder

• Fetching the content of a folder

• Fetching metadata for a content item in JSON format

• Getting metadata for a content item

All the operations are accessed by sending a HTTP request to some url, e.g.GET http://hostname/api/1/json/content/userfolder/martin.juell/ .

4 Di�erences in Development Process 15

Algorithm 1 Opening a window on Android

s t a r tAc t i v i t y (new Intent ( cu r r en tAc t i v i t y . th i s , newActivity . c l a s s ) )

4 Di�erences in Development Process

This chapter discusses di�erences between the development process of Titaniumand that of Android, and the strenghts and weaknesses of both. Discussion ofiOS will occasionally be included for perspective.

4.1 Programming

Titanium uses Javascript for it's main development language, while normal An-droid development uses Java. Apart from the obvious syntactical di�erences,the most striking di�erence to the programmer is the lack of enforced typesand name coherence. While any seasoned JavaScript developer is used to this,Java/Android developers might miss their IDEs ability to instantly point outerrors that would cause the code not to compile, or break type safety rules.While a Javascript IDE will detect errors such as incorrectly formatted objectnotation, there is no checking that variable or object names are correctly spelledand valid until the code is actually run.

Assuming one is familiar with object oriented programming and generalprogramming language principles, learning the ropes of either Java or Javascriptknowing the other is no tremendous hurdle, but being already familiar with thelanguage used is a clear advantage, so a web developer looking to get into mobiledevelopment might prefer the familiar Javascript. Regardless of what languagethe developer knows, they will have to learn how to e�ectively program againstthe API in question, and while native Android de�nitely has the advantage interms of the possibilities it supplies, it su�ers a detriment in that it is harder tolearn how to do basic tasks, even if one already knows Java.

Example: Opening a window

Consider a fairly basic task, opening a new window. Code listings 1 and 2 showhow to open a new window over the current window in Android and Titanium.The Titanium version is quite straightforward, a window object is created, andthe UI is told to display it. The Android version is not more complicated interms of the amount of code required, but leaves a completely new developerwith far more questions, such as �How is an Activity di�erent from a window,and why do I need an Intent to start one ?�3 A developer new to iPhone lookingto open a new window will �nd that opening windows is discouraged, and thathe should instead change the views displayed by the current window[6].

Control versus convenience

What constitutes a strength or a weakness in APIs will vary greatly betweendevelopers and organizations. An Android professional might enjoy being in

3 See A for explanation of key Android terms.


Algorithm 2 Opening a window in Titanium

var window = Titanium . UI . createWindow ({u r l : ' mywindow . j s '

} ) ;window . open ( ) ;

complete control over thread management, allowing some tasks to run on back-ground threads while incrementally updating the user interface on the mainthread to create a slick experience, and would miss having full control overthreads in Titanium. Meanwhile a developer who is not as well versed in multi-threaded programming might enjoy that Titanium has an asynchronous HTTPclient that does not require him to think about threads himself, and might pullhis hair out over Android's security restrictions regarding threads and the UI[5]when trying to implement that behavior himself on Android. iOS developers usethe XCode interface builder's drag and drop functionality to build user inter-faces, Android uses XML layouts, and while building the UI programmaticallyin Titanium Javascript is not as elegant as either of them, it saves developerstime because they don't have to do both.

Feature speed-dial

In addition to the background-executing HTTP requests, Titanium allows anumber of other commonly used tasks to be done with very little code. To dis-play a remote image in an ImageView on Android, one has to open a HTTPURL-Connection to the image's URL, feed the input stream to the BitmapFac-tory's decodeStream() method, and create a BitmapDrawable from the resultingBitmap, which the ImageView can display. This has to be done in the back-ground so as not to lock the UI while the image is downloaded, but the Im-ageView.setImageDrawable call must happen on the main UI thread or it causea security violation. Titanium eliminates this headache: Simply set the imageproperty of the image view to the URL and the image will be downloaded inthe background and displayed correctly. Similarly, streaming an audio clip onlytakes one line of code. Common media features are very easily accessible in theirbasic form, allowing great time savings. They are not always useful, however.To load a thumbnail for a content item in Inspera Content Server, one musthave read access to the item. So for items that aren't completely public, it isnecessary to include a cookie for authentication, which the image attribute ofImageView objects does not support. An alternative approach tried was to loadthe image manually using a HTTPClient with the Cookie header set, howeverfor large lists, this would lead to dozens of httpclients being created, crashing theapplication due to lack of memory. A possible solution would have been to haveone httpclient process a queue of urls, along with references to the imageViewsin which to put the image. This approach was discarded in favor of just sendingthe session id in the URL, and not declaring any httpclients manually at all,which worked very well. 4

4 Session ID in URLs is disabled on Inspera's production servers, however the author has

lobbied for the �nal version of the API to support some sort of authentication via URL as it

brings great convenience to app development.


Separating content from presentation

On Android, layouts are written as XML �les, completely separate from programcode. Lists display data using adapters, classes whose responsibility it is tocreate a View for each list item, typically by in�ating an XML layout, and settingthe views inside to display text and images gathered from the data backing thelist. On Titanium, the UI is created programmatically, side by side with otherapplication code. Depending on what kind of separation is desired, the developercan put layout generating code in separate functions where possible, which canalso be put in separate �les and included where needed, if desirable. Titaniumlists have a data attribute which can either be set to a list of data objects (withproperties such as title, leftImage, and hasChild, which Titanium will pick upon), or a list of already generated table row Views. The latter approach is more�exible in presentation, but consumes more memory as it does not recycle viewobjects.

Tools used

Titanium supplies only the tools to start a new application project, and to buildit for the platforms it supports, and the developer is encouraged to use �theirfavorite IDE� to actually write the code. This is a wise choice, as developingand maintaining an IDE would add a signi�cant workload to the Appceleratordevelopment team, however this does lead to some signi�cant changes in thework�ow of the app developer, compared to developing for Android using Eclipsewith the Android plugins.

Adapting to the organization

For an organization that wants a small number of specialized mobile develop-ers, an API that is harder to familiarize with is no obstacle, but if the mobiledevelopment is done primarily by developers who only spend a portion of theirtime on mobile apps, a simple API which is easier to understand is a big plus.The same goes for already knowing the language used, or at least its paradigms.The real bene�t, however, kicks in once iPhone or another platform enters thepicture as well. iOS development uses Objective-C, which is another languageto learn for a lot of developers, and the API is quite di�erent from that ofAndroid.[15] Titanium does a good job of hiding the quirks of each platformbehind a simple and easily understandable API, and presumably so the otheravailable tools such as PhoneGap.

4.2 Debugging and Testing

One of the features native Android developers will quickly miss is the abilityto use the Eclipse graphical debugger to step through code as it's running onan emulator or device. It's an excellent way to verify that variables contain thevalues they're supposed to, and that the program �ow is correct. Titanium doesnot have this functionality, and as a result Titanium apps are harder to debug.However, when the debuggable attribute is set to true, applications providefairly good feedback upon encountering a runtime JavaScript error, showingan alert dialog with an error description as well as the name of the o�endingjs �le and line number. For detecting semantic-only errors, the developer can


Fig. 4: Error message generated by Titanium

use Titanium's log features to write to the Android system log, viewable inTitanium Developer when using the emulator, or in the LogCat view in Eclipsewhen testing on a device.

On occasion, the prototype under development produced some rather pecu-liar error messages, such as the one shown in Fig. 4, that do not state wherethe error is. The best way to get around this issue is by making small, in-cremental changes and testing frequently, minimizing the number of possiblesources of the error. There was also an instance in which the application wouldcrash, and the only debug information would be a regular Android stack tracein the Android system log containing an Android system error message with noreference to where in the Titanium source it occurred. The problem occurredbecause a UI component was directly manipulated from a HTTPClient eventhandler function, which are run in background threads, and only the UI threadis allowed to manipulate the UI thread on Android. Problems like this are aninherent issue with this kind of tool; in addition to errors occurring becausethe developer has written something the Titanium spec does not allow, he mayalso face errors occurring because he has written something Titanium has noobjections with, but the code generated by Titanium causes an error on one ormore of the underlying platforms.

Android developers moving to Titanium might miss the built-in JUnit frame-work support to run automated tests. However, there are JavaScript testingframeworks that can allow similar functionality, such as jsUnity (www.jsunity.com).No such frameworks were evaluated in this project.


4.3 Overall Time Spent

Developing in Titanium is de�nitely faster than developing for Android andiPhone separately. For a developer with no previous Android experience, itshould also be faster to develop an Android-only application using Titaniumthan using the Android SDK. The amount of code required to achieve somefunctionality is smaller in many cases, and it is not necessary to know the quirksof Android in order to get something working. Quality assurance is a must,however, and making sure the application displays nicely on di�erent screensizes (which Android supports better), and does not use excessive memory overprolonged use is a challenge.

5 Di�erences in Completed Application 20

Fig. 5: Log output generated after closing of the Gallery picker activity, be-fore starting an actual upload, showing large amounts of memory beingallocated, forcing garbage collection several times.

5 Di�erences in Completed Application

The �rst di�erence noticeable to the Android user is the splash screen. Splashscreens are mandatory on iPhone, but not very common on Android. The de-fault is a generic Titanium image, however it can easily be swapped for anotherof the developer's choosing. When it comes to the user interface controls, Ti-tanium delivers on its promise, they are exactly as they would be if developedusing Android tools, animations and transitions included. Some of Android'sUI controls, such as the GridView, are missing, but most are available and workwell.

Performance

As far as execution speed goes, the concerns are primarily whether the usercan notice any sort of slowdown or waiting times beyond what is expected oracceptable for some action, and secondarily, the strain on the battery. Sincethe prototype was implemented very di�erently from the native application, itmakes little sense to compare the two in either regard, however there are a fewthings to point out. Titanium seems to allocate vast amounts of memory, andout of memory errors were somewhat common during implementation. Memoryallocation has been pointed out by developers.android.com as a key performancepoint[4], so this is unfortunate. It is important that the developer pay attentionto memory usage, reusing objects when possible, and freeing resources explicitlywhere possible when they are not in use. Despite the memory allocations, theprototype ran smoothly.

6 Discussion 21

Fig. 6: Orbium, a game developed in PhoneGap. Available for iOS, Androidand Palm.

6 Discussion

6.1 Choice of platform revisited

Initially, the last bullet point of the criteria read �compile to native code for eachplatform�, however that was misleading, as even Titanium, which uses nativeUI controls, does not in fact compile its code to native code. Still, there wasclear emphasis on a native user experience when considering frameworks, whichled to PhoneGap being dropped in favor of Titanium. As this project neared itscompletion, it was debated within Inspera whether native user experience needsto be such a priority. It also became clear that while Titanium does use webtechnologies (Javascript), there is no real opportunity to reuse HTML writtenfor the web in Titanium mobile apps.

WebViews return

All Inspera projects have HTML- and Flash-based web frontends, and it wouldbe pretty safe to assume all users of a mobile application would be familiar withthe web frontend. An application that looks more or less exactly like websitethe user is already familiar with could easily be just as good, or better, thanone using the list views and buttons of its target platform. An example ofthis is Orbium (Fig. 6), a PhoneGap showcase application available on thepaid Android Market. Its UI controls are appealing, intuitive and well-behaveddespite not being native. One can also assume that a lot of the features in mostapplications developed by Inspera will be features also o�ered on the website,possibly adding extra capabilities enabled by the mobile context. It would seemlike there would be great potential for reusing HTML, CSS and JavaScript fromthe web version to quickly create a satisfactory PhoneGap application.

While that might sound good, ultimately it's not that easy. The HTML, CSSand Javascript is generated on the server side using Java and XSLT based on

6 Discussion 22

dynamically changing data, so it is not a matter of simply pasting the HTMLinto a PhoneGap project. The phone context is di�erent from the browsercontext in several ways, one of which is that it is not always online, but the usermight expect the app to be usable anyway. For that to work, the workings ofthe app must reside on the device, as must a cached copy of the user's data -so simply fetching all HTML from the server on request is not reliable enough.In addition, the content should be laid out to �t a mobile display rather thana computer screen. This means that even if both the desktop browser versionand the mobile version are to be implemented in the same language, the degreeof reusability might not be very high.

Still, there is de�nitely a case to be made for the WebView-based model.One is the ability to design the graphical user interface using the same processused for the web, which developers are already familiar with. The fact that theapp can be run and debugged in a conventional browser (at least the parts thatdon't require phone features), is also an advantage. Prototypes can be easilyshown to customers who don't have devices - all they need is their desktopbrowser and they can interact with the application.

A Flashier alternative

Adobe's rapidly improving tools also deserve closer consideration. At the time ofprint, Adobe Flash builder can deploy AIR apps to Android and iOS, with Black-Berry about to follow, which is the same as Titanium. Inspera's Flash/Flexdevelopers have, in an e�ort parallel to this one, conducted a pilot project usingthe new AIR runtime on mobile devices. The target project is ExplorAmaze(Fig. 7), an interactive dynamic storytelling tool under development, and theprototype allows playing back remote and local content in the ExplorAmaze for-mat. The prototype uses the AIR runtime's ability to handle device keypressessuch as 'back' and 'menu', as well as the built-in GUI controls, and runs on boththe iPad and Android tablets such as Samsung's Galaxy Tab. Performance hasbeen reported as very satisfactory, with the only drawback being some initialload time while the sizable application loads and the AIR runtime is started.Ryan Stewart[9] has had similar �ndings with the Flash Player on Android,stating that Flash, with no hardware acceleration, only uses 10% more batteryplaying back video than the native, hardware-accelerated player, and performssimilarly well in games. AIR leverages the OpenGL and hardware accelerationfeatures of the device, which bodes well for both execution speed and batterylife. The visual quality on the ExplorAmaze prototype is reportedly excellent,even on varying screen sizes, due to the AIR runtime's ability to use vectorgraphics and adapt to di�erent aspect ratios. Doing all mobile development inAIR, easily reaching all platforms with high-quality applications generated fromone codebase is a very attractive option.

There are a few drawbacks, however. AIR is neither open nor free, withFlash Builder licenses currently starting at $249 for the standard version, and$699 for premium. What's problematic is that Adobe have 100% control overthe future development of the platform. What it's going to cost to use it, whatfeatures it will support, and what platforms it will run on are all questionswhich Adobe have the sole power to decide for themselves. To some degreethis is always true when basing development on a third-party tool, however ifan open-source tool takes a an unpopular turn it can be forked, while closed

6 Discussion 23

(a) Editor running in a web browser

(b) Player running in AIR on a Mac

Fig. 7: ExplorAmaze

6 Discussion 24

proprietary tools like AIR cannot. Steve Jobs and Apple are concerned aboutAdobe's control over Flash [13], and Steve Jobs and Apple are themselves aconcern. They disallowed applications not originally written for the iPhone atone point[11], and there is no stopping them from doing it again.

Security is also a concern that must be addressed. On Android, every appli-cation runs in its own Linux process with its own user ID which has a speci�cset of permissions. The permissions an application requires must be speci�ed inthe application's manifest or otherwise the application will not run. The user ispresented with the permissions the app requires during install and may chooseto reject applications that require permissions he does not wish to grant, suchas writing to the external storage or accessing current GPS location. It wouldbe troubling if AIR applications all used the permissions required by the AIRruntime itself, as users would get accustomed to accepting applications that�require� access to all features, and seemingly innocent applications would beable to bypass this detection under the cover of being AIR apps. Fortunately,AIR apps require an <android> tag in their application descriptors in order tosuccessfully deploy to Android, which must contain, among other things, thepermissions used by that particular application[8]. The real issue is whethervulnerabilities in the AIR runtime or application could allow exploits that harmthe user in other ways, like leaking or deleting data the application has accessto, or performing other actions on an attacker's behalf. Such a vulnerability haspreviously been found in Android's Flash Player[3].

Still, for Inspera, AIR for Android, iOS and BlackBerry is very promising.It achieves the goal of one codebase for many platforms, possibly including thebrowser and the desktop, while enabling a wide variety of features. As Insperaalready has Flex developers who are familiar with Flash Builder and AIR, thereis no need to buy licenses or learn new languages or entire APIs. It also allowsreuse of Flash/Flex content used in web solutions. The look and feel mightdi�er from that of native applications, however this does not prevent developersfrom creating engaging, appealing, user-friendly interaction.

The native advantage

Clearly cross-platform development, regardless of tools used, can save massiveamounts of design, development, and maintenance work. Does this mean theend of platform-speci�c development? Not entirely. For organizations thatcan a�ord developing separately, or do not care about reaching every platform,native development has some clear advantages. Not having to depend on thefeatures o�ered by a third-party tool, native applications can take advantage ofevery feature of their target platform, as soon as they are released. There is norisk of security holes in third party software compromising the application, or ofthe makers of that software going out of business, hiking their prices, or makingdecisions that con�ict with the organization's interests. Native applicationsalso have no overhead from intermediary software layers and as a result shouldperform better. However, the di�erence in platforms requires developers whoknow each platform, as well as the �nancial resources to pay them. For anyapplication targeting more than two platforms, one would have to really needthe native advantage for native development to be worth it.

6 Discussion 25

Summary

In the end, it comes down to what suits the organization, the developers, andthe project best. AIR might be the most appealing option for Inspera, hav-ing already adopted Adobe's technology heavily in past and current projects.However it seems there are tools available that suit most organization's existingknowledge and codebase, whether it be Ruby, C++, J2ME, Flex or Web.

7 Conclusions and future work 26

7 Conclusions and future work

As a result of popularity rise in mobile devices, cross-platform developmentframeworks for mobile applications are rapidly emerging and evolving. Theyprovide what can sometimes be a restricted set of features, or somewhat lesserperfomance, but for many companies the tradeo� will be well worth it. Thegreatest bene�ts present themselves as less time spent learning APIs and lan-guages, ability to reuse existing development e�orts, and less time spent desgn-ing, writing and managing code.

The work done in this project has provided Inspera and the author withbetter insight into the workings of such frameworks in general, and Titaniumin particular. It has contributed to shaping future functionality in the API,and explored what can be done with a greatest-common-denominator featureset available. [...]

7 Conclusions and future work 27

References

[1] .

[2] .

[3] .

[4] .

[5] .

[6]

[7] Citation needed.

[8]

[9]

[10] Adobe Inc. Packager for iphone, September 2010. URL http://labs.

adobe.com/technologies/packagerforiphone/.

[11] Apple Inc. Statement by apple on app store review guidelines, September2010. URL http://www.apple.com/pr/library/2010/09/09statement.

html.

[12] OpenPlug Inc. Elips studio pricing, September 2010. URL http://

developer.openplug.com/download/pricing.

[13] Steve Jobs. Thoughts on �ash, apr 2010. URL http://www.apple.com/

hotnews/thoughts-on-flash/.

[14] John Krogstie. Model-driven development and evolution of informationsystems: A quality approach. 2010.

[15] Erlend Stav. Developer's overview and comparison of the iphone and theandroid platforms. 2009.

http://labs.adobe.com/technologies/packagerforiphone/

http://labs.adobe.com/technologies/packagerforiphone/

http://www.apple.com/pr/library/2010/09/09statement.html

http://www.apple.com/pr/library/2010/09/09statement.html

http://developer.openplug.com/download/pricing

http://developer.openplug.com/download/pricing

http://www.apple.com/hotnews/thoughts-on-flash/

http://www.apple.com/hotnews/thoughts-on-flash/

A Key Android terms explained 28

A Key Android terms explained

Taken from the Android documentation, available at http://developer.android.com.

Activity An activity is a single, focused thing that the user can do. Almostall activities interact with the user, so the Activity class takes care ofcreating a window for you in which you can place your UI with setCon-tentView(View). While activities are often presented to the user as full-screen windows, they can also be used in other ways: as �oating windows(via a theme with windowIsFloating set) or embedded inside of anotheractivity (using ActivityGroup).

Intent An intent is an abstract description of an operation to be performed.It can be used with startActivity to launch an Activity, broadcastIntentto send it to any interested BroadcastReceiver components, and startSer-vice(Intent) or bindService(Intent, ServiceConnection, int) to communi-cate with a background Service. An Intent provides a facility for per-forming late runtime binding between the code in di�erent applications.Its most signi�cant use is in the launching of activities, where it can bethought of as the glue between activities. It is basically a passive datastructure holding an abstract description of an action to be performed.The primary pieces of information in an intent are:

action � The general action to be performed, such as ACTION_VIEW,ACTION_EDIT, ACTION_MAIN, etc.

data � The data to operate on, such as a person record in the contactsdatabase, expressed as a Uri.

View [The View class] represents the basic building block for user interfacecomponents. A View occupies a rectangular area on the screen and isresponsible for drawing and event handling. View is the base class forwidgets, which are used to create interactive UI components (buttons, text�elds, etc.). The ViewGroup subclass is the base class for layouts, whichare invisible containers that hold other Views (or other ViewGroups) andde�ne their layout properties. All of the views in a window are arrangedin a single tree. You can add views either from code or by specifying atree of views in one or more XML layout �les. There are many specializedsubclasses of views that act as controls or are capable of displaying text,images, or other content.

WebView A View that displays web pages. This class is the basis upon whichyou can roll your own web browser or simply display some online contentwithin your Activity. It uses the WebKit rendering engine to display webpages and includes methods to navigate forward and backward through ahistory, zoom in and out, perform text searches and more.

Documents

A case study on the viability of cross-platform mobile ...krogstie/project-reports/2010/Ubiquity-juell.pdfA case study on the viability of cross-platform mobile ... save time otherwise