Project Ubiquity A 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 dierent 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 dierent 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 project in computer science in the fall of 2010 by Martin Andreas Juell. The project is completed in the rst term of the nal year of the 5-year integrated MSc program in Computer Science at the Norwegian University of Technology and Science (NTNU), and its scope is 15 units (half of the normal workload for half an 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 very fragmented market of mobile devices and platforms, harnessing these tools could be a critical factor in market survival, and they could lower the cost for small businesses to enter the application scene. I extend my thanks to my supervisors at Inspera, Sondre Bjørnebekk, Bjørn Rustberggard and John Arne Skjervold Pedersen, as well as my supervisor at IDI, John Krogstie, for providing invaluable feedback throughout the writing process.
ii Contents
1 Background and objective ...... 1 1.1 The problem with platforms ...... 1 1.2 Inspera AS, Inspera Content Server and Creaza ...... 1 1.3 Objective of project ...... 2 1.4 Outline of report ...... 2 2 Choice of platform ...... 4 2.1 Criteria ...... 4 2.2 Reviews ...... 5 2.3 Final Consideration ...... 10 3 Development work ...... 11 3.1 Prototype: Creaza for Titanium ...... 11 3.2 Inspera Content Server API ...... 14 4 Dierences in Development Process ...... 15 4.1 Programming ...... 15 4.2 Debugging and Testing ...... 17 4.3 Overall Time Spent ...... 19 5 Dierences in Completed Application ...... 20 6 Discussion ...... 21 6.1 Choice of platform revisited ...... 21 7 Conclusions and future work ...... 26 References ...... 27 A 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 ...... 11 3 Creaza prototype implemented in Titanium ...... 13 4 Error message generated by Titanium ...... 18 5 Log output generated after closing of the Gallery picker activ- ity, before starting an actual upload, showing large amounts of memory 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 of Technology 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 diering plat- forms, and to develop an application for iOS, Android, Palm WebOS, Windows Mobile, Symbian OS, Samsung Bada, and BlackBerry, one must write the same application seven times, and maintain all seven codebases separately. Expenses related to development, testing, bug xing and maintaining security can quickly outweigh the value the application provides. The concept of platform fragmentation and the desire to develop software across the boundaries that are set by each platform was not born with mobile devices. Operating systems and programming languages for conventional com- puters also dier substantially, both in terms of syntax and features, and best practices 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 the functionality of software as a platform-independent model (PIM), written in a formal, domain-speci c language (DSL). Using standardized, platform-speci c rules and tools, the PIM is then translated into platform-speci c models in a computer-assisted process. The aim is to increase software quality, development speed, portability and reusability. [14] Modern desktop applications wanting to reach both the Mac OS, Linux and Windows platforms have the same problem, and can solve it in several ways. Using a programming language like Java leverages the fact that almost all necessary platform adjustments are done in the Java implementation for each platform, and the application developer does not have to think much about them. One example of such an application is Eclipse (www.eclipse.org), the IDE used for development in this project. Another approach is to use a language like C or C++ for development, and either make manual adjustments for each platform or use libraries that present some generic functionality to the developer, and handle the implementation speci cs dierently for each platform. One such library is GTK+ (www.gtk.org), a multi-platform user interface library used in many open-source applications, such as the vector drawing program Inkscape (www.inkscape.org). Mobile platforms often use dierent programming languages, but there are software kits available that let developers write one codebase in a meta-language, and then build this code into applications for several dierent platforms. Some particular components may still have to be developed speci cally on a per- platform basis, but there is still great potential to save on development and maintenance time and costs. There are several dierent approaches to how this can 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 on Inspera's key product, Inspera Content Server. Inspera CS is a web-based soft- 1 Background and objective 2 ware platform built to handle and present rich media for use in education and communication. Content is stored in an XML format, independently of its use. This allows great exibility in composition and presentation. Content can be combined hierarchically, forming structures, virtual documents containing sev- eral elements of potentially dierent types. This approach can handle a variety of dierent 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 tests for all school children in Norway), Lokus (e-learning portal for Aschehoug, a major Norwegian publisher), and Creaza (explained below). Inspera anticipates increasing demand for mobile applications in future projects, and would bene t greatly from having one standard framework for devices to communicate with the system. Creaza (www.creaza.com) is a suite of web-based creative tools directed at storytelling. It features a sophisticated timeline based video editor, an audio editor, a mind mapping tool, and a cartoon creation tool. It is directed towards education, and comes with a rich library of media that users can mix with their own content to create video, soundscapes, and cartoons. It is marketed toward learners, and a signi cant portion of the content can be related to school curriculum in subjects like history and geography.
1.3 Objective of project The objective of this project is to determine the viability of developing Inspera's future mobile applications using a cross-platform mobile development toolkit. It details the development of a proof-of-concept prototype application using cross- platform tools, and then tries to assess how great the time- and eort-saving advantages of using these tools are. It also examines whether there is a substan- tial dierence in the quality of the generated device code versus handwritten code and whether there is a noticeable dierence in performance, stability, and overall user experience. If cross-platform tools prove to be valuable, then a gen- eral framework can be built based on the application-independent components of the application. This can form the basis for future applications, reducing the amount of application-speci c code as well as that of platform-speci c code. If successful, this would minimize development and maintenance costs, while allowing rapid protoyping, development and deployment of new applications.
1.4 Outline of report
• Section 2 addresses the challenge of determining what tool to use based on a set of criteria, and also nding the set of criteria that will best suit Inspera.
• Section 3 details the prototype implemented as well as the changes made to the server side to accommodate this and future projects.
• Sections 4 and 5 describe the dierences and tradeos between native and cross-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 1 Background and objective 3
multiplatform tools. 2 Choice of platform 4
2 Choice of platform
One of the most critical choices one must make when attempting cross-platform development is the decision of what tool to use. As there is no o cial registry of what tools are available for this task, a list of what were perceived to be the best and most widely known frameworks was assembled using web searches and reading articles. After constructing a list of criteria, a quick evaluation of each candidate was performed in order to narrow the eld, followed by a deeper analysis 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 to performance, stability, and resource usage.
• All other things equal, a free (or cheap) alternative is better than a costly one, and an open source alternative would be better than a proprietary one. In addition, to speci cally suit Inspera, the tools should:
• Allow Inspera's developers to write apps in a language they are somewhat familiar 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 in mobile 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 web components. Java: Might allow some reuse, although Java is mostly used on the server 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 like web pages or apps for another platform).
2.2 Reviews Table 1 contains a quick comparison of the frameworks examined. Because of the nature of the assignment, a number of the candidates were not analyzed deeply, due to biases in the criteria making them very unlikely to be selected for 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. The WebView is wrapped inside a PhoneGap container which allows access to native phone features via Javascript calls, combining the familiarity, versatility, and wide deployability of web apps with the extended functionality of mobile apps. It is open source, and has received a lot of praise from reviewers. This sounded promising to some extent, however, given the focus on nativity in the criteria, it seemed necessary to test a couple of sample apps in order to judge whether there was a signi - cant dierence in user experience. The PhoneGap showcase contained mainly iOS apps, however there were two applications that were built for Android, and available 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-style focus and pushdown eects on buttons (rather than button-style), and the back button quit the application entirely, rather than moving back one level as is the standard on Android. On iOS, this is normal behavior, and iPhone users expect to use the back button the application provides to navigate inside the application, but to an Android user this is unnatural. This might be something a 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 2 Choice of platform 6
Tool Platforms Language Look & Phone License Feel features PhoneGap All major HTML/ Web-like Acc, Geo, OSS CSS/ JS Vib, Cam, Sound, Contacts MoSync All major C/C++ Unknown Geo, Free for + more Cam, OSS use, Sound commercial licenses available OpenPlug Most Flex Decent Most Proprietary, major (no expensive RIM) RhoMobile All major HTML Pretty Most/All Free for / JS / good OSS use, Ruby commercial licenses available Titanium iOS, An- HTML5/ Like na- Most/All OSS, paid droid, CSS/ JS tive plans avail- (WinMo able + RIM in dev) WidgetPad Smart- HTML5/ Unknown Unknown Free phones CSS/ JS BedRock/ All major, Java/ Intended Unknown Unknown Metismo Nintendo J2ME for DS, PSP games AirPlay All major C++ Custom Unknown Unknown UI kit (looks good) AlcheMo Most J2ME Unknown Most Unknown major (no RIM) MotherApp Android, Custom Native, Cam, Unknown iOS, RIM HTML appeal- Geo, etc. ing
Tab. 1: Overview of the frameworks examined 2 Choice of platform 7
(a) iPhone-like menus displaying on An-(b) Android hyperlink-style focus eect on droid 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 viable option.
Appcelerator/Titanium Titanium, like PhoneGap, uses HTML/CSS/Javascript2 as its development lan- guage, however there are a few key dierences between the two. The developers have put a lot of eort into making the apps feel native, even with customized UI controls, 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 display the web code, it features a Javascript-to-native bridge, which maps UI elements and Javascript calls to native APIs, creating a user experience that appears to be 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 web services. Its major weakness is that it only supports Android and iPhone/Pad at the moment, however APIs for BlackBerry RIM and Windows Mobile are in development. According to www.appcelerator.com on December 9th, 2010,
2 Current versions of Titanium use Javascript almost exclusively. 2 Choice of platform 8
Titanium has almost 90,000 registered developers, who create over 1,000 new apps monthly.
OpenPlug OpenPlug uses Flex (MXML and ActionScript 3) as its metalanguage, which is 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 these applications for mobile devices such as the iPad. It would also allow Inspera's Flex developers to develop mobile apps the way they develop web and Adobe AIR apps, using Flex Builder with the OpenPlug plug-in. It supports a variety of operating systems, devices and features, and generates decent-looking GUI controls. One of the reasons OpenPlug was considered a top contender early on was because Apple has no plans to let Flash run on its mobile devices the way it runs on computers[13]. Before September 9, 2010, there were also strict guidelines on what apps were allowed to be published to the app store. Apple said they would not allow apps whose code was created with a translation tool, unless they had explicitly approved that tool. During the nal consideration of the frameworks, Apple relaxed these restrictions[11], and shortly after, Adobe announced[10] that it would resume development of a tool to translate Flash and AIR applications to native iOS code. This means that Inspera's Flash/Flex developers would be able to use this tool to deploy Flash-based applications to iOS 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 for Inspera if they chose OpenPlug as their framework.
Adobe Flash/Flex/AIR In October 2010, Adobe launched a new version of its Flex SDK and Flash Builder, dubbed Hero and Burrito, respectively. This release is intended to allow developers to use Flex to develop for mobile devices the same way they can currently develop for the browser and desktop (using Adobe Integrated Runtime, AIR). This approach requires the AIR runtime to be installed on the target device, which is currently only available for Android. Adobe has said other platforms will be supported in the future[2]. Hero and Burrito were not available during the consideration phase of this project, and as a result was not considered as a development tool for the prototype. However, Adobe's platform does bring great promise for cross-platform applications. Christian Cantrell at adobe has demonstraed its potential in a demo titled One app, ve screens[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 code run on the desktop in Windows, MacOS and Linux, a browser, and also as apps on 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 variety of phone features, and its generated UIs look fairly appealing. For Inspera, 2 Choice of platform 9 the choice of language is a deal breaker, however, organizations with Ruby developers 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 in HTML5, CSS3 and Javascript. All project management, source code edit- ing, debugging, collaboration, versioning and even distribution is done in the browser. This is intriguing, but not what Inspera is looking for.
BedRock/Metismo Metismo is a tool heavily directed towards game development, and features such as native-feeling GUI do not seem to be prioritized. This, coupled with the slightly poor choice of language and the many other options available led to Metismo 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++ will not be practical for Inspera.
AlcheMo The sales pitch on AlcheMo's website primarily brags about AlcheMo's ability to port existing J2ME applications to modern smartphone platforms. There is not much detailed info regarding what its generated GUIs look like. J2ME seems like a relatively poor choice of language for a company with no legacy J2ME applications to port. With no samples available and many other good candidates, AlcheMo was not chosen.
MoSync MoSync uses C++ as its development language and because of the bias against C++ 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 dierent from all the other tools in its methodology. The de- veloper creates a version of his website that produces MotherApp compatible HTML (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 for each platform in its cloud, and deliver the binaries to the developer (The binaries communicate with the developer's website, not at all with MotherApp once they are completed). This is an original twist, however, the developer not having any 2 Choice of platform 10 control over the compilation, generated source, and tool chain is de nitely sub- optimal. If MotherApp becomes hugely popular, its communication channels might congest completely and its ability to handle requests from developers will drop to unacceptable standards (In order to obtain a binary, developers have to contact MotherApp via their contact form, which seems unpractical).
2.3 Final Consideration Of the ten frameworks considered, all that did not use either web technologies or Flash/Flex as their metalanguage were eliminated as candidates, as none of them seemed to oer anything of enough value to Inspera to warrant the dis- advantage brought about by the language choice. In addition, WidgetPad and MotherApp were dropped from consideration as they did not provide enough control over the source code and the processes applied to it. PhoneGap might have been the winner for another organization, however, when compared along- side Titanium, it became clear that PhoneGap's strengths were wide platform support and HTML5 features, while Titanium oered native interaction. Since native 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 does support Windows Mobile and Symbian OS and none of the others do, it is an extra proprietary layer on top of Adobe Flex, which would soon be viable by itself. Also, OpenPlug PRO costs ¿1399 a year, OpenPlug PREMIUM costs ¿3499[12], and the free version of OpenPlug includes an advertisement banner in applications. In the end, Titanium was selected. It is free and open source, and thus easy to experiment with. It has an active community, promises great user interaction with little eort, and is based on open web technologies. However, to learn about the potential of AIR as a mobile development tool, Inspera's ash developers later 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 application project 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 phone to their Creaza account, and allow users to view completed productions from their account on their phone, making Creaza more ubiquitous. The goal of the prototype is to create an alternative written in Titanium. The Android application has been under development for quite some time, leverages a number of Android speci c features, and it is not desirable to make a complete copy of it. The goal of the prototyping, however, is to probe what the capabilities of Titanium are, and what challenges it introduces. Using this approach it is also a goal to infer something more general about when to use Titanium, or multi-platform tools in general, and when they should be avoided. The prototype should contain the same main functionality as the Android implementation, but it need not be implemented in the same detail. The main goals for the original application were that it should allow the user to upload and download/view content on a device, and the primary goal is to do this on Titanium as well. While it would be natural to compare the two on technical 3 Development work 12 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 great functionality 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 features of 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 paper edition of this text. During development and testing, the app was run on a Google Nexus One, accessing an instance of Inspera Content Server running locally on the development machine using 802.11g Wi-Fi. Since the changes to the API on which the app depends have not been deployed to any other environment, and may never be in their exact current form, the application has not been altered for delivery in order to work in any other setting. Upon starting the application, the user is presented with the dashboard, a main menu displaying the application's main functions, which are Homepage, My Media, and Upload Media. They allow the user to see his basic pro le info and nished productions, see the raw media les in his user folder, and upload les from his device to that folder, respectively. All of these actions require the user to log in, however, he is allowed to see the dashboard to get a better idea of what the application will oer once he has taken the time to enter his credentials, or create an account if he does not have one. Logging in is done by making a request exactly like what a browser would send to log into the web version, then storing the cookie received and sending it with each subsequent request, mimicking the behavior of the web browser to minimize the need for redundant code. The cookie is stored using Tita- nium.App.Properties, which is essentially a dictionary structure whose values persist across applications sessions, so the user will remain logged in even if he exits 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 be seen by other users (in a web browser, visiting other users in the application is outside the prototype scope), including a list of publicly available nished productions. The my media screen displays the content of the user's folder as a list, showing the name of each element as well as a thumbnail. The uploader is implemented dierently than in the Android version, which uses MediaStore, a database 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 the SD 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 through a callback. When the user selects Upload media, the gallery application is launched (Fig. 3b), and when the user clicks a thumbnail, that le is uploaded to his folder in Creaza. The user may then upload another le, or return to the main menu. This is not as convenient for bulk uploading, but has the added bene 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 Creaza application. It doesn't allow queueing a long series of uploads, but it doesn't require implementing much custom UI, and it still gets the job done. One could say it is good enough, and a good way to exploit the inherent functionality in Titanium. 3 Development work 13
(a) Main menu (b) Gallery application invoked to select an image to upload
Fig. 3: Creaza prototype implemented in Titanium 3 Development work 14
3.2 Inspera Content Server API Due to demand from customers and own needs, Inspera has decided to create an API that is accessible to applications outside the CMS itself, e.g. mobile and desktop apps and Rich Internet Applications (RIAs). The API shall con- tain most of the functionality currently used by Flex applications, and it will support both the Adobe Message Format (AMF) used by Flex and AIR applica- tions, and Javascript Object Notation (JSON), which will be used by AJAX and mobile applications. Unfortunately for this project, it is scheduled for release with Inspera Platform 9.0 sometime in 2011, which is outside the timeframe of this project. In order to develop the prototype, the following operations were implemented in a prerelease version of the API, all using JSON for information exchange:
• 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 Dierences in Development Process 15
Algorithm 1 Opening a window on Android startActivity(new Intent(currentActivity.this , newActivity.class))
4 Dierences in Development Process
This chapter discusses dierences between the development process of Titanium and that of Android, and the strenghts and weaknesses of both. Discussion of iOS 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 dierences, the most striking dierence to the programmer is the lack of enforced types and name coherence. While any seasoned JavaScript developer is used to this, Java/Android developers might miss their IDEs ability to instantly point out errors that would cause the code not to compile, or break type safety rules. While a Javascript IDE will detect errors such as incorrectly formatted object notation, there is no checking that variable or object names are correctly spelled and valid until the code is actually run. Assuming one is familiar with object oriented programming and general programming language principles, learning the ropes of either Java or Javascript knowing the other is no tremendous hurdle, but being already familiar with the language used is a clear advantage, so a web developer looking to get into mobile development might prefer the familiar Javascript. Regardless of what language the developer knows, they will have to learn how to eectively program against the API in question, and while native Android de nitely has the advantage in terms of the possibilities it supplies, it suers a detriment in that it is harder to learn 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 show how to open a new window over the current window in Android and Titanium. The Titanium version is quite straightforward, a window object is created, and the UI is told to display it. The Android version is not more complicated in terms of the amount of code required, but leaves a completely new developer with far more questions, such as How is an Activity dierent from a window, and why do I need an Intent to start one ?3 A developer new to iPhone looking to open a new window will nd that opening windows is discouraged, and that he 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 between developers and organizations. An Android professional might enjoy being in
3 See A for explanation of key Android terms. 4 Dierences in Development Process 16
Algorithm 2 Opening a window in Titanium var window = Titanium.UI.createWindow({ url : 'mywindow. js ' }); window.open();
complete control over thread management, allowing some tasks to run on back- ground threads while incrementally updating the user interface on the main thread to create a slick experience, and would miss having full control over threads in Titanium. Meanwhile a developer who is not as well versed in multi- threaded programming might enjoy that Titanium has an asynchronous HTTP client that does not require him to think about threads himself, and might pull his hair out over Android's security restrictions regarding threads and the UI[5] when trying to implement that behavior himself on Android. iOS developers use the XCode interface builder's drag and drop functionality to build user inter- faces, Android uses XML layouts, and while building the UI programmatically in Titanium Javascript is not as elegant as either of them, it saves developers time because they don't have to do both.
Feature speed-dial In addition to the background-executing HTTP requests, Titanium allows a number 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 resulting Bitmap, 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 cause a security violation. Titanium eliminates this headache: Simply set the image property of the image view to the URL and the image will be downloaded in the background and displayed correctly. Similarly, streaming an audio clip only takes one line of code. Common media features are very easily accessible in their basic form, allowing great time savings. They are not always useful, however. To load a thumbnail for a content item in Inspera Content Server, one must have read access to the item. So for items that aren't completely public, it is necessary to include a cookie for authentication, which the image attribute of ImageView objects does not support. An alternative approach tried was to load the image manually using a HTTPClient with the Cookie header set, however for large lists, this would lead to dozens of httpclients being created, crashing the application due to lack of memory. A possible solution would have been to have one httpclient process a queue of urls, along with references to the imageViews in which to put the image. This approach was discarded in favor of just sending the 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. 4 Dierences in Development Process 17
Separating content from presentation On Android, layouts are written as XML les, completely separate from program code. Lists display data using adapters, classes whose responsibility it is to create a View for each list item, typically by in ating an XML layout, and setting the views inside to display text and images gathered from the data backing the list. On Titanium, the UI is created programmatically, side by side with other application code. Depending on what kind of separation is desired, the developer can put layout generating code in separate functions where possible, which can also be put in separate les and included where needed, if desirable. Titanium lists have a data attribute which can either be set to a list of data objects (with properties such as title, leftImage, and hasChild, which Titanium will pick up on), 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 view objects.
Tools used Titanium supplies only the tools to start a new application project, and to build it for the platforms it supports, and the developer is encouraged to use their favorite IDE to actually write the code. This is a wise choice, as developing and maintaining an IDE would add a signi cant workload to the Appcelerator development team, however this does lead to some signi cant changes in the work ow of the app developer, compared to developing for Android using Eclipse with 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 mobile development is done primarily by developers who only spend a portion of their time 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 the picture as well. iOS development uses Objective-C, which is another language to learn for a lot of developers, and the API is quite dierent from that of Android.[15] Titanium does a good job of hiding the quirks of each platform behind a simple and easily understandable API, and presumably so the other available tools such as PhoneGap.
4.2 Debugging and Testing One of the features native Android developers will quickly miss is the ability to use the Eclipse graphical debugger to step through code as it's running on an emulator or device. It's an excellent way to verify that variables contain the values they're supposed to, and that the program ow is correct. Titanium does not have this functionality, and as a result Titanium apps are harder to debug. However, when the debuggable attribute is set to true, applications provide fairly good feedback upon encountering a runtime JavaScript error, showing an alert dialog with an error description as well as the name of the oending js le and line number. For detecting semantic-only errors, the developer can 4 Dierences in Development Process 18
Fig. 4: Error message generated by Titanium use Titanium's log features to write to the Android system log, viewable in Titanium Developer when using the emulator, or in the LogCat view in Eclipse when 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 where the error is. The best way to get around this issue is by making small, in- cremental changes and testing frequently, minimizing the number of possible sources of the error. There was also an instance in which the application would crash, and the only debug information would be a regular Android stack trace in the Android system log containing an Android system error message with no reference to where in the Titanium source it occurred. The problem occurred because a UI component was directly manipulated from a HTTPClient event handler function, which are run in background threads, and only the UI thread is allowed to manipulate the UI thread on Android. Problems like this are an inherent issue with this kind of tool; in addition to errors occurring because the developer has written something the Titanium spec does not allow, he may also face errors occurring because he has written something Titanium has no objections with, but the code generated by Titanium causes an error on one or more 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 testing frameworks that can allow similar functionality, such as jsUnity (www.jsunity.com). No such frameworks were evaluated in this project. 4 Dierences in Development Process 19
4.3 Overall Time Spent Developing in Titanium is de nitely faster than developing for Android and iPhone separately. For a developer with no previous Android experience, it should also be faster to develop an Android-only application using Titanium than using the Android SDK. The amount of code required to achieve some functionality is smaller in many cases, and it is not necessary to know the quirks of Android in order to get something working. Quality assurance is a must, however, and making sure the application displays nicely on dierent screen sizes (which Android supports better), and does not use excessive memory over prolonged use is a challenge. 5 Dierences 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 being allocated, forcing garbage collection several times.
5 Dierences in Completed Application
The rst dierence noticeable to the Android user is the splash screen. Splash screens 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 another of 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 developed using Android tools, animations and transitions included. Some of Android's UI controls, such as the GridView, are missing, but most are available and work well.
Performance As far as execution speed goes, the concerns are primarily whether the user can notice any sort of slowdown or waiting times beyond what is expected or acceptable for some action, and secondarily, the strain on the battery. Since the prototype was implemented very dierently from the native application, it makes little sense to compare the two in either regard, however there are a few things to point out. Titanium seems to allocate vast amounts of memory, and out of memory errors were somewhat common during implementation. Memory allocation has been pointed out by developers.android.com as a key performance point[4], so this is unfortunate. It is important that the developer pay attention to memory usage, reusing objects when possible, and freeing resources explicitly where possible when they are not in use. Despite the memory allocations, the prototype ran smoothly. 6 Discussion 21
Fig. 6: Orbium, a game developed in PhoneGap. Available for iOS, Android and Palm.
6 Discussion 6.1 Choice of platform revisited Initially, the last bullet point of the criteria read compile to native code for each platform, however that was misleading, as even Titanium, which uses native UI controls, does not in fact compile its code to native code. Still, there was clear emphasis on a native user experience when considering frameworks, which led to PhoneGap being dropped in favor of Titanium. As this project neared its completion, it was debated within Inspera whether native user experience needs to be such a priority. It also became clear that while Titanium does use web technologies (Javascript), there is no real opportunity to reuse HTML written for the web in Titanium mobile apps.
WebViews return All Inspera projects have HTML- and Flash-based web frontends, and it would be pretty safe to assume all users of a mobile application would be familiar with the web frontend. An application that looks more or less exactly like website the user is already familiar with could easily be just as good, or better, than one using the list views and buttons of its target platform. An example of this is Orbium (Fig. 6), a PhoneGap showcase application available on the paid Android Market. Its UI controls are appealing, intuitive and well-behaved despite not being native. One can also assume that a lot of the features in most applications developed by Inspera will be features also oered on the website, possibly adding extra capabilities enabled by the mobile context. It would seem like there would be great potential for reusing HTML, CSS and JavaScript from the web version to quickly create a satisfactory PhoneGap application. While that might sound good, ultimately it's not that easy. The HTML, CSS and 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 HTML into a PhoneGap project. The phone context is dierent from the browser context in several ways, one of which is that it is not always online, but the user might expect the app to be usable anyway. For that to work, the workings of the 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 than a computer screen. This means that even if both the desktop browser version and the mobile version are to be implemented in the same language, the degree of 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 process used for the web, which developers are already familiar with. The fact that the app can be run and debugged in a conventional browser (at least the parts that don't require phone features), is also an advantage. Prototypes can be easily shown to customers who don't have devices - all they need is their desktop browser and they can interact with the application.
A Flashier alternative Adobe's rapidly improving tools also deserve closer consideration. At the time of print, 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/Flex developers have, in an eort parallel to this one, conducted a pilot project using the new AIR runtime on mobile devices. The target project is ExplorAmaze (Fig. 7), an interactive dynamic storytelling tool under development, and the prototype allows playing back remote and local content in the ExplorAmaze for- mat. The prototype uses the AIR runtime's ability to handle device keypresses such as 'back' and 'menu', as well as the built-in GUI controls, and runs on both the iPad and Android tablets such as Samsung's Galaxy Tab. Performance has been reported as very satisfactory, with the only drawback being some initial load 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 battery playing back video than the native, hardware-accelerated player, and performs similarly well in games. AIR leverages the OpenGL and hardware acceleration features of the device, which bodes well for both execution speed and battery life. The visual quality on the ExplorAmaze prototype is reportedly excellent, even on varying screen sizes, due to the AIR runtime's ability to use vector graphics and adapt to dierent aspect ratios. Doing all mobile development in AIR, easily reaching all platforms with high-quality applications generated from one codebase is a very attractive option. There are a few drawbacks, however. AIR is neither open nor free, with Flash Builder licenses currently starting at $249 for the standard version, and $699 for premium. What's problematic is that Adobe have 100% control over the future development of the platform. What it's going to cost to use it, what features it will support, and what platforms it will run on are all questions which Adobe have the sole power to decide for themselves. To some degree this is always true when basing development on a third-party tool, however if an 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 about Adobe's control over Flash [13], and Steve Jobs and Apple are themselves a concern. They disallowed applications not originally written for the iPhone at one 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 c set of permissions. The permissions an application requires must be speci ed in the application's manifest or otherwise the application will not run. The user is presented with the permissions the app requires during install and may choose to reject applications that require permissions he does not wish to grant, such as writing to the external storage or accessing current GPS location. It would be troubling if AIR applications all used the permissions required by the AIR runtime itself, as users would get accustomed to accepting applications that require access to all features, and seemingly innocent applications would be able to bypass this detection under the cover of being AIR apps. Fortunately, AIR apps require an
The native advantage Clearly cross-platform development, regardless of tools used, can save massive amounts of design, development, and maintenance work. Does this mean the end of platform-speci c development? Not entirely. For organizations that can aord developing separately, or do not care about reaching every platform, native development has some clear advantages. Not having to depend on the features oered by a third-party tool, native applications can take advantage of every feature of their target platform, as soon as they are released. There is no risk of security holes in third party software compromising the application, or of the makers of that software going out of business, hiking their prices, or making decisions that con ict with the organization's interests. Native applications also have no overhead from intermediary software layers and as a result should perform better. However, the dierence in platforms requires developers who know each platform, as well as the nancial resources to pay them. For any application targeting more than two platforms, one would have to really need the 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, and the 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 existing knowledge 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 development frameworks for mobile applications are rapidly emerging and evolving. They provide what can sometimes be a restricted set of features, or somewhat lesser perfomance, but for many companies the tradeo will be well worth it. The greatest bene ts present themselves as less time spent learning APIs and lan- guages, ability to reuse existing development eorts, and less time spent desgn- ing, writing and managing code. The work done in this project has provided Inspera and the author with better insight into the workings of such frameworks in general, and Titanium in particular. It has contributed to shaping future functionality in the API, and explored what can be done with a greatest-common-denominator feature set 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, September 2010. 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 information systems: A quality approach. 2010.
[15] Erlend Stav. Developer's overview and comparison of the iphone and the android platforms. 2009. 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. Almost all activities interact with the user, so the Activity class takes care of creating 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 another activity (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, broadcastIntent to 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 dierent applications. Its most signi cant use is in the launching of activities, where it can be thought of as the glue between activities. It is basically a passive data structure 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 contacts database, expressed as a Uri.
View [The View class] represents the basic building block for user interface components. A View occupies a rectangular area on the screen and is responsible for drawing and event handling. View is the base class for widgets, which are used to create interactive UI components (buttons, text elds, etc.). The ViewGroup subclass is the base class for layouts, which are invisible containers that hold other Views (or other ViewGroups) and de ne their layout properties. All of the views in a window are arranged in a single tree. You can add views either from code or by specifying a tree of views in one or more XML layout les. There are many specialized subclasses 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 which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.