Cross Platform Mobile Development

(1)

Cross Platform Mobile

Development

Master’s Thesis Software Development Author 20097733 Bobby Nielsen [email protected] Supervisor

Henrik Bærbak Christensen

Department of Computer Science, University of Aarhus Aabogade 34, 8200 Aarhus N, Denmark

(2)

Abstract

This thesis presents a research and comparison of options for cross platform mobile development. What are the options in the market, and how does the mobile development industry see the options for cross platform development?

The high level goal is to be able to build an app that has a single codebase in one language for several mobile platforms. A framework for evaluating cross platform mobile development options against this goal will be presented, and evaluations of some of these options using prototyping e.g. Xamarin.

(3)

1. Motivation

Several mobile platforms exists today, and it is not in the cards that product companies will agree to use a common development platform to ease the way developers can create apps for mobile devices on multiple platforms.

According to the International Data Corporation (IDC) [IDC] Android, as a mobile OS, are dominating the world market, and their overall market share has continued to increase over the last years (fig. 1-1), although it is expected that iOS take back some of the market with the release of iPhone 6 in the end of Q3. This doesn’t necessarily mean that units shipped with others OS’s is declining. You have to take the overall growth of 27.2% year over year in the second quarter of 2014 (2014Q3) into

consideration and acknowledge that the smartphone market is still rapidly increasing.

Fig. 1-1 WorldwideSmartphone OS market share 2014Q3

(6)

Fig. 1-2 Great Britain Smartphone OS market share 2014

Fig. 1-3 Germany Smartphone OS market share 2014 0,0% 10,0% 20,0% 30,0% 40,0% 50,0% 60,0% 70,0%

Jan Feb Mar Apr May Jun Jul Aug Sep Okt Nov Dec

Android Blackberry iOS Windows Other 0,0% 10,0% 20,0% 30,0% 40,0% 50,0% 60,0% 70,0% 80,0% 90,0%

(7)

Fig. 1-4 France Smartphone OS market share 2014

From the OS market share we see that Android, iOS, and Windows Phone (WP) are the three major players in the market – a market which is heavily affected by the evolving market. We also see that app developers need to cover three platforms to cover the market relative completely.

This means that developers will have to develop one app three times, or use technologies for cross platform development.

Depending on the functionality of the app you, as a developer, want to create, you need to decide whether you have to create your app(s) the native way, or if you can create it as a webapp (HTML5 + JavaScript). As soon as the app gets a little complex, you will probably recognize that you want better performance, and the native look and feel, that you get when you create native apps.

But today, when you want to create native apps, for say the three most common platforms (Android, iOS, and Windows Phone), then you will end up with three different code bases in three different programming languages, namely Java, Objective-C, and C#.

You might have to build your UI’s for each platform, but you do not want to code the business logic of the apps that you develop several times, if you can do it once. Therefore I want to investigate, how I can create cross platform mobile frameworks and libraries with a single codebase.

0,0% 10,0% 20,0% 30,0% 40,0% 50,0% 60,0% 70,0% 80,0% 90,0%

(8)

At Process Factory, where I work, we are on the verge of building mobile apps, but we face the problem of defining a strategy for building apps. We want to be more

(9)

2. Hypothesis/Problem statement

This research will investigate how cross platform mobile development is executed. How can frameworks and libraries be created with a single codebase, such that the frameworks and libraries support all mobile platforms. Do products exist that support cross platform development?

We will assume that it is possible to build application components that will be executable on all major mobile platforms using one language. The major platforms are: Android, iOS, and Windows Phone. We want to research if this is how the industry does mobile development, or are the same apps with same functionality programmed several times in different languages? Are apps developed specifically for each platform?

Delimitations

Focus will only be on the three major platforms: Android, iOS, and Windows Phone. Also, focus will be on native apps and not on hybrid or webapps, because native apps development is still the approach that can ensure a good user experience (UX) as well as support the highest complexity in the apps. There is a big difference in the

application requirements between game applications and other mobile applications, e.g. different expectations to the UX. Therefore focus will be on non-game application development, which has to live up to the different UX expectations within each platform.

Hypothesis

H1. It is possible to find a programming language that can be executed on all

major mobile platforms, so that developers only need to use one language for common frameworks, libraries and business logic.

H2. It is possible to create a cross platform mobile library or framework with

a single codebase in one programming language, that can be used for development of apps on all major mobile platforms having the native look-and-feel and high performance.

H3. Developers are not aware of the possibilities for developing native apps

(10)

Code-free1 solutions will not be taken into consideration, as it is a field in itself that can be researched and compared to solutions involving code programming.

1

(11)

3. Method

To study the problem and validate the hypotheses this defined method is followed.

3.1 Approaches for Cross Platform Development

What technologies are available on the market and which should be used? That is the question that this research will present an answer to. The different products and/or technologies for doing cross platform development will be analyzed to present viable options in mobile development. Along with this I will describe the pros and cons in selecting each of these as the strategy for developing mobile applications. An

evaluation of the products and/or technologies that the analysis finds most promising will be presented. The evaluation criteria will be created from a research in the tendencies and demand in the market.

3.2 Survey and Interviews

Are developers aware of the potential possibilities of cross platform mobile development? What do developers think of mobile development, and how do developers like to build mobile apps? Therefore I will create a survey (fig. 3-1) to get an idea of how developers approach mobile development for several platforms. The survey will also be designed to gather options for mobile development. I will

(12)

Fig. 3-1 Survey questions

Contact will be made to app development firms in Denmark ranking in top 10 on Google. Each will be asked questions (fig. 3-2) about mobile development today, cross platform development, and their view on the challenges within mobile development. The answers from the survey and the interviews will give an idea of the state of knowledge within the developer community, as well as a view into how mobile development is done today. These answers will provide a basis for creating product evaluation criteria later in the analysis.

Native or Not?

•How would you approach the development of an app for Android? •How would you approach

the development of an app for iPhone (iOS)? •How would you approach

the development of an app for Windows Phone?

Frameworks for mobile development

•Which frameworks do you know for cross platform mobile development (tools for making apps for Android, iOS and/or Windows Phone)?

Your preference

•Which strategy do you prefer for mobile development? •Which product(s) do you

prefer for mobile development?

Challenges and Issues

•Do you know of any code-free solutions for mobile development? •What do you think is the

biggest challenge in mobile development? •Do you see any issues with

cross platform mobile development? •Other comments

(13)

Fig. 3-2 Interview questions

3.3 Cross Platform Languages/options

To select a language or a product option for cross platform development, an investigation is made (fig. 3-3) to define which languages/options that is executable on the three major platforms: Android, iOS, and Windows Phone, and that provides a native look and feel. The investigation results in a list of products with programming language relations. The list is used to select the best options for cross platform development.

The list is developed by researching mobile development options available on the market regardless of type, licensing or coverage. Trends and products for

development in the mobile industry is googled to help define the list. A survey is circulated to get a view of the general developers’ knowledge about mobile

development and the options in the market. To get in touch with mobile developers, experienced in the mobile industry, interviews are conducted with developers from some of the Danish app development firms.

Interview questions

•Hvad do you think about developing an app for iOS, Android og WP? •Three languages?

•Other platforms you are focusing?

•Do you know if it is possible to use just one language for the three platforms (Android, iOS, WP)? •Would you like to just use one programming language?

•Are developers generally aware of the possibilities of Cross Platform development? •That isn't webapps?

•What strategy do you prefer for mobile development, and why? •Native

•Hybrid •Webapps

•Which products do you prefer for mobile development?

•Do you know of any code-free solutions for mobile development? •What is the biggest challenge within mobile development?

(14)

Fig. 3-3 Analysis of Cross Mobile Development

3.4 Evaluation of Cross Platform Development options

From the list of viable options for cross platform development, some are selected for evaluation. After the product has been selected, I will investigate and document the process of developing an application using the product. This is done by building prototypes to prove the hypothesis and show how cross platform development can be executed. Issues and probable solutions to these will be recorded during the evaluation. The target is to evaluate by prototyping, and this with all of Android, iOS, and Windows Phone. These prototypes will show how common development tasks can be executed having a focus on providing a single code base for all of or most of the application.

3.4.1 Hello World

Using the candidates I select for further evaluation, the simplest of apps will be created to test the development setup and test whether apps can be created for the three platforms using a common shared library. The shared library will have one method, hello, that takes a string as an argument and returns a string concatenation of “Hello “ and the string argument (fig. 3-4 + 3-5). This Hello World test will also test the ability to create a User Interface (UI) with a native look and feel.

Fig. 3-4 Pseudo code for Hello World

Internet

search

•Google search: mobile development •Google scholar search: mobile development

Survey

•How knowledgeable are developers about options for mobile development?

•What options do developers prefer?

•Using what approach/strategy do developers go to mobile development?

Interviews

•What qualitative options does experienced mobile developers see for mobile development?

•How does experienced mobile developers go to mobile development?

(15)

:App :SharedLibrary

Fig. 3-5 Sequence Diagram for Hello World

3.4.2 Prototyping

The selected candidates that pass the Hello World test of extracting common behavior into a shared library will be further evaluated by prototyping. The case for prototyping will contain stories that provide ground for the evaluation of the product candidate’s ability to support selected functionality. The focus on this selected functionality is not from a standalone app’s viewpoint, but from a viewpoint where the app is part of a system, and therefore integration and the ability to be able to integrate is considered important.

To be able to integrate apps and services over the network, we need a network. Preferably we have a good quality high bandwidth network connection. But unfortunately we cannot count on that. Actually we can count on the opposite. We can be sure that at different points in time, depending on many different and varying conditions, we will have no or a low quality connection. As developers we will have to take that fact into consideration. What do we do with data, if we cannot push it to some backend? It should not be a problem of the user of the app. The problem should be transparent to the user. A solution would be to store the data locally on the device, and later on, when a better network connection is available, the data can be synchronized with the backend. Therefore we must be able to persist the data on some device data store for later synchronization.

Another evaluation point is the UI/UX . The importance of a native look and feel is argued by the industry, and is a high priority for app developers, as the research of the industry view shows (chapter 4.2), except when it comes to game development, which is a different case, because in games you expect a different UX. Therefore another evaluation point is the support of the OS specific native look and feel. The case

(16)

services (GPS). Everything but UI implementation must be programmed once for the three platforms; Android, iOS and Windows Phone.

Stories to be implemented (fig. 3-6):

Fig. 3-6 Case stories

Deployd [Deployd] is a tool that makes building APIs a simple task by providing out of the box functionality for creating services supporting REST and Websockets – an API engine. Deployd will easily be able to support the backend requirements for stories four and five.

•Story 1

•Write a text to storage: Let the user write a text in a textbox and save to storage.

•Story 2

•List all texts written by users on screen. Storage (Local Persistance)

•Story 3

•Let the user write a twitter name in a textbox. Retrieve the last tweet of the twitter given.

API Integration (Twitter)

•Story 4

•Post a comment (comment, email, creation date) to a backend service (Deployd)

•Story 5

•Retrieve (get) list of all comments (comment, email, creation date) from a backend service (Deployd)

REST Service Integration

•Story 6

(17)

Metrics

The criteria for evaluating the selected technologies are created during the analysis, when experience with mobile development is gathered. The reasoning for having these metrics is described starting in chapter 3.4.2.

While developing the prototypes, the defined metrics (fig. 3.7) will be considered.

Fig. 3-7 Metrics

•Ease of implementing native UI, with the right look and feel •Lines of Code (LOC) used to implement each story

•Time to complete each story

•Native coverage: An indicator of the possibility of implementing all stories using the selected platform.

(18)

4. Analyses and Results

This chapter will present possible options for mobile application development that can be executed on mobile platforms, as well as pros and cons in relation to choosing one option for cross platform development.

We will also present how a cross platform mobile development can be executed, utilizing a shared codebase across platforms. The pros and cons of executing cross platform mobile development, and its different approaches will be discussed. Based on a survey and interviews we will provide a view of how developers see mobile development and if developers are aware of the possibilities that cross platform development can provide.

4.1 Approaches to cross platform mobile development

What options and approaches do we know of for cross platform mobile

development? The approaches for cross development could be Cross-compilation, Virtual Machines, Webapps, Hybrid, and Source translation that each has their strengths and weaknesses.

Cross-compilation

Cross-compilation (fig. 4-1) as described by Hartman [Hartman2011] separates the build environment from the target environment. In a mobile development context: Developers use a platform-independent API to build mobile apps, including UI, data persistence and business logic using mainstream programming languages like

JavaScript, Ruby or Java. The cross-compiler processes the code and transforms it into platform-specific apps targeted the different platforms. The generated software artifact can be deployed and executed natively on the device.

Fig. 4-1 Cross-compilation strengths and weaknesses Performance, since the app is

running natively on the device. Improved UX, as the app behaves like any other app on the user’s ecosystem with native access to device specific capabilities like integrated camera, sensors, etc.

(19)

Virtual Machines

Another technique is the use of a virtual machine (VM) [Wikipedia-VM] (fig. 4-2) to abstract the target platform details from the app’s running code. To do this the runtime environment that the application will run on, as well as the API, will have to be provided. The runtime environment executes the app on the mobile device and enables the interoperability between the device’s operating system and the app. Once you would expect that applications utilizing a virtual machine would run a bit slower due to the runtime interpretation latency introduced when the VM is translating data and instructions to and from the underlying host platform. These days’ virtual machines have evolved. E.g. tests [Magenic1][Magenic2] on mobile devices with the Mono engine running C# shows that it can compete with applications written using Objective-C and Java.

Fig. 4-2 Virtual Machines strengths and weaknesses

Mobile Web App – Webapp(s)

Most developers will probably think of mobile web applications (fig. 4-3) in relation to cross platform mobile development, and it is an increasingly popular approach. The application will run in the browser of the mobile device using standard web

technologies like HTML, CSS and JavaScript. The advanced capabilities of HTML5 and CSS3 make it possible for the application to look like a native app.

The pros are much like for the cross-compiler. Portability should be the main advantage over cross-compilation, since VMs are more maintainable and more flexible to extend when new features are added to the device and need to be supported by the API.

(20)

Fig. 4-3 Webapps strengths and weaknesses

Hybrid

It is also possible to create apps as a hybrid (fig. 4-4) between native and webapps. HTML5 webapps is then embedded inside a thin native container. The web pages are usually embedded within the apps. Hybrid apps can be made available through the platforms ecosystems, the app store, marketplace etc. and the user experience is closer to native.

Fig. 4-4 Hybrid strengths and weaknesses Advantages to web applications are

simpler deployment and immediate availability since modern mobile devices are equipped with a browser that can run the webapp. The user only needs an active data connection and the url.

The [HTML5] standard still has to be finalized, and different browsers will historically have differences in the implementation of the standard. Also, it is not possible to emulate the native UI completely using standard web elements, which leads to a poorer user experience. Furthermore advanced device capabilities like contacts, storage and sensors is normally restricted. The need for an active data connection will also lessen the user experience, when the user is within grey areas with lower bandwidth.

Resides in the platforms

ecosystems, just like native apps. Let you build once for all

platforms, same as for webapps.

Some advanced device capabilities are not available. Minor

(21)

Source Translation (transpiling)

Source translation [Plaisted2013] (fig. 4-5) is another option. It is the process of translating programs from one high-level programming language to another. Using source translation business logic can be developed in one language, and then be translated to the language that is used for native development on the different platforms. Development of the UI will be carried out using the platform-native language, and will be built specifically for each platform, and no translation is expected on the UI layer.

Fig. 4-5 Source translation strengths and weaknesses

4.1.1 Researched languages and products

Problem: What are the products and languages currently on the market for cross

platform mobile development?

Analysis: Searching the Internet, it is easy to find a lot of options for mobile

development. First search on Google on “Mobile framework multi platform” gave an indication that the term is not multi platform, but cross platform. It is important to use the correct terminology to the continuing research on cross platform mobile development. A search on Google scholar for “cross platform mobile” showed an interesting article [Hartman2011], which provided a list of cross platform mobile options. Although the list is just a few years old, the list had several products, which isn’t available at all anymore. This tells us that the market hasn’t had time to stabilize yet, with options coming and going. One must be careful when selecting the platform for app development, and take the risk of vendor lock-in and vendor “death” into consideration.

UI development is native, meaning a native look and feel is easily ensured.

(22)

By googling the products presented by Hartman [Hartman2011] other papers with more products came to surface. When investigating Appcelerator a reference [AppceleratorGartner2014] to a new gartner report showed up: Magic Quadrant for Mobile Application Development Platforms [Gartner2014]. This report has gathered what I expect to be the closest thing to a complete list of options for mobile

development. During the research of vendors and products listed by Gartner

[Gartner2014] a list of frameworks was found on Wikipedia [Wikipedia-1], which has been used as a third resource for investigation. The list (table 4-1) presented

hereunder is compiled by first a research of options from Hartman [Hartman 2011] and second research of options from Gartner [Gartner2014], and third Wikipedia [Wikipedia-1], and then only including feasible options for cross platform

development with a native approach. Hartman [Hartman2011] presents 22 options, and Gartner [Gartner2014] presents 86 options, and Wikipedia [Wikipedia-1] presents 28 options that are taken into consideration when compiling the list2.

Solution: The first result of the analysis is the list in appendix A (table A-2) containing

80 options for cross platform mobile development. Many programming languages are in play in mobile development, as well as different approaches to support the many different device architectures on the market. This list (table A-2) of 80 options, which this analysis has considered viable for general3 mobile development, is broken down further to only include options viable for development of non-game native mobile applications with a focus on a native UX true to each platform.

Stages in compiling the list (table 4-1) based on table A-2:

1. All options targeted hybrid and/or webapps development is removed: a. Alpha Software, AppFurnace, AppGyver Supersonic, Convertigo,

Cordova, Globo, MicroStrategy Mobile Apps, Oracle Mobile

Application Framework, PhoneGap, Pro Gamma Instant Developer, Telerik AppBuilder, Click Software, appery.io, Appticles, Backbase, DSI Mobile Platform, i-exceed Appcillon, NSBasic, Pega Mobile, Progress Pacific, Rocket LegaSuite Mobile, Application Craft, AppsFreedom, bMobilized, Bootstrap, Dojo, dudaMobile, Enyo JS, goMobi, Gumby Framework, HP Anywhere, Jo, JQuery Mobile, Mendix, Mobl, mofuse, MooFWD Zubron, Next, Paradise App Designer, Sencha Touch, Skeleton, Telerik KendoUI, WebApp.net, Xui, Zurb.

2. Options where the products native capability only provides an SDK for integration with a main business product, and not providing a product for general development is removed:

2_{See Appendix A for a full list of all researched options including options that did not qualify}

for the list of cross development options.

3

(23)

a. SAP Mobile Platform, Verivo Akula.

3. Options targeted game development without a reasonable possibility of building a native UX, and options without a reasonable possibility of building a UX with a native look and feel, is removed:

a. Unity 3D, Gamesalad, MoSync, Runrev LiveCode, RhoMobile, Movilizer, Adobe AIR.

4. Development support for all of Android, iOS and Windows Phone is required, and technologies that does not include or plan to include this support is removed:

a. RoboVM, RubyMotion, Tabris.

5. Source translation needs to prove its worth to be considered a viable solution, so products using this approach are removed:

a. j2objc, JUniversal.

6. Some products were not available for evaluation due to e.g. lack of information about getting and using the software, or a longer process of acquiring the software:

a. Retriever RADE.

7. Platforms that require an on premise server for any app is removed: a. Verivo Akula.

8. Remaining code-free solutions is removed (delimitation): a. Icinetic AppWorks, July Systems, Magic Software 9. Products that currently only support one platform is removed:

a. React Native

Product Language

AnyPresence HTML5, JS, Native languages Appcelerator Titanium JS

C++ Builder XE7, Embarcadero C++

Clang C++

Codename One Java

Corona Lua

Embarcadero AppMethod C++, Object Pascal

FeedHenry HTML5, JS, Native languages IBM MobileFirst HTML5, JS, Native languages

Kinvey HTML5, JS, Native languages

Kivy Python

Kony HTML5, JS, Native languages

Marmalade C++

QT C++, QML/JS

Visual C++ for Cross-Platform Mobile Development

C++

Xamarin C#

(24)

4.1.2 Conclusion on development options

There are many options to consider for cross platform development, and many are promising to deliver easier development for multiple platforms. It is a hard task to get an overview of the options on the market, and even harder to select one out of the many for the development of your product. There are risks associated with selecting a specific product for development. You need to consider vendor lock-in. Will the choosing of a product allow you to move over to another vendor later, or will it not? Already vendors have left the market due to the high competition, and with the size of the market and the fast evolvement, you must expect more takeovers and

bankruptcies. Developers are searching for feasible ways to develop apps with a cross platform mindset, and the market will continue to evolve heavily over the next years. From this list some of the products will be selected for further analysis and evaluation of development experiences.

4.2 The industry view

What does the industry say about mobile development?

VisionMobile, a research company in the app economy, presents their view on mobile development in their recurring report: “State of the Developer Nation”

(25)

Fig. 4-6 HTML vs. Native

Interest in developing for Internet of Things (IoT), other than smartphones and tablets, is on the rise. This is documented both by Vision Mobile

[VisionMobile2015Q1] and Appcelerator [Appcelerator2014Q3]. The latter also mentioning the fact that the most difficult obstacle to timely app release is finding skilled resources. This is recognized by more than a third of both developers and IT decision makers.

As seen on InfoQ [InfoQ2013] the most important driver for developers to use HTML for app development is the cross platform code portability. What is then stopping developers from using HTML? That is performance issues and the limited access to platform specific features – the hardware APIs.

Although some are still trying to create one tool to allow a complete single codebase for the major platforms, developers are realizing that Android, iOS, and Windows Phone have fundamentally different design guidelines, and are having different sets of native UI controls, all of which is updated frequently by Google, Apple, and Microsoft [RexStJohn2015]. This makes it hard for anyone to create a platform that supports “Develop once, deploy anywhere”.

Dropbox [Dropbox1] has realized that the UI is best done with the native tooling, and that it is not feasible to go for a completely single codebase that also embraces the UI layer. But Dropbox wants to come as close to a single codebase as possible, and have redeveloped their apps utilizing common business logic across their iOS and Android apps.

If we turn to Microsoft they have long tried to reduce the number of codebases for their Office product, and their approach is equal to Dropbox. Currently having a reuse percentage above 90, e.g. PowerPoint for Android includes 95% of shared code [MSOffice1].

“The gap between HTML and native is widening. The native SDKs introduce new APIs at a faster rate than HTML5 can keep up with. To harness the power of these new APIs native is the only viable option.”

Conny Svensson,

(26)

4.2.1 Survey

To get closer into the minds of developers the survey described in chapter 3.2 was created and shared to gather the opinions on mobile development.

The survey was shared with/sent to:

 Current work network

 Network of fellow master students known from classes on software construction

 LinkedIn network

 LinkedIn groups:

o Mobile Software Development Group o Scandinavian IT Professionals

o Digital Open Minds

o IT Development Professionals (Denmark)

o Mobile App Design, Development & Promotion ★ Android ★ iPhone o Software Design Patterns and Architecture

o The Enterprise Architecture Network o IT People Denmark

 Forums:

o Eksperten.dk o dreamincode.net o xda developers

 Prosa (union), with no feedback

 ComputerWorld, with no feedback

(27)

Fig. 4-7 Respondent location

Most of the developers responding to the survey would approach app development using native development tools for each platform – varying from 78-92% of the respondents (fig. 4-8, 4-9, 4-10). The rest is mainly choosing cross platform alternatives. The respondents were asked to select the official approach to the platform or describe some other alternative they preferred.

Fig. 4-8 Android approach

Respondent location

France Switzerland Germany Denmark Spain Faroe Islands Great Britain India Jordan Philippines Serbia Sweden US

How would you approach the development of an app for Android?

Using the Android Development Kit from Google (the maker of Android) and Java

B4A Cordova

google sdk + c++/objC/asm

(28)

Fig. 4-9 iOS approach

Fig. 4-10 Windows Phone approach

Of the cross platform options most people are aware of the most well-known, most of which are targeted development of hybrid or webapps like PhoneGap, Cordova and JQuery Mobile. Of the other tools Xamarin is known by over 50% and Adobe Air is known by more than 25% of the respondents.

How would you approach the development of an app for iPhone (iOS)?

Using Xcode and Objective-C and/or Swift, which is provided by Apple.

B4i C++ Cordova IntelliJ Idea

Investigate cross-platform frameworks. React Native

How would you approach the development of an app for Windows Phone?

Using Visual Studio provided by Microsoft and C# or VB.

Cordova IntelliJ idea

(29)

Fig. 4-11 Development options

Most respondents prefer a native strategy for app development (fig. 4-13), and over 80% prefer native development tools for mobile development (fig. 4-12). The latter

0 5 10 15 20 25 30 35 40 45

Native (Android Development Kit, Xcode, Visual… Xamarin Codename One Marmalade PhoneGap Cordova Appcelerator Titanium Adobe Air JQuery Mobile JUniversal QT Sencha Touch RhoMobile (Rhodes) Corona IBM MobileFirst Tabris FeedHenry Kinvey RoboVM J2objc WebApp.net Xui Jo AML Visual C++ for Cross-Platform Mobile Development MoSync Clang Telerik AppBuilder Kony SAP Mobile Platform Pega Mobile Salesforce Mobile MicroStrategy Mobile Apps Oracle Mobile Application Framework DSI Mobile Platform Embarcadero AppMethod Verivo Akula ClickSoftware Other

(30)

means that to create an app for more than one platform, a tool for each platform is preferred.

Fig. 4-12 Products preferred

Regarding the code-free solutions (fig. 4-14) people are mainly unaware of the options in the market, with 91% not knowing any.

0 5 10 15 20 25 30 35 40 45

Native (Android Development Kit, Xcode, Visual… Xamarin Codename One Marmalade PhoneGap Cordova Appcelerator Titanium Adobe Air JQuery Mobile JUniversal QT Sencha Touch RhoMobile (Rhodes) Corona IBM MobileFirst Tabris FeedHenry Kinvey RoboVM J2objc WebApp.net Xui Jo AML Visual C++ for Cross-Platform Mobile Development MoSync Clang Telerik AppBuilder Kony SAP Mobile Platform Pega Mobile Salesforce Mobile MicroStrategy Mobile Apps Oracle Mobile Application Framework DSI Mobile Platform Embarcadero AppMethod Verivo Akula ClickSoftware Other

(31)

Fig. 4-13 Mobile strategy preferred Fig. 4-14 Code-free

Many respondents recognize cross platform mobile development as a challenge within mobile development that hasn’t the right tooling yet, but done right would mean a great deal to the development of apps. Many developers would prefer better options for code reusability across platforms, preferable with as few tools and languages as possible to do the job. Another challenge is maintainability which is another argument for better cross development options. When it comes to

maintainability there are several factors to consider when approaching the goal of a single codebase e.g. developer language competencies.

Respondents are also concerned with the right look and feel and the UI development, which makes it more difficult to select a single product for development, as the development of the UI is very different across platforms.

Concerns about cross platform development are: Third party dependencies and the updating of these, which must be in sync with the mobile OS vendors, support of platform features, performance, community support, and look and feel.

Which strategy do you prefer for

mobile development?

Native Hybrid Webapps Other

Do you know of any code-free

solutions for mobile

development?

(32)

4.2.2 Interviews

Some of the Danish app developers (table 4-2) have been asked to answer a small set of questions regarding mobile development with a focus on cross platform development and development options in that regard. Googling for app developers in

Denmark resulted in these companies, which was contacted and asked to answer a few questions. About a handful of these developers were willing to answer the questions and give their view on mobile development as of today.

The purpose was to get an understanding of how developers work with app creation and to understand the challenges of mobile

bluefragments redWEB Novasa Interactive Nodes iDeal Development Dwarf No answer Lector No answer AppTown No answer Centic No answer InSilico No answer Table 4-2 Interviewees

development, especially the challenge of supporting several platforms, and to understand if the right tooling was available to support the process of developing applications for more than one mobile platform.

(33)

•A. Hedegren: Yes, that is the way, when you develop natively.

•E. Bjerregaard:Yep, 3 languages: C#, Java and Objective C. Practically speaking, the 3 languages are very different, and you can easily get a bit skizofrenic of shifting between them. That is why, we try to let som people develop Java/C# and others Objective C.

•Truong: Because we have developed natively using the 3 languages for a long period of time, it is faster for us to develop natively compared to hybrid solutions. There are often so big code-wise differences between the platforms that the development of the 3 apps experiences different technical challenges, even though it is the same feature that is developed for the 3 platforms. Usually Android development is faster, but then the testing takes longer, due to number of different devices.

•T. Steen: Not a problem. Currently I only work with iOS and Android, but I have enough experience with .Net that I relatively quickly could get into WP, if it were a topic.

•T. Martinsen: There are many aspects to consider. For many companies, it is typically the development cost of creating 3 apps that scares them from developing the 3 apps, and instead just 2. The possibilities that have emerged with cross platform technologies e.g. Xamarin and Cordova (Phonegap) has got the attention of many companies, due to the cost-wise benefit.

1.a. What do you think about developing an app for all of iOS, Android and WP - Three languages?

•A. Hedegren: Since we started 11 years ago, we have developed for many platforms e.g. BlackBerry and Symbian. Today it is mainly iOS, Android and WP.

•E. Bjerregaard: Once in a while we use Unity, which can run on alle 3 platforms and desktop/browser.

•Truong: We are also developing web projects, and for mobile apps, we have started to use the Xamarin platform.

•T. Steen: Not currently.

•T. Martinsen: No, not really, but I keep an eye on what happens of course. With time the term "devices"/"mobile" is getting more fluent, and in the future the focus will probably not only grasp the 3 platforms, but also gaming consoles, TV's etc.

(34)

•A. Hedegren: We require such large demands for code quality, UX, response time and future-proofing that cross platform tools is not an option at all. Furthermore we seek to attract customers that is not interested in cutting cost at the expense of quality. We often use web content to show static content that have to be the same regardless of the platform. •E. Bjerregaard: Well yes, that is kind of the holy grail. Code once and reuse on all platforms.

Practically, it is difficult. There are tools that try e.g. Xamarin, but it does not work great. There are quite big differences between the platforms. E.g. a demand for a physical back button on Android, but not on iOS. So you always have to consider back buttons in the UI on iPhone, but not on Android.

•T. Steen: I believe that there are several hybrid solutions that can handle all three platforms.

2. Do you know if it is possible to use one language for all the three platfroms?

•A. Hedegren: Only for web.

•Yes, we do that already with Xamarin.

•T. Steen: As such it isn't the language that is the problem of having three different platforms. I have no problems in shifting between different languages. The problem is that you have to have and maintain three different codebases. A single language would help in the sence that it would make possible to have one codebase for all three platforms. This is though discouraged by the fact that the three different platforms are different. So you will have to make

compromises on either features or design, or there will have to be made exceptions in the codebase to handle the differences of the three platforms. Lastly, it is very important to think about how functional the language is, that are to replace the three others. Java, Objective C and .NET are all very mature having lots of features and mature API's that offer competent code completion and test/bug hunting features.

•T. Martinsen: Xamarin makes it possible to use C# for business logic for all three mobile platforms. Cordova makes it possible to use javascript/html.

2.a. Would you like to use a single language?

•A. Hedegren: It is our impression that many developers are.

•T. Steen: It is my understanding that many developers use Cross Platform udvilking.

3. Are developers generally aware of cross platform development possibilities?

•A. Hedegren: Yes

•E. Bjerregaard: Yes. I think so. we regularly try new tools. So far it is just not good enough, and therefore we code using the three platforms "native" languages.

•Truong: Yes

•T. Steen: I think generally not that I have seen many webapps. Although it may be that either they generally are outside my area of interest, or that I am not aware that an app is a webapp. •T. Martinsen: Many developers, especially windows developers, are well aware of this problem.

I think many development houses have it on their mind, but not all do much about it. Presumably they will have to in the future.

(35)

•A. Hedengren: Basically, we develop native but occasionally integrate web elements, so that in principle we can call them hybrid apps. Basically we always develop interaction elements native, and excludes any web elements for text-heavy, static pages that might be edited via a CMS. We always strive to only use web elements, if it can not be differentiated from the native look.

•E. Bjerregaard: NATIVE! It is the only way to keep the UX right. We still need to see a webapp or hybrid app having UX done right. We have tried with hybrid apps a couple of times, but

everytime we have stopped, and done it the right way; Native!

•Truong: Native - native is still our preferred strategy, especially on larger business critical projects. There are better support from communities, and qua our experiences it is faster and we can deliver a better quality. Hybrid - The only hybrid platform we go with is Xamarin. It seems most promissing. We still don't believe in e.g. Phonegap. It is though a huge

disadvantage to be dependent of yet another third party platform. E.g. we are depedent on that Xamarin supports new OS updates. Webapps - If we develops wepapps, then we always build it as a responsive site.

•T. Steen: I prefer native development. It gives the full breadth of functionality, and brings the current platform in focus, so that the apps generally gets better adapted the design

philosophies on each platform.

•T. Martinsen: Native is clearly the preferred way, with a cross platform engine like Xamarin for the common business logic. It is a bit more expensive than webapps, but gives a much better performance, better integration and a better UX, which counts a lot.

4. Which strategy do you prefer for the development of apps and why (Native, hybrid or webapps)?

•A. Hedegren: Xcode, Android Studio, Visual Studio.

•E. Bjerregaard: We use XCode for iOS development, Visual Studio for WP and Eclipse for Android development. Visual Studio is clearly the best tool.

•Truong: Android Studio and Xcode.

•T. Steen: Android Studio for android, XCode and AppCode for iOS (AppCode primarily). For WP, I would most likely end up using Visual Studio.

•T. Martinsen: Visual Studio and Xamarin.

(36)

Summing up

Most developers believe that the way to build apps, is to do it the native way primarily using the tools provided by the mobile OS vendors – you could call it true •A. Hedegren: No, but it sounds terrifying.

•E. Bjerregaard: Well yes, I have seen some, bu I can't remember any product names. The apps that are made using these are generally hideous looking.

•Truong: No. •T. Steen: No.

•T. Martinsen: Microsoft created Project Sienna as such a drag'n'drop app for making Windows 8 apps. I am not a fan, but I can see some wins with that approach - e.g. that product owners that are not technicians can develop something.

6. Do you know any code-free solutions for mobile development?

•A. Hedegren: To create the best possible product within the boundaries of the given budget. •E. Bjerregaard: Two things: The limited resources available on a phone e.g. CPU, GPU and RAM.

The silent requirement of efficient code. This is something we think is very interesting in app development. Secondly, the network connection. This places great demands on apps that the network can come and go, and be of different quality. Ideal apps has a quite sofisticated strategy, where e.g. pictures are fetched in a lower resolution on Edge than on 3G. It is about giving the user the feeling that things run smooth even if the network suddenly disappear. •Truong: External factors, such as 3. party integrations, Apples approval proces, and of course

when it is new (sometimes beta) teknology we have to work with e.g. the Beacon technology. •T. Steen: The app market is maturing, so the biggest challenge, for the momemt, is the

extended amount of quility apps. Many niches have already been filled, so it is no longer that easy to create a good app and make money of it.

•T. Martinsen: Cross platform and device variations. Device variations within Android is a gigantic issue.

7. What is the greatest challenge within mobile development?

•A. Hedegren: A whole lot, and more than i have time to mention, but for instance: You are dependent on another vendor than the OS vendor, and you are thereby one step away from the metal. It is harder to debug and optimize. UX stinks almost always in cross platform apps, and the possibilities for very dynamic and complex UI's are limited. The platforms are different, and once in a while we end up with quite different solutions across the platforms. If you want to make apps, that are on the leading edge, then you can't be satisfied having some sort of framework between yourself and the platform you are working with.

•Truong: You are dependent on yet another external platform. Still small developer community to search for help.

•T. Martinsen: It is an issue that it is not possible to compile for iOS on other than a native Mac device. It presents a number of limitations to the development and is part of increasing development costs.

8. Do you see any issues with cross platform mobile development?

•A. Hedegren: It is difficult, expensive, and it shows if you cut costs.

(37)

native. Only a few recognizes the strategy of platforms like Xamarin as a possible

future for developing mobile applications, although most agree that it is not optimal to develop the same app several times to support the major platforms. Some argue that third party tools cannot deliver the same quality apps that they can provide with the true native way. Apparently the answers indicate that app developers are aware of the possibilities of using cross platform possibilities. Most don’t know of code-free solutions and don’t like the idea. One believes that the quality of such is poor. Another recognizes that there might be a demand for easier development of apps, development that not necessarily requires a developer.

4.2.3 Conclusion on the mobile development industry

If we reflect on the direction the developers and companies are heading, we see a trend towards native application development that have a goal of sharing code across platforms. We see that the platforms have many differences and many updates of the differences, and that doesn’t make it feasible to pursue a goal of “Develop once, deploy anywhere”.

The survey, although having only 60 respondents, gives an idea of the developer view on mobile development. In general developers are not aware of the many options on the market, and besides the few third party options that have been able to create some awareness, developers only know of the official tools from Google, Apple and Microsoft. Mostly when developers think about cross platform development within mobile, they think of web solutions that is enabled by the hybrid and webapp

approaches. Developers would like to see better cross platform options for the native approach, as the current development mainly is about creating an app for each platform without any code reusability. Better options for cross platform development would mean easier development and easier maintainability, especially if fewer tools and languages could be used for the development of apps with a single codebase. Challenges with cross platform mobile development is considered to be for the tools to keep up with the mobile OS vendors and keep current with the different platform features, and the look and feel of apps that are different on each platform.

Most of the interviewed app developers focus on the probable weaknesses they foresee regarding cross platform development. Not a lot of focus is on the benefits that it can provide. Going onwards the learnings from these interviews will be taken into consideration in the search for cross platform native solutions. It would indeed be interesting to research how far code-free solutions have come, as 13 of the 80 recognized options for cross platform development are code-free4.

The lack of awareness about cross platform development, and the culture amongst developers that doesn’t question platform specific app development, results in a

4

(38)

developer community that, in large part, does not consider cross platform

development doable. This has a great influence on the chances for development to move against a more cross platform way of thinking.

4.3 The Dilemma – Selecting the mobile strategy

When you are starting a project of creating an app, you need to consider your target group and whether you will need to create the app for several platforms. When you choose to target several platforms, you will have to select a strategy for developing the app. Will you build the app several times, once for each platform, or will you define a cross platform strategy that lets you build the app part or the whole app using just one language, framework and/or platform.

How complex is your app? That is a question you need to consider, because the complexity of the app influences how you should build your app. A simple app can be created as a webapp. Depending mainly on the use of device APIs will effect whether you can go ahead with a hybrid app or you need to go native. If you want to ensure high performance, you will have to go native. JavaScript is not built for performance, but to e.g. optimize programmer productivity [Crawford2013].

The target in this paper will be on the more complex apps, and ensuring performance and availability of device APIs. Therefore only options for creating native apps will be considered. As already delimited in chapter 2, code-free solutions will not be

investigated further in this paper.

4.3.1 Which and Why?

A subset of the list of viable development options (table 4-1) will be used to implement the case stories described in chapter 3, if they pass the Hello World test (chapter 3.4.1). The measurements will be recorded according to defined metrics (chapter 3.4.2). To evaluate and compare the development options, implementations using native Android and iPhone (iOS) technologies are implemented.

Native Android

Reference implementation of stories will be created using the Android Studio [Android Studio]. Android Studio is the official IDE for Android development. It is based on IntelliJ IDEA, and offers e.g. a Gradle-based build system. Android Studio was released in December 2014. Before Android Studio, Android development was usually done with Eclipse and the Android Development Kit. The implementation of the stories using the Android Studio will provide grounds for comparing and

(39)

Native iPhone (iOS)

Reference implementation of stories will be created using Xcode [Xcode]. Xcode is the IDE for iOS and OSX development. Xcode has been available since the fall of 2003. The implementation of the stories using Xcode will provide grounds for comparing and evaluating development options.

Xamarin

The Xamarin platform is built to provide a single language, C#, for the development of apps. Xamarin uses the Mono Framework to execute compiled C# source code on the different platforms. Xamarin integrates seamlessly with Visual Studio, but Xamarin does also provide its own IDE – the Xamarin Studio. Xamarin 2.0 was released in early 2013 and was the first unified Xamarin platform, which embraced before separate iOS, Android and OSX development tools. The Xamarin platform could then support C# code-sharing across device platforms. The Xamarin platform was selected for the Hello World test.

Embarcadero C++ Builder XE7

C++Builder XE7 [C++Builder] is supposedly the only true single source solution for natively compiled applications on Windows, OSX, iOS, and Android. It is an IDE that promises a fast creation of apps for Windows, OSX and mobile from one codebase. This had to be tested, and XE7 was selected for the Hello World test.

Visual C++ for Cross-Platform Mobile Development (VC++)

VC++ is a tool that you, with Visual Studio 2015 [VS2015], can use to build cross platform mobile apps that run on Android, Windows Phone, and iOS support was added April 29, 2015, as the Visual Studio 2015 Release Candidate was released. You can use C++ [C++] to write static or dynamic libraries that you can build for all platforms, and share your code in hybrid apps written in multiple languages. You are able to use existing C++ libraries in your apps, and reuse legacy code.

VC++ makes it possible to build cross-platform mobile native (C/C++) binaries targeting Windows platforms through the Visual C++ toolchain C1xx/C2 and the Android platform through Clang/LLVM toolchain [Asthana2014]. The Android

Platform with API Level 3 introduced the Native Development Kit (NDK) which enables creation and consumption of libraries written in C/C++. The recently added iOS extension requires an Apple Mac, because Apple does not allow software targeted OSX and iOS to be built on other hardware.

(40)

C++ is used for apps like Dropbox [Dropbox1][Dropbox2][Dropbox3] and MS Office apps [MSOffice1][MSOffice2][MSOffice3].

4.4 Hello World

5

Using the candidates identified as interesting for cross development, simple hello world prototypes will be created to confirm that a common library can be created that can be used to hold common logic/functionality that can be reused on the selected platforms without modifications.

4.4.1 Xamarin with Visual Studio6

To evaluate Xamarin with Visual Studio three projects was created, one for each of the three platforms holding the platform specific UI layer, and one project for the common library for business logic.

To support iOS development from within Visual Studio on the Windows machine, you will need access to either a Mac computer that can act as a build host or an online service that can handle the iOS builds. Having a Mac available the first option was chosen, and a connection between Visual Studio on the Windows PC and the Xamarin Build Host on the Mac computer was made. This would support development of the iOS UI and the build of the iOS app. It was not without problems to connect the two, but it was possible, although some connection waiting time was experienced. First impression of developing for iOS on Windows with a build host on Mac: it is slow. The fact that you need a Mac for designing and building apps is just a poor strategy. It should be much easier to create iOS apps and not requiring a Mac. The development setup doesn't seem to be very stable, and I worry about developing real apps this way.

The implementation of the UI is very much like using Apples Xcode, but there are differences. The UI event handling is implemented differently with Xamarin. So there are differences between developing for iOS with Xcode and Xamarin, so even if you know Xcode beforehand, you will need time to get used to work with Xamarin. Developing the integration between the iOS UI and the common library (fig. 4-15) was easy, and without issues.

5

For source code regarding Hello World see Appendix E

6

(41)

:ViewController :Shared

btnHello_TouchUpInside

hello(string text):string

C#

Fig. 4-15 Xamarin iOS

Moving on with Xamarin and Android. My impression on creating the Android app: It's easy. Referencing the shared library is not a problem at all with this simple case (fig. 4-16). How you build the UI resembles how you would do it with Android Studio. I actually think that the UI, which is defined with xml is exactly the same whether you develop using Android Studio or Xamarin, and that lessens the risk of vendor lock-in.

:MainActivity :Shared

btnHello.Click

C#

Fig. 4-16 Xamarin Android

(42)

:MainPage :Shared

btnHello_Click

C#

Fig. 4-17 Xamarin Windows Phone

Fig. 4-18 Xamarin Hello World iOS Fig. 4-19 Xamarin Hello World Android Fig. 4-20 Xamarin Hello World WP

All in all Xamarin passes the Hello World test. Apps for all three platforms was created that were able to utilize the common library, and that with a UI with a native look and feel.

4.4.2 Embarcadero C++ Builder

(43)

As with Xamarin, you need a Mac to handle the builds. Some difficulties were met connecting C++ Builder on the Windows PC to the Platform Assistant installed on the Mac computer, but the setup succeeded.

It was easy to develop the app, but to build it and test it was a lot of trouble. After spending more than ten hours on the iOS build and test without getting near a working product, iOS was given up upon.

Deploying to Android was problem free, but the UI was messed up, and did not reflect the designed layout.

C++ Builder XE7 did not offer support for Windows Phone development.

The outcome of the Hello World test with C++ Builder was not good, and C++ Builder does not pass the test.

Fig. 4-21 Layout designer Fig. 4-22 UI on Android

4.4.3 Visual C++ for Cross-Platform Mobile Development (VC++)

(44)

Prerequisites for doing this Hello World evaluation of Android, iOS, and Windows Phone utilizing a common library for business logic written using C++:



Visual Studio 2015 (RC) installed



Android Studio installed



Xcode 6.3 installed

To support iOS development from within Visual Studio on the Windows machine, you will need access to either a Mac computer that can act as a build host or an online service that can handle the iOS builds. Having a Mac available the first option was chosen, and a connection between Visual Studio on the Windows PC and the Build Host (vcremote) on the Mac computer was made. This would support the build of a library executable on iOS, which could be included in Xcode, where the iOS app, and most important the UI, is built.

The development using VC++ is way more difficult than using Xamarin. You have setups for the build for each platform to take care of, and there are many C++ specific options to consider e.g. the different compilers that are used for the different

platforms. The difference in data types available is also an important factor.

As you can develop Windows Phone apps using C++, the same way you can with C#, it is a more or less a seamless integration between the UI layer and the business layer in the common library. The Windows Phone uses Specific data types in the UI

components that are not part of standard C++, and if you want to have the common library available for Android and iOS, you will have to use standard parts for the common library. This results in a necessary data mapping between the Windows Phone UI layer and the common library.

(45)

:MainPage :CommonLibrary.WP :CommonLibrary

btnHello_Click

helloWorld(String^ world):String^

helloWorld(std::string text):std::string C++

Fig. 4-23 VC++ Windows Phone

To utilize the C++ common library from the Android Java project, you will need the Java Native Interface [JNI] to bind Java and the compiled C++ library. On the Java side you will have to implement a class to interface the native C++ library. You will define java methods that will bind to the JNI specific parts of the C++ library. In the library you will have to wrap the library methods with JNI. With JNI in a C++ header you define the coupling to the Java methods and the data types etc. used. From the compiled Java class you can have javah generate this header, which then needs to be implemented in the library. This wrapper will have to handle the type mapping between Java and C++ (fig. 4-24).

This little Hello World prototype is manageable when it comes to the JNI wrapper. Only a String type needs to be passed back and forth between Java and C++.

(46)

The iOS support of Visual C++ is brand new, and not without issues. Building the library for iOS resulted in an error and the build log was telling that you should look at the inner exception, which wasn’t present anywhere. Since the iOS part of Visual C++ is new, there are not many experiences online to learn from. On the 26th May a bug describing the same issue was raised on Microsoft Connect [iOS build issue]. This means that I cannot currently build a library that I can include in my iOS project in Xcode. Another solution is to include the C++ source code in the iOS project in Xcode, and then let Xcode handle the build of both Objective-C and C++ all together.

When you need to integrate between Objective-C and C++, you can create a wrapper (.mm file), which makes it possible to mix Objective-C and C++ code. The two

languages are created on the same basis, C, and therefore have some of the same basics e.g. the scalar types such as int, float and char.

It was a simple task to integrate the iOS app and the common library using an Objective-C++ wrapper (fig. 4-25).

:ViewController :CommonLibraryFacade :CommonLibrary

hello(id sender):IBAction

hello(NSString* world):NSString*

helloWorld(std::string text):std::string

Objective-C Objective-C++ C++

Fig. 4-25 VC++ iOS

(47)

Fig. 4-26 VC++ Hello World WP Fig. 4-27 VC++ Hello World Android Fig. 4-28 VC++ Hello World iOS

4.4.4 Hello World conclusion

Concluding on the Hello World tests, Xamarin and Visual C++ qualifies for further evaluation, and Embarcadero does not (fig. 4-29).

The only issue with Visual C++ was that Visual Studio could not build the library for iOS due to a bug in the release candidate [iOS build issue]. This was handled by including the C++ source code in the iOS project in Xcode.

(48)

Fig. 4-29 Hello World: GO/NO GO

4.5 Prototypes

7

To compare and evaluate the development of apps using native solutions provided by OS vendors and other third party solutions, the case consisting of six stories will be implemented and measured according to defined metrics (see chapter 3.4.2 Prototyping).

For every prototype the time measuring was first started when the development environment had been prepared and a project setup was ready. This was to focus the measuring on the specific story implementation at hand, and not the initial

preparations.

4.5.1 Android – Native reference

The stories will be implemented using “single” platform Android development, as oppose to cross platform development, to be able to compare the results of the different approaches.

7

For source code regarding prototypes see Appendix E

Xamarin was able to deliver

acceptable results and

qualifies for further

evaluation.

Visual C++ RC had no issues

supporting Windows Phone

and Android, but a probably

minor issue supporting iOS.

Visual C++ was selected for

further evaluation.

Embarcadero C++ Builder did

not pass the simple Hello

World test, and will not be

evaluated further. There was

just to many problems trying

to get it to work, and the test

was completely unsuccessful.

GO!

(49)

Story 1 + 2 – SQLite

An implementation of Story 1 with the help of tutorial [AndroidSQLite1] and Story 2 with the help of tutorial [AndroidSQLite2] was easily completed with Android Studio (fig. 4-30). The Android development kit comes with a built-in package for integrating with SQLite. Necessary tasks were to add an activity with controls to fulfill the stories and implement a data access object for SQLite integration.

The development took only 1 hour 22 minutes, and resulted in 286 LOC.

:MainActivity :TextDao

newText(View view)

addText(Text text)

:SQLiteDatabase

insert(String table, String nullColumnHack, ContentValues values) close()

getAllTexts():List<Text> fillList()

query(String table, String[] columns, null):Cursor

Fig. 4-30 Android Story 1 + 2

Story 3 – Twitter

Twitter provides a Twitter Kit for Android [AndroidTwitter] that uses Retrofit and encapsulates the Twitter REST API. This means that this implementation is not really an implementation of a RESTful service, but rather the Twitter Kit. This fact will properly have improved the implementation speed. The Twitter Kit provides okay documentation, and was easily implemented. I used the Otto event bus [Otto] to handle the asynchronous integration between the UI and the Twitter API. Otto is simple, fairly documented and easy to use. This first time of working with Twitter API and Otto was a good experience (fig. 4-31).

The story of implementing the Twitter integration took 1 hour 45 minutes, and resulted in 276 LOC.

(50)

:TwitterActivity :Bus lastTweet(View view) post(LoadLastTweetEvent event) :TwitterApi onLoadLastTweet(LoadLastTweetEvent event) post(LastTweetLoadedEvent event) onStoriesLoaded(LastTweetLoadedEvent event)

Fig. 4-31 Android Story 3

Story 4 – REST POST

The implementation of REST POST (fig. 4-32) was done using the Apache HttpClient [ApacheHttpClient], Otto event bus and Java Threading [JavaThreading].

The event bus and threading did make a little trouble. The bus did not accept calls from other than the main thread. A simple constructor setting on the bus did allow calls from other threads.

The development of story 4 took 1 hour 48 minutes and 298 LOC.

:RestActivity :Bus postComment(View view) post(PostCommentEvent event) :RestApi onPostComment(PostCommentEvent event) post(CommentPostedEvent event) onCommentPosted(CommentPostedEvent event)

Fig. 4-32 Android Story 4

Android project: 01:45 276 LOC

Cross Platform Mobile Development