Cross Platform Mobile Development - Computer Science …cs.au.dk/.../site_files/cs/...SoftwareDevelopment.pdf · Cross Platform Mobile Development ... The primary focus is on native

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

2015-06-14

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.

The primary focus is on native app development with Android, iOS and Windows

Phone, and not on hybrid or mobile web development.

3

Contents 1. Motivation ............................................................................................................... 5

2. Hypothesis/Problem statement .............................................................................. 9

3. Method ................................................................................................................. 11

3.1 Approaches for Cross Platform Development .................................................... 11

3.2 Survey and Interviews ......................................................................................... 11

3.3 Cross Platform Languages/options ..................................................................... 13

3.4 Evaluation of Cross Platform Development options ........................................... 14

3.4.1 Hello World .................................................................................................. 14

3.4.2 Prototyping .................................................................................................. 15

4. Analyses and Results ............................................................................................. 18

4.1 Approaches to cross platform mobile development .......................................... 18

4.1.1 Researched languages and products ........................................................... 21

4.1.2 Conclusion on development options ........................................................... 24

4.2 The industry view ................................................................................................ 24

4.2.1 Survey ........................................................................................................... 26

4.2.2 Interviews ..................................................................................................... 32

4.2.3 Conclusion on the mobile development industry ........................................ 37

4.3 The Dilemma – Selecting the mobile strategy .................................................... 38

4.3.1 Which and Why? .......................................................................................... 38

4.4 Hello World ......................................................................................................... 40

4.4.1 Xamarin with Visual Studio .......................................................................... 40

4.4.2 Embarcadero C++ Builder ............................................................................ 42

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

4.4.4 Hello World conclusion ................................................................................ 47

4.5 Prototypes ........................................................................................................... 48

4.5.1 Android – Native reference .......................................................................... 48

4.5.2 iOS/iPhone – Native reference .................................................................... 53

4.5.3 Xamarin ........................................................................................................ 58

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

4.5.5 Conclusion on prototypes ............................................................................ 76

5. Related works ....................................................................................................... 80

4

6. Discussion .............................................................................................................. 81

7. Conclusion ............................................................................................................. 82

Conclusion on the Hypotheses ................................................................................. 84

References .................................................................................................................... 86

Appendix A – A research in technologies, products and vendors ............................ 89

Researched vendors .................................................................................................. 89

Cross Platform Development Options ...................................................................... 92

Appendix B – Hardware and OS specifications ........................................................ 97

Appendix C – Hello World Tests ............................................................................... 98

C.1 Xamarin with Visual Studio ................................................................................. 98

C.1.1 Xamarin iOS Development ........................................................................... 98

C.1.2 Xamarin Android Development ................................................................. 100

C.1.3 Xamarin Windows Phone Development .................................................... 100

C.2 Embarcadero C++ Builder XE7 .......................................................................... 101

C.2.1 C++ Builder iOS Development .................................................................... 102

C.2.2 C++ Builder Android Development ............................................................ 102

C.2.3 C++ Builder Windows Phone Development ............................................... 102

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

Appendix D – Prototype Details ............................................................................. 106

D.1 Android Details ................................................................................................. 109

D.2 iOS Details ......................................................................................................... 110

D.3 Xamarin Details ................................................................................................. 111

D.4 VC++ Details ...................................................................................................... 114

Appendix E – Source Repositories .......................................................................... 116

5

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

If we take a look into our region, and look at the smartphone OS market share in

Great Britain (fig. 1-2), Germany (fig. 1-3) and France (fig. 1-4), presented by Kantar

[Kantar]. Then we can see that the tendency is the same, Android is dominating. But

here we see the effect of Apple shipping a new product, the iPhone 6, late in Q3. In

Q4 the iOS market share is rapidly increasing.

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%


Android

Blackberry

iOS

Windows

Other

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%


Android

Blackberry

iOS

Windows

Other

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

efficient than what will be possible, when doing three native versions of an app, with

three codebases. At the same time we want performance and the native feel that we

don’t think webapps can provide. We will need to define a way for us to produce apps

to our customers, and as of right now, we want to know the best way to go. To find

our way, we will have to evaluate the possibilities. This paper will function as a

preliminary research for defining a strategy towards mobile development at Process

Factory.

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

for several platforms having one single codebase for the business logic

of the app.

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 Code-free or codeless solutions provide means for developing apps without the use of code.

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

supplement the survey by interviewing developers that are working with mobile

application development. The survey and interviews will provide the base for

determining how mobile apps are built, and give an indication about the developer

awareness of the possibilities that cross platform development can provide.

The survey will be shared on social media and development forums, and thereby

targeted developers who have a minimum interest in mobile development, but not

necessarily any work experience with mobile development. I claim that with all the

information that we are bombarded with today, you will need a minimum interest in

mobile development to choose to answer a survey on mobile development. The

surveys goal is to get an insight into the broad understanding of and knowledge about

mobile development. Are the possibilities for mobile development, especially cross

platform development, known to the broad developer community?

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 regarding mobile development?

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?

•Do you see any issues regarding cross platform mobile development?

•Other comments regarding 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?

SharedLibrary.hello(“Bobby”) returns “Hello Bobby”

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

The case used for prototyping cross platform development will contain the use of

storage (local database), Application Programming Interface (API) integration

(Twitter), Representational State Transfer (REST) service integration, and location

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

•Using the GPS, show the coordinates of the current location

Device Hardware Functions

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.

Metrics for prototype development

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.

Complexity as cross-compilers needs to be kept consistent with the fragmented mobile platforms and operating systems available.

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.

The VM needs to be updated when the device vendors change the interfaces that the VM depend on.

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 adjustments for each platform.

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.

UI development in a different language than business logic, meaning your developer team must be able to program in several languages.

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 General in the sence, that the options are not considered limited to a limited business area.

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# Table 4-1 Options for cross development (delimited)

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”

[VisionMobile2015Q1]. VisionMobile recognizes that Apple has an increasing lock on

the high-end with iOS and Android dominates everywhere else, Windows Phone is

growing, and is currently at 30% mindshare. The developer platform priorities among

full time professionals show that Android has 40% of developers, iOS has 37%, and

Windows Phone and the mobile browser have just 8% and 7% respectively. Tool

awareness is rising, and more developers than ever is utilizing third party tools. Cross

platform tool adoption is rising as well. The percentage of developers using cross

platform tools has grown from 23% to 30% over the last 6 months. A decline is seen

on the targeting of mobile browsers and the overall proportion of developers using

HTML5 on mobile devices is falling. Developers are switching to native code and new

developers are adopting native platforms. One of the reasons for this is that the gap

between HTML and native is widening, as expressed by Conny Svensson, CGI (fig. 4-6)

[VisionMobile2014Q3].

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,

Managing Architect and Strategist - Mobility,

CGI Sweden

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

The survey ran over nearly three months and resulted in 60 responses from

developers from 13 different countries (fig. 4-7). The survey was marketed in two

rounds on the different media, and this experience shows that such a survey must be

marketed continuously to really bring in responses.

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 JavaB4A

Cordova

google sdk + c++/objC/asm

Investigate cross-platform frameworks.

Wait for React Native to work on Android

Xamarin

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 isprovided by Apple.B4i

C++

Cordova

IntelliJ Idea


React Native

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

Using Visual Studio provided by Microsoft andC# or VB.

Cordova

IntelliJ idea


Xamarin

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


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

Which frameworks do you know for cross platform mobile development?

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


MoSync

Clang

Telerik AppBuilder

Kony

SAP Mobile Platform

Pega Mobile

Salesforce Mobile

MicroStrategy Mobile Apps


DSI Mobile Platform


Verivo Akula

ClickSoftware

Other

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

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?

No

Yes

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.

The following pages present the interviews and the outcome gathered from these.

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.

1.b. Do you focus on other platforms?

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.

3.a. That are not webapps?

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.

5. Which products do you prefer for mobile development?

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.

9. Other comments regarding mobile development?

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 Code-free solutions is not a priority in this paper.

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

evaluating development options.

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.

The preview/release candidate of the extended VC++ tool will be evaluated, which is

the latest suggestion by Microsoft for cross platform development targeting mobile

platforms.

40

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

apps [MSOffice1][MSOffice2][MSOffice3].

4.4 Hello World5 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 See Appendix C.1 for details

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

Impressions on the Windows Phone Development: It works as I expected. No surprise

here. It is just like the native way to develop Windows Phone apps. You usually don't

need to move source code into a library, but in this case we want to separate our

business logic from the UI logic (fig. 4-17), so we can use the business logic for iOS and

Android as well.

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

To evaluate C++ Builder the goal was to create apps for the three platforms. With C++

Builder you develop your application once and then build and test it on your target

platforms.

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++)

To evaluate VC++ with Visual Studio a shared library project was created, a common

library for business logic. Then one project for each of the three platforms holding the

platform specific UI layer, was created using Android Studio for Android, Visual Studio

for Windows Phone and Xcode for iOS.

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.

To develop a Windows Phone C++ app with a C++ library is an accomplishable task.

The fact that C++ is used all over resulting in no language-to-language integrations

removes many obstacles (fig. 4-23).

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++.

:MainActivity :CommonLibrary

hello(View view)

hello(String world):String

:CommonLibrary.AndroidW

:CommonLibrary

Java_dk_bobbyz_helloworldvcppandroidapp_CommonLibrary_hello(jstring world):jstring


Java JNI C++

Fig. 4-24 VC++ Android

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*


Objective-C Objective-C++ C++

Fig. 4-25 VC++ iOS

As the UI layer is developed natively, there are no differences in this approach that

are different from building specifically for each platform when it comes to the UI, and

therefore no degrade in the look and feel.

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.

Developing for iOS is obviously more troubling than for other platforms. Apple has

been able to limit the possibilities for developers and make it harder to improve.

48

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

4.5 Prototypes7 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

! N

O G

O!

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.

Android project: 01:22 286 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)




51

Story 5 – REST GET

The REST GET story (fig. 4-33) was implemented using same technologies as for the

POST story.

As the main thread handles everything UI, it must also be the one thread updating the

UI views. The results from the GET request had therefore to be posted as an event to

the main thread, as not any thread would be able to update the UI. The bus had to be

extended to ensure that the update task was posted to the main thread.

The implementation built on the components from story 4 and added 178 LOC, which

took 1 hour 12 minutes.

:RestActivity :Bus

getComments(View view)

post(GetCommentsEvent event)

:RestApi

onGetComments(GetCommentsEvent event)

post(CommentsReceivedEvent event)onCommentReceivted(CommentsReceivedEvent event)


Story 6 – Location

The location was identified using the location services from Google

[GoogleLocationServices].

The only trouble was making the emulator ready for location services and setting the

location of the emulator

Implementing the location service took 1 hour 30 minutes.



52

Measurements – Android Native reference

Story Time LOC Main outcome Seq8

1 00:44:24 S1 + S2 Easy SQLite integration. 1

2 00:37:21 283 (MainActivity.java, activity_main.xml, Tekst.java, TekstDao.java)

2

3 01:44:54 276 (MyApplication.java, RestActivity.java, activity_rest.xml, TwitterApi.java, TwitterApiImpl.java, LastTweetLoadedEvent.java, LoadLastTweetEvent.java)

Both the Twitter Kit and the Otto event bus is very easy to get started with. The Twitter Kit documentation lacks a few details that would complete the experience.

11

4 01:48:34 298 (RestActivity.java, activity_rest.xml, Comment.java, RestApi.java, RestApiImpl.java, PostCommentEvent.java, CommentPostedEvent.java)

It was easy to implement POST using HttpClient. Otto needed a simple configuration change to accept calls from other than the main thread.

19

5 01:11:43 64 + (412 - 298) = 178 (GetCommentsEvent.java, CommentsReceivedEvent.java, AndroidBus.java and additions to: RestActivity.java, activity_rest.xml, Comment.java, RestApi.java, RestApiImpl.java)

Easy implementation of GET with HttpClient. The Otto Bus was extended to specifically post events to the main thread, because it has to handle UI updates.

20

6 01:30:21 176 (GPSActivity.java, activity_gps.xml)

It was easy to use Google Location Services. Configuring the emulator location from Android Studio had minor issues, and the easiest solution was to update the location using telnet (See Appendix D).

21

Table 4-3 Android measurements

8 Seq shows the sequence of the overall prototype development.

53

Fig. 4-34 Story 3

Fig. 4-35 Story 4 + 5

Fig. 4-36 Story 6

4.5.2 iOS/iPhone – Native reference

The stories will be implemented using “single” platform iPhone development, as

oppose to cross platform development, to be able to compare the results of the

different approaches.


As with Android the SQLite library is available as default and the library just have to

be included in the project in Xcode. Tutorial [iOSSQLite] provided details enough to

implement write to and read from the SQLite database. Having the documentation it

was easy to implement these simple stories with the native development option for

iOS – Objective-C (fig. 4-37).

The SQLite implementation of story 1 and 2 took 2 hours 50 minutes, with a total of

330 LOC.

54

:ViewController :DBManager

btnGemTekst(UIButton sender):IBAction

executeQuery(NSString* query)

loadDataFromDB(NSString* query):NSArray*

loadData()

runQuery(char* query, boolean isQueryExecutable)

Fig. 4-37 iOS Story 1 + 2

Story 3 – Twitter

Using fabric.io [fabric.io] for Twitter and Grand Central Dispatch [iOSGCD] to

introduce me to the messaging engine within iOS, the retrieval of one twitter’s latest

tweet was implemented (fig. 4-38). Fabric.io provides good help with the

implementation in the form of guided development, but it lacks the small details that

complete the integration between Twitter and the application. Some additional time

was spent to figure out the authentication mechanism.

2 hours 54 minutes was spent implementing the tweet retrieval having 179 LOC.

:TwitterViewController :NSNotificationCenter

btnRetrieveTweet:(id sender):IBAction

postNotificationName(NSString name, NSObject object)

:TwitterApi

onLoadLastTweet(NSNotification* notif)

postNotificationName(NSString name, NSObject object)onLastTweetLoaded(NSNotification* notif)

Fig. 4-38 iOS Story 3

iOS project: 02:50 330 LOC


55

Fig. 4-39 Story 3

Fig. 4-40 Story 4

Fig. 4-41 Story 5

56


The implementation of REST POST was done using NSMutableURLRequest and

NSURLConnection for the HTTP operation and Grand Central Dispatch for messaging

between UI and Service (fig. 4-43).

Although having implemented a REST api for iOS

before in another context, it took over 2 hours.

About 15 minuttes was spent fixing an error

using the UIAlertView, which is a minor detail in

the implementation.

The development of story 4 took 2 hour 3

minutes and 209 LOC.


The REST GET story was implemented using

same technologies as for the POST story without

any issues (fig. 4-44).

The implementation built on the components

from story 4 and added 87 LOC, which took 1

hour 12 minutes.

:RestViewController :NSNotificationCenter

BtnPost(id sender):IBAction


:RestApi

onPostComment(NSNotification* notif)

postNotificationName(NSString name, NSObject object)onCommentPosted(NSNotification* notif)


Fig. 4-42 Story 6

57

:RestViewController :NSNotificationCenter

BtnGet(id sender):IBAction


:RestApi

onGetComment(NSNotification* notif)

postNotificationName(NSString name, NSObject object)onCommentReceived(NSNotification* notif)



The location was identified using CLLocationManager. Since the release of iOS 8 a few

extra application setup steps has to be configured to allow the use of the location

manager. Some trouble testing the story on the simulator. The quick solution was to

shift to a real device (iPhone 5S).

1 hour 10 minutes was used to get the location on iOS.

iOS project: Story 4: 02:03 209 LOC

iOS project: Story 5: 01:12 87 LOC


58

Measurements – iOS/iPhone Native reference

Story Time LOC Main outcome Seq

1 02:05:08 S1 + S2 It was easy to implement the SQLite integration. The developer community has documented many examples that can help the implementation.

3

2 00:49:58 330 (DbManager.h+.m, AppDelegate.h+.m, ViewController.h+.m)

4

3 02:54:20 179 (TwitterViewController.h+.m, TwitterApi.h+.m)

The Twitter kit documentation is a good help, but lacks important details, details about the authentication mechanism, and that affected the time to complete the story.

15

4 02:03:27 209 (RestViewController.h+.m, RestAPI.h+.m, Comment.h+.m)

Having experience with such an implementation, the development speed is slow. An issue with the popup also increased time spent.

16

5 01:12:42 296 - 209 = 87 (Additions to RestViewController.h+.m, RestAPI.h+.m)

No issues. 17

6 01:09:48 73 (GPSViewController.h+.m)

Only issue was to test the app using the simulator. A real device was the easy solution.

18

Table 4-4 iOS measurements

4.5.3 Xamarin

The stories will be implemented using cross platform development platform: Xamarin

to evaluate development compared to native reference development. Xamarin with

Visual Studio is used to create a common library project for shared functionality as

well as projects for each of Android, iOS and Windows Phone (WP), which all will rely

on and utilize the common library.


The standard SQLite library that would have been the easiest implementation didn’t

support PCL (Portable Common Library), and could therefore not be included in the

PCL for the three Xamarin apps. Another implementation that required a deeper

understanding of the SQLite integration had to be implemented. The nuget9

SQLitePCL was used to help the implementation of SQLite integration.

9 A nuget is a packaging of a library that can be used with Visual Studio.

59

The iOS development with Xamarin has some difficulties. Minimum 15 minutes of

waiting on iOS Designer, which needs connection to Mac Build Host. The Deployment

to the device is also slow, and sometimes halts for no obvious reason.

The common library was developed along with the Android implementation, which

took 4 hours 13 minutes doing 271 LOC. Having built the library clearly improved the

implementation speed of both the iOS and WP apps. The iOS implementation took 1

hour 6 minutes with 197 LOC, and the WP implementation (fig. 4-45) took only 39

minutes having 104 LOC, although some fiddling with the version of the Sqlite dll was

required.

:MainPage :IDBManager

btnSave_Click(object sender, RoutedEventArgs e)

LoadDataFromDB(string query):List<object>

FillList()

newText(string text)

runQuery(string query, bool isQueryExecutable)

runQuery(string query, bool isQueryExecutable)

Fig. 4-45 Xamarin Windows Phone Story 1 + 2

Story 3 – Twitter

Twitter has had an architecture change, so that every request has to be

authenticated. Earlier on a simple get request could be used to retrieve data from

Twitter that was public. Because I want to implement an API, I had to find a Twitter

API implementation that could be used. With Visual Studio’s Nuget tool, it is very easy

to find and integrate third party tools. Tweetinvi was the suggested implementation,

and it did the job fine. To handle messaging between the UI and the business logic of

the Twitter API, mvvmcross’ messenger had the functionality to handle this with ease.

Once again using the iOS designer and testing on simulator or device is really

annoying. Connecting to the build host is the first problem; it is slow and only works

Android project + library: 04:13 271 LOC


Windows Phone project: 00:39 104 LOC

60

half of the time. Then there is the problem of getting to use the iOS designer to make

storyboards. Sometimes I felt very lucky, that was when the designer decided to show

up. A lot of problems were encountered testing the app. The simulator didn't want to

behave. Fortunately it was possible to test the story on a physical device (iPhone 5S).

At least half the time was spent waiting for the development environment to do its

job, and to figure out workarounds, because the development environment didn't do

its job.

The WP development also had some rare designer issues this time. An issue with the

xaml designer meant that the UI had to be implemented by hand coding the xaml (UI

xml definition). Some time was spent trying to get the designer to work. The error

could be due to preview version of Visual Studio 2015.

Again the common library was developed along with the Android project. This took 2

hours 12 minutes, with 192 LOC. Implementing the iOS UI took 45 minutes having 84

LOC and WP (fig. 4-46) took 22 minutes with 78 LOC.

:Twitter :IMvxMessenger

btnRetrieveTweet_Click(object sender, RoutedEventArgs e)

Publish<LoadLastTweetEvent>(LoadLastTweetEvent event)

:ITwitterApi

OnLoadLastTweet(LoadLastTweetEvent event)

Publish<LastTweetLoadedEvent>(LastTweetLoadedEvent event)OnLastTweetLoaded(LastTweetLoadedEvent event)

Fig. 4-46 Xamarin Windows Phone Story 3




61

Fig. 4-47 Story 3 Android

Fig. 4-48 Story 3 iOS

Fig. 4-49 Story 3 WP


The implementation of REST POST (fig. 4-50) was done using the Xamarin

implementations of the HttpClient and again messaging between UI and service with

MvxMessenger.

Issues with which elements of the .Net framework that is available in a PCL. No .Net

utility for JSON serialization was available and a third party utility NewtonSoft

[NewtonSoft] was used. This utility was already added to the project by Tweetinvi.

The async and await functionality of C# had to be understood and implemented such

that the application would not go into a waiting state/deadlock.

The loading of the iOS Designer was surprisingly fast compared to earlier experiences,

just 1-2 minutes. Building the UI with the iOS Designer was troublesome. The code

behind file for the new view controller was not generated properly. Recreating the

view controller in the storyboard did the trick.

On this iOS project and the CommonLibrary project some references was missing

regarding MvvmCross and the app would't start. Updating the MvvmCross references

helped, and the list of references was aligned with the Android project that already

worked fine.

62

Testing using the simulator on the build host was possible for the first time. It takes

some time to start the simulator on the build host from the development machine,

but no longer than usual with Xcode.

The problems with the iOS Designer prolonged the development with about 20

minutes, and the ‘References’ issue also about 20 minutes.

No issues with the WP development, which is also backed by the implementation

time logged.

Once again the common library and the Android project were developed

simultaneously. Time spent was 2 hours 57 minutes, with 247 LOC. iOS development

experienced better performance, but with a few obstacles it took 1 hour 25 minutes,

and 79 LOC. WP without issues took 19 minutes, and 81 LOC.

:Rest :IMvxMessenger

btnPost_Click(object sender, RoutedEventArgs e)

Publish<PostCommentEvent>(PostCommentEvent event)

:IRestApi

OnPostComment(PostCommentEvent event)

Publish<CommentPostedEvent>(CommentPostedEvent event)OnCommentPosted(CommentPostedEvent event)



The REST GET story was implemented using same technologies as for the POST story,

and extending the existing REST Api for the library as well as the UI parts of the

platform specific projects.

The Android and common library development was straight forward, having just

minor trouble of deserializing the array of Comment objects.

To create the iOS UI and utilizing the CommonLibrary took just under 10 minutes. But

the http client was not working, and an exception was thrown. What was working




63

with Android did not work with iOS. Analyses of the async behavior lead to no

changes. The HttpClient was not working and just hang on the get request, and

exception was thrown on the default timeout. Articles mention that the projects

targeting the different platforms must be configured to use the right dependency

containing HttpClient, else the application will not work. The iOS project setup

analyzed, and the System.Net.Http from Xamarin was referenced, and app.config

added to control the dependent references. Changing from testing on device to

simulator made the application function, at least on the simulator. It is a critical issue

that running the application on device and simulator is inconsistent. As the Android

tests are carried out using simulator as well, the iOS implementation is considered

completed, with a note regarding the aforementioned inconsistency.

WP development (fig. 4-51) had no issues.

53 minutes implementing Android and common library having 114 LOC. Due to the

fact that the iOS implementation did not function on a physical device, but worked on

simulator, additional time was spent trying to fix this issue. After 3 hours 41 minutes

and 47 LOC the iOS development was stopped acknowledging that the story only

works with the simulator. WP development took 16 minutes with 13 LOC.

:Rest :IMvxMessenger

btnGet_Click(object sender, RoutedEventArgs e)

Publish<GetCommentsEvent>(GetCommentsEvent event)

:IRestApi

OnGetComments(GetCommentsEvent event)

Publish<CommentsReceivedEvent>(CommentsReceivedEvent)

OnCommentsReceived(CommentsReceivedEvent event)





64

Fig. 4-52 Story 4 + 5 Android

Fig. 4-53 Story 4 + 5 - iOS

Fig. 4-54 Story 4 + 5 WP


To create the Location Api the nuget Xam.Plugin.Geolocator [Xam.Plugin.Geolocator]

was found to be a viable option for handling the location services. It is a port of the

functionality of Xamarin.Mobile to make it available for PCL projects.

When working with the simulator you have to remember to initialize the geolocation

of the virtual device. That is done differently depending on the simulator.

Problems with the iOS designer were experienced again. It is very random if the iOS

Designer will show the storyboard in Visual Studio. It is very frustrating to work with,

as it sometimes works and sometimes will not work for no obvious reason, and

suddenly it works again. It would be very hard to accept on a daily basis.

The app testing time while developing is longer on iOS than with Android and WP. The

simulator is running on the build host (mac) and the physical device is connected to

the build host, and the connection from Visual Studio on the development machine

(Windows PC) to the device via the mac is not very performant, and hardly

acceptable. Most of the time of the iOS development on this story was spent waiting.

After working with the iOS Designer, the WP xaml designer is a joy to work with no

waiting time at all. Also the simulator loads the app for testing in just a few seconds.

65

With Android and iOS the Xamarin Geolocator plugin works great, and there was no

issues getting the location coordinates using the physical device on iOS. The nuget

Xam.Plugin.Geolocator was not updated with a WP8.1 bugfix although the bug was

resolved, and therefore an exception was thrown when the library was used. Asking

for an update of the nuget resulted in a working nuget two days later.

The common library was developed along with the Android project, and this took 1

hour 42 minutes with 193 LOC. Creating an iOS View Controller that utilized the

common library took 1 hour 2 minutes with 64 LOC. The WP implementation took 47

minutes with 80 LOC.

Fig. 4-55 Story 6 Android

Fig. 4-56 Story 6 iOS

Fig. 4-57 Story 6 WP




66

Measurements – Xamarin Android


1 03:47:15 S1 + S2 It was easy to implement the SQLite integration with the help of the added nuget SQLitePCL.

5

2 00:25:58 271 (Main.axml, MainActivity.cs, IDBManager.cs, DBManager.cs, Tekst.cs)

6

3 02:12:14 192 (Twitter.axml, TwitterActivity.cs, ITwitterApi.cs, TwitterApi.cs, LastTweetLoadedEvent.cs, LoadLastTweetEvent.cs)

Both Tweetinvi and MvxMessenger were fairly easy to get started with, and had good documentation to help the implementation.

12

4 02:57:18 247 (Rest.axml, RestActivity.cs, IRestApi.cs, RestApi.cs, Comment.cs, PostCommentEvent.cs, CommentPostedEvent.cs)

No .net utility was available for JSON serialization in PCL, and a third party utility was used. This utility was already added to the project by Tweetinvi. The async and await functionality of C# had to be understood and implemented such that the application would not go into a waiting state.

22

5 00:52:35 361 - 247 = 114 (GetCommentsEvent.cs, CommentsReceivedEvent.cs, and additions to Rest.axml, RestActivity.cs, IRestApi.cs, RestApi.cs, Comment.cs)

Minor trouble deserializing the array of Comment objects.

23

6 01:42:20 193 (GPS.axml, GPSActivity.cs, ILocationApi.cs, LocationApi.cs, LocationReceivedEvent.cs)

When working with the simulator you have to remember to initialize the geolocation of the virtual device. With Android that can be done through telnet.

28

Table 4-5 Xamarin Android measurements

67

Measurements – Xamarin iOS


1 00:26:29 S1 + S2 Minimum 15 minutes of waiting on iOS Designer, which needs connection to Mac Build Host. Deployment to device is also slow, and sometimes halts for no obvious reason.

7

2 00:39:33 197 (AppDelegate.cs, Main.cs, RootViewController.cs, TableSource.cs)

8

3 00:44:43 84 (TwitterViewController.cs)

Again problems with the iOS Designer. Testing on simulator was a failure, both success on physical device.

13

4 01:25:21 79 (RestViewController.cs)

The iOS Designer was quicly available and usable. Missing references regarding MvvmCross was easily solved by updating the nuget.

24

5 03:40:44

36 + (90 - 79) = 47 (CommentsTableSource.cs, and additions to RestViewController.cs)

Not functioning on physical device, but works on simulator.

25

6 01:02:25 64 (GPSViewController.cs)

Again issues with iOS Designer. The Xamarin Geolocator plugin works great.

29

Table 4-6 Xamarin iOS measurements

68

Measurements – Xamarin Windows Phone


1 00:32:20 S1 + S2 Some Fiddling with the version of Sqlite dll was required.

9

2 00:06:20 104 (MainPage.xaml, MainPage.xaml.cs)

10

3 00:21:37 78 (Twitter.xaml, Twitter.xaml.cs)

The xaml designer did not work this time, and the UI was handcoded.

14

4 00:19:08 81 (Rest.xaml, Rest.xaml.cs)

No issues 26

5 00:15:59 94 - 81 = 13 (Additions to Rest.xaml, Rest.xaml.cs)

No issues 27

6 00:47:13 80 (GPS.xaml, GPS.xaml.cs)

The xaml designer is a joy to work with compared to the iOS Designer. The nuget was not updated with a bugfix for WP 8.1, and the update was requested from the developer, which delivered over the weekend.

30

Table 4-7 Xamarin Windows Phone measurements

Xamarin Conclusion

Xamarin is easy to get started with, and has a good developer community with

answers to many of the problems you meet during development. If you already know

C# and Visual Studio you have an advantage although both are easy to get started

with. Xamarin has been able to get awareness in the developer community, and is

probably the best known option on the market. Xamarin has also been able to get

recognized by Microsoft that supports Xamarin development e.g. by integrating

Xamarin in Visual Studio. The only real problem experienced with Xamarin, is the iOS

development. I don’t recognize developing the iOS UI in Visual Studio with a Mac

build host connected as viable. There are too many issues with the connection and

too much time is spent waiting on the iOS Designer.

Some issues were experienced with the runtime behavior that strangely enough

depended on the application being executed on a physical device and not in the

simulator or vice versa. Such issues must be removed to deliver a satisfactory

development experience.

69

Developing the UI is done specifically for each platform, and the layout is defined just

as you would on the native platforms. That way Xamarin can be true to the platform

specific look and feel. The code-behind, the controller code, is developed using C#.

The price of $999/year is not the deal breaker, and if Xamarin improves the iOS

development, then Xamarin is a good option for cross platform development.

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

The stories will be implemented using C++ for cross platform development of the

business logic using Visual C++. This will evaluate C++ development compared to

native reference development. Visual C++ with Visual Studio is used to create a

common library project for shared functionality. The library will be utilized by

applications built using native development environments for each of Android, iOS

and Windows Phone, such as Android Studio, Xcode, and Visual Studio. They will rely

on and utilize the common library.

Note: At this time it has not been possible to evaluate the building of C++ libraries for

iOS usage, due to a present issue [iOS build issue] with Visual Studio 2015 RC.

Therefore the part consisting of the build and usage of a C++ library for iOS is

dismissed from this evaluation.


The approach was to begin with the implementation of the Windows Phone app and

the common library (fig. 4-58). The SQLite library was already installed in Visual Studio

earlier, but a few issues with the SQLite version was recognized. This was handled by

updating the SQLite extension in Visual Studio. At first the SQLite database file was

created and the table to store the records in it, but it was troublesome to use the

database file by including it in the application. Instead the database file was

discarded, and the table was created runtime.

In Story 2 overlooking a missing "open connection" meant that about an hour was

wasted figuring out the error, although the error message was actually okay. The lack

of C++ experience might have been a factor.

With Android JNI is used to bind Java and C++ (fig. 4-59), and it takes some time to get

used to how this binding is written. When you have created the Java Class with the

native method definitions, then it is easy to use javah to create the C++ header file for

the JNI binding, but to instantiate a Java object and use it in C++ requires some

research into the JNI specifics.

Almost ten hours trying to make the Android insert data into SQLite database using

the C++ library, and this story is put to an end. Five or ten hours of more work could

probably be enough to solve the problem. It would require further research in

70

debugging native code executing on the Android system to be able to find the little

details that results in the app crashing on insert.

:MainPage :DBManager

btnInsert_Click(Platform::Object ̂sender, Windows::UI::Xaml::RoutedEventArgs ̂e)

insert(Text text)

findAll():vector<Text*>FillList()

:TextDao

query(char* query):vector<vector<string> >

Fig. 4-58 VC++ Windows Phone Story 1 + 2

:MainPage :DBManager

insertText (View view)

insert(Text text)

FillList()

:TextDao



:TextDao

insert(Text text)

Android_TextDao

Java_dk_bobbyz_crosscppandroidapp_commonlibrary_impl_TextDaoImpl_insert(jObject aText)

Java_dk_bobbyz_crosscppandroidapp_commonlibrary_impl_TextDaoImpl_findAll()findAll():List<Text>

Java JNI C++

Fig. 4-59 VC++ Android Story 1 + 2

Windows Phone project + library: 05:57 325 LOC

Android project: 09:52 525 LOC Failed

71

Story 3 – Twitter

Twitcurl [Twitcurl], a C++ library for Twitter usage, should have functionality to solve

this story. During build found that libs for Windows Phone was missing.

You could of course develop the twitter api yourself, and build an integration to the

REST Twitter interface, but that was not the point of this story.

Implementing the custom event handling between UI and business logic was harder

than expected. Having the event handling in the common library using C++ native

event handling constructs was not working. Visual Studio reported errors that

couldn't be corrected due to lack of information available about how to fix it. The

approach was changed to use platform specific event handling, as that had already

been tried with Android and iOS. Then event handling on Windows Phone with C++

would be the only untried implementation. Handling the custom events in Windows

Phone between the UI layer and the business logic took some time to figure out, and

in the end wasn’t successful. Following the documentation from Microsoft resulted in

a compilation error, due to the fact that so called native objects can’t be passed

through the handler, and this native object was just a simple instance of a class

created to contain event data. Without having much to go with, the event handling

was discarded and focus moved to the implementation of the Twitcurl library.

Twitcurl is dependent on another library cURL [cURL]. Both cURL and Twitcurl libraries

needed to be built and added to the Visual Studio solution, and included in the

projects.

The twitcurl functionality to retrieve latest tweet has been implemented in the

common library, but is has not been possible to link the library without error, and that

is the result both for Windows Phone and Android. Researching the possible

configurations of the Visual C++ projects to include the dependent libraries have not

let to a successful build. Several hours have been spent on finding a solution without

any progress, and the story is ended in a failure.


The problem here is to find C++ libraries that can handle the http request and JSON

serialization, unless you want to implement everything yourself.

Another solution would be to make use of platform specific functionality for e.g. the

http post request.

Windows Phone project + library: 05:29 Failed

Android project: 02:29 Failed

72

After having used several hours already on implementing Story 4 with Windows

Phone, most of which on trying to handle events, and not sending http requests,

another approach is needed. Focus is shifted to the http request, discarding the need

for event handling. You could probably have written your own message handling

feature within the time spent here, but that was not the point. The point is to use

generic modules for the generic parts of the application, and write your app specifics

yourself.

The application, without event handling, is almost done. Only the vital part of sending

http requests is missing. For this story the Poco library was tried. It seems to be a fair

library with many useful features. The http post request should be easy to implement.

The trouble is at runtime: DLLs are missing. The reason could be that Poco isn't

compatible with VC++ 2015 yet, and that Poco therefore needs to be adapted. That is

a viable reason, since Poco have Visual Studio version specific project

implementations for the earlier versions, and Visual Studio 2015 has not yet been

released in the final version. One must expect that maintained libraries, such as Poco,

needs a period of time to adapt to new releases of dependent projects. That is a usual

case when it comes to third party libraries, frameworks and platforms, and it can

delay the implementation of features introduced in new versions of the mobile OSs.

As it hasn’t been possible to implement the library during development of the

Windows Phone app within a reasonable amount of time, the Android

implementation is discarded. The Android implementation is equally dependent on

the common library being able to utilize Poco, which have been a failure to introduce.


Story 5 is mainly an extension of the library implementation from Story 4, and since

Story 4 is a failure, there is not a working library to build upon. Therefore it does not

make sense to implement Story 5, and it is therefore discarded.


So does it make sense to implement a Location API having the project structure of this

prototype, which is a combination of platform specific projects on the UI layer and a

cross platform business layer? The size and features of the Location API is limited, and

maybe a more viable solution would be to implement it as part of the platform

specific projects. Third party library vendors are providing location features, but do

we want to depend on a third party for this small task of retrieving the location?

Windows Phone project + library: 10:25 Failed

Android project: 01:28 Failed

73

Looking back on the difficulties integrating libraries, I say that it will not be viable

choice to integrate a library such as QT [QT] to handle the positioning part of this

story. The Location API can be built easily using the platform specific tools and

integrated with either the UI layer or the business logic layer.

Measurements – VC++ Windows Phone


1 02:33:55 S1 + S2 It is an accomplishable task to implement SQLite integration in C++ and put it in a library. Using JNI requires some research, and takes some time to get into and get right.

31

2 03:23:01 UI: 128 (MainPage.xaml, MainPage.xaml.h, MainPage.xaml.cpp) Lib: 197 (DBManager.h, DBManager.cpp, TextDao.h, TextDao.cpp, Text.h, Text.cpp)

32

3 05:28:35 UI: 101 (Twitter.xaml, Twitter.xaml.h, Twitter.xaml.cpp) Lib: 123 (TwitterApi.h, TwitterApi.cpp)

Only one C++ Twitter API found. Finding an option for messaging/event handling between UI and business logic is not straightforward, and you would probably be better of implementing it yourself. Issue with linking.

35

4 10:25:29 UI: 109 (Rest.xaml, Rest.xaml.h, Rest.xaml.cpp) Lib: 139 RestApi.h, RestApi.cpp, Comment.h, Comment.cpp)

It is not a hard task to write the business logic layer using existing libraries to handle the http requests e.g. using Poco. The hard part is to compile and link the library for the different platforms and CPU architectures.

36

5 - - As Story 5 is supposed to build on Story 4, which was a failure, then Story 5 is a failure

-

6 - - It is not considered a viable choice to build a C++ library for the platform specific location services

-

Table 4-8 VC++ Windows Phone measurements

74

Measurements – VC++ Android


1 09:51:52 UI: 162 (activity_main.xml, MainActivity.java) Java lib: 139 (TextDao.java, TextDaoImpl.java, Text.java) JNI: 179 (Android_TextDao.h+.cpp, handle.h) C++ Lib: 242 (Additions to DBManager.h, DBManager.cpp, TextDao.h, TextDao.cpp, Text.h, Text.cpp)

It is an accomplishable task to implement SQLite integration in C++ and put it in a library. Using JNI requires some research, and takes some time to get into and get right. Being able to debug the native C++ library utilized by the Android (Java) application is a must. The Android log is not providing much help, when it comes to errors in the C++ library.

33

2 - - As the insert into the database failed, the data retrieval hasn’t been resolved.

34

3 02:29:14 Trying to compile and link the common library for Android with the Twitcurl integration was a failure and wasn’t resolved. Therefore no Android specific JNI binding and UI development was executed.

Only one C++ Twitter API found. Finding an option for messaging/event handling between UI and business logic is not straightforward, and you would probably be better of implementing it yourself. Issue with linking.

38

4 01:27:40 Trying to compile and link the common library for Android with the Poco library was a failure and wasn’t resolved. Therefore no Android specific JNI binding and UI development was executed.

It is not a hard task to write the business logic layer using existing libraries to handle the http requests e.g. using Poco. The hard part is to compile and link the library for the different platforms and CPU architectures. JNI is an extra layer of complexity that you need to handle to be able to separate the UI in Java and the business logic in C++.

37

75

5 - - As Story 5 is supposed to build on Story 4, which was a failure, then Story 5 is a failure

-

6 - - It is not considered a viable choice to build a C++ library for the platform specific location services

-

Table 4-9 VC++ Android measurements

VC++ Conclusion

As the UI layer is developed natively, there are no differences in this approach that

are different from building specifically for each platform when it comes to the UI, and

therefore no degrade in the look and feel.

The experience of having implemented SQLite integrations in the earlier prototypes

meant that it was relatively easy to write the library again, this time in C++. What

wasn’t easy was to build the library, configuring the compiler, linker etc. C++ as a

language is not that hard to write, but to build using different compilers for the

different platforms and CPU architectures is rather complex and experience is a plus.

It is a quite steep learning curve to get into native, as in C/C++ development, with

Android. First of all a good understanding of C++, the compilers and the C++ standard

that these compilers support is a good basis. Then there is the JNI (Java Native

Interface) that binds Java and C++. Another issue is the debugging. It is hard to debug

the C++ library. You can add log messages that are written to the Android logcat. It

should be possible to debug the native library while running the application, but it is

not something that has been tried during this prototype. Last but not least, there is

the linking. The linking has been quite a headache during this evaluation. Building

and/including libraries for the Common Library to use has been most difficult, and is

the main reason that most of the stories resulted in failure.

The event handling regarding Windows Phone has taken a considerable amount of

time, and should probably have been a story in itself. It has mainly affected the time

spent on Story 3 and Story 4. You either need to find a good cross platform solution to

handle events between the UI layer and the business logic layer, or develop that

feature yourself.

If we consider some of the third party libraries e.g. Poco, which were a dependency of

the VC++ project, then maybe it was too early to evaluate VC++ 2015. The library

developers haven’t had much time to build new versions that support e.g. the

Windows Phone specifics delivered with Visual Studio 2015.

76

Only one story was a success. More experience with building C++ applications would

have improved the chance of success in more stories.

There are many C++ frameworks and libraries available that could be evaluated as

part of the implementation of the VC++ prototype. Evaluating these would require a

great deal, and only be a viable task, if C++ was the language that must be used.

4.5.5 Conclusion on prototypes

When we look at the measurements collected during the development of the

prototypes (table 4-8), we can compare the implementation of each story.

Generally the results of the VC++ prototype implementation are not very comparable

to the rest of the prototypes, because it was mostly a failure. This is primarily due to

the lack of experience with C++ application development. It shows though that C++

development is harder to get started with, and it has the complexities of being built

for each execution platform, whereas Xamarin is executed within a virtual machine.

The Xamarin evaluation shows that there are some issues when it comes to the use of

the iOS Designer to create the UI, whereas building the UI for Android and Windows

Phone is just as easy as if the UI was built using the platform specific tools.

We can expect that the improvements in time spent using Xamarin will improve,

compared to the platform specific implementations, as the business logic layer grows

and get more complex.

Story 1 + 2 - SQLite

The Xamarin Android implementation included the development of the Common

Library, and it took longer than both the Android and iOS implementations. But if we

look at both the Xamarin iOS and the Xamarin Android implementations that utilized

the already built library, then we see that they were implemented in lot less time.

If we look at Story 2, and take away the “random” sized iOS Designer load times, we

see that the Xamarin implementations was done considerably faster that the Android

and iOS implementations.

If we look at the VC++ WP implementation, then we must admit that development

times are not good. The experience is that, it is not the actual writing of code that

takes much more time. It is the building procedure, including different compilers and

linking of libraries that are the main concern.

If we look at the LOC for each prototype we hardly see any differences. Of course the

Xamarin library implementation is only written once, and that means a few less lines.

The VC++ Android implementation draws most attention with the most LOC. This is

77

due to mainly the JNI layer that is the binding between Java and C++, but also in this

context we have e.g. the Text class in both Java and C++.

Story 3 – Twitter

In this story all three Xamarin implementations was done faster than the Android and

iOS implementations combined. That is a surprise, and also with less LOC. Also if we

look at the implementations where both the Android and iOS are integrating the

official API provided by Twitter, and the Xamarin implementations are utilizing a third

party library to integrate with Twitter.


Again Xamarin is ahead when we want our app to target all three platforms: less time

and less code - less code to maintain.


If we disregard the important fact that the Xamarin iOS implementation did not

function on the physical device, which resulted in several hours of debugging, then

Xamarin is faster to develop with. LOC-wise we can conclude that the use of Xamarin

results in much less code on the business logic layer to maintain. That is the tendency

we see looking on all stories.


The Android and iOS uses the platform specific functionality to get the location of the

device, whereas the Xamarin implementations utilize a single third party library

within the Common Library. One drawback of using one such library is that it has to

keep up with the changes from the OS vendors. An example of this was the Xamarin

Windows Phone implementation, for which the library (nuget) wasn’t updated with

the latest fix. In this situation it was easily resolved by contacting the developer

noting the issue.

Story comparison

Story Time LOC

1 (Android) 00:44:24 S1 + S2

1 (iOS) 02:05:08 S1 + S2

1 (VC++ Android) 09:51:52 722 (Failed)

1 (VC++ WP) 02:33:55 S1 + S2

1 (Xamarin Android) 03:47:15 S1 + S2

1 (Xamarin iOS) 00:26:29 S1 + S2

78

1 (Xamarin WP) 00:32:20 S1 + S2

2 (Android) 00:37:21 283

2 (iOS) 00:49:58 330

2 (VC++ Android) - Not implemented; see chapter 4.5.4

2 (VC++ WP) 03:23:01 325

2 (Xamarin Android) 00:25:58 271

2 (Xamarin iOS) 00:39:33 197

2 (Xamarin WP) 00:06:20 104

3 (Android) 01:44:54 276

3 (iOS) 02:54:20 179

3 (VC++ Android) 02:29:14 Failed

3 (VC++ WP) 05:28:35 224 (Failed)


3 (Xamarin iOS) 00:44:43 84

3 (Xamarin WP) 00:21:37 78

4 (Android) 01:48:34 298

4 (iOS) 02:03:27 209

4 (VC++ Android) 01:27:40 Failed

4 (VC++ WP) 10:25:29 248 (Failed)


4 (Xamarin iOS) 01:25:21 79

4 (Xamarin WP) 00:19:08 81

5 (Android) 01:11:43 178

5 (iOS) 01:12:42 87


5 (VC++ WP) - Not implemented; see chapter 4.5.4


5 (Xamarin iOS) 03:40:44 47

5 (Xamarin WP) 00:15:59 13

79

6 (Android) 01:30:21 176

6 (iOS) 01:09:48 73


6 (VC++ WP) - Not implemented; see chapter 4.5.4


6 (Xamarin iOS) 01:02:25 64

6 (Xamarin WP) 00:47:13 80

Table 4-10 Story comparison

80

5. Related works Back in 2011 the Department of the Navy Grant N62909-11-1-1032, issued by the

Office of Naval Research Global (ONRG) and funded by the U.S. Army Medical

Research and Material Command, Telemedicine and Advanced Technology Research

Center (TATRC) entitled Medical Mobile Development Project, completed a research

in cross platform mobile development [Hartman2011] that this research uses as a

source for further research.

81

6. Discussion If we look into C++ development, then we see that there are many C++ frameworks

and libraries available that support several platforms and architectures, which could

be evaluated as options for cross platform mobile development. As the mobile

development industry is moving closer to a cross platform thinking, it will be

interesting to follow the development within the C++ world. C++ has an advantage as

the language is executable on most platforms, but a disadvantage in the development

of the language, as it haven’t had such a focus as more modern languages have had.

We see an improved focus on providing better options for C++ development, and the

motivation for this is smartphone and IoT development. It is interesting to see if the

development of C++ will improve on the developer mind share the coming years and

become an option for a larger part of the developers navigating in this market.

In the future we will most likely see development platforms that give you the ability

to build an app once for all mobile platforms. A trend in the mobile development

world is that, vendors are providing a platform for creating clients and servers, both

apps and backends. The last in the form of BaaS (Backend as a Service) or MBaaS

(Mobile Backend as a Service), although some claims to be BaaS, but are essentially

just PaaS (Platform as a Service). The apps are developed once for all platforms,

although with a hybrid or webapp approach. Some of these platforms have also the

functionality to build libraries that can be incorporated into native applications.

Microsoft has a new interesting approach to get more apps on Windows Phone,

which is to make Windows Phone able to run Android apps, and to provide a tool to

convert iOS apps to be able to run on Windows Phone. This could be the first step in

the direction of a common execution platform, which would ease mobile

development goal of targeting all major platforms, and thereby most consumers. The

development in this area will have a major effect on the development of cross

platform initiatives. If a common execution platform is agreed upon, then there will

only be one platform to target.

Both Google and Apple have just presented the features of the coming releases for

Android and iOS during the Worldwide Developers Conference (WWDC) 2015. The

focus is on stability and improvements. One conclusion [Dignan2015] is that both

Android and iOS are entering the service pack phase, which is a sign of maturity. If

that is the case, then it will become easier for third party vendors to provide tools and

libraries to ease the development of mobile applications, because keeping up with

new features have been one of the biggest challenges.

82

7. Conclusion Do products exist that support cross platform development?

Yes, we can’t argue with that. This research has found a long list of products that can

be used for cross platform mobile development (table A-2). Depending on the

application requirements each of the products may be a viable choice for the

development of the application to be. You will have to match the requirements to the

development approach. There are several approaches and many options for each. As

a developer (company) you would want to define a strategy for mobile app

development that takes different levels of complexity into consideration, and defines

some guidelines for each of the approaches: Native, Hybrid, and Webapp

development. These guidelines could suggest the currently best product option. It is

not a simple task, and it is guidelines that you should develop over time. There are

many factors to consider, e.g. the competencies of the developer team. Having this

strategy will not only help new projects get started, but can also guide the selection

of new employees. The strategy can bring structure to the development.

As this research shows, the market is loaded with many options for mobile

development. Probably too many, and it can be overwhelming to choose or find the

right one. Furthermore it seems, it is a hard game to sell tools and frameworks for

mobile development. The players on market are shifting fast. I find that several have

been on and now off the market e.g. CouchOne, WidgetPad, JQTouch, and Bedrock to

name a few. Another concern is that many of the frameworks are still quite new, and

presents a risk of vendor lock-in, a risk that have a huge effect, if the chosen product

for mobile development (or the company behind) has to shut down.

Are developers using cross platform options, or are the same apps with same

functionality programmed several times in different languages? Are apps developed

specifically for each platform?

During this research, it has become clear that the answer is yes, yes, and yes. Mobile

development is getting more mature, although immature still, and developers are

starting to pursue ways of better development e.g. development with code reuse on

several platforms. Native mobile development hasn’t had the right tools to make

cross platform development feasible, but that is starting to change. Microsoft has

lately seen the need for better tooling when it comes to cross platform development,

and want to support the development for Android, iOS, and Windows Phone from

one IDE, namely Visual Studio 2015 with C++ as the common denominator. A

company such as Dropbox has also seen the advantages of having a single codebase

for their apps, and have rewritten some of their apps for Android and iOS, and this

using C++. Along the way, Dropbox haven’t had the necessary tools to handle the

integration between C++ and Java and Objective-C respectively, and have therefore

built tools, such as Djinni [Djinni] which is now open sourced, to ease the

83

development. But cross platform development does not seem to be on the

developers mind. At least not yet, and the common approach is to build the same app

several times, if the app is supposed to target several platforms.

It is seen that the mobile developer community is starting to move against a more

cross platform approach, e.g. by the initiative by one of the Dropbox developers,

Steven Kabbes, who has started a project, mx3 [mx3], with the goal to showcase and

collect cross platform mobile techniques. If we turn to Google, we see that Google

Inbox [GoogleInbox] shares 70 % of the codebase between Android, iOS, and the

Web. With Google Inbox, Java is the language, which for iOS is transpiled to

Objective-C using J2ObjC [J2ObjC], and for the Web Java-to-JavaScript is handled by

the Google Web Toolkit SDK [GWT]. There are still a lot room for improvements when

it comes to mobile development.

84

Conclusion on the Hypotheses The hypotheses presented in chapter 2 are all evaluated to be valid.

Fig. 7-1 Conclusion on the Hypotheses

The options for cross platform mobile development are many, most likely to many.

The mobile development market is running fast, and products enter and exit the

market. It is difficult, and not without risks, to choose a product for app development,

and that is probably also why many developers tend to go with native development

options provided by the mobile OS vendors, because that approach doesn’t have the

risks of selecting a third party, even though code reuse then is not an option.

The quickly changing market is also a factor in why developers know so little about

the options in the market. It takes a great deal of attention and resources to follow up

on the options in the market. Just getting an overview is a considerable task.

H1

• It has been possible to find several languages that with different techniques are executable on all major platforms. With Xamarin, and the Mono engine, it is possible to build apps for the major platforms with the use of just the C# language. C++ is another language that is executable on all platforms, and is used for app development with the purpose of getting closer to a single codebase across platforms.

H2

• Using C# and the Xamarin platform it is possible to build the complete codebase with the one language, and therefore also libraries and frameworks, that target all major platforms, and also having the native look and feel. C++ can be used to build libraries for the major platforms as well. These libraries can then be utilized in the development of native apps. As C++ is only used to build libraries, it has no effect on the look and feel.

H3

• According to the studies concerning this paper the general developer do not know of the options for having a single app codebase when it comes to the native approach. Many are aware of the possibilities that the hybrid and webapp approach presents. When we ask the mobile developers, they know of some options for cross platform native development, but it is not recognized as viable yet, although many benefits are seen.

85

It is almost a part of the mobile developer’s culture to develop specifically for each

platform, and it typically takes strong arguments to change such a culture. The

developers already have a major task in keeping up with the often changes to

Android, iOS and Windows Phone, and may not have the capacity to look beyond for

options that can improve the overall development process.

One of the most popular and known options for cross platform mobile development,

the Xamarin platform, was evaluated to be a good option for cross development

showing some of the qualities wanted e.g. code reusability. Comparing Xamarin with

native Android and iOS development showed that Xamarin is competitive, and is able

to provide results equal to and in some cases better than the OS vendors provided

tools.

The evaluation of Visual C++ resulted in a failure. Only a few of the stories were a

success. The knowledge needed to build C++ applications for different platforms and

CPU architectures was underestimated.

If we compare the approaches of Xamarin and Visual C++, then Xamarin has an

advantage using the virtual machine approach compared to the cross-compilation

approach of Visual C++. When it comes to Xamarin, it handles the target platform

differences in the virtual machine, whereas with C++ you as a developer need to

handle the platform specific building including the architectures to target.

The evaluation shows that it is not just a simple task to pursue a goal of a single

codebase for all the platforms you target, and that you need to match the skills and

resources with the options available.

This research is only evaluating a few of the products available for cross platform

development, but it presents a framework for evaluation that can be built upon and

used to evaluate the products that you consider as possible options for your

development.

New platforms are entering the device market, such as the Apple iWatch, Google

Glass, Smart TVs and so on, the whole IoT. The ability to share a codebase, between

all the platforms that you want to target, will have a huge effect on your work,

because you can focus on developing the code right, once and for all.

86

References (Ordered alphabetically)

[Android Studio] http://developer.android.com/tools/studio/index.html

[AndroidSQLite1] http://www.techotopia.com/index.php/An_Android_Studio_SQLite_Database_Tutorial

[AndroidSQLite2] http://www.vogella.com/tutorials/AndroidSQLite/article.html

[AndroidTwitter] https://dev.twitter.com/twitter-kit/android

[ApacheHttpClient] https://hc.apache.org/httpcomponents-client-ga/index.html

[Appcelerator2014Q3] http://www.appcelerator.com/resource-center/research/appcelerator-2014-q3-mobile-report/

[AppceleratorGartner2014] http://www.appcelerator.com/resource-center/research/gartner-mq-2014/

[Appcelerator-IDC2014] http://www.appcelerator.com/enterprise/resource-center/research/appcelerator-2014-q3-mobile-report/

[Asthana2014] http://blogs.msdn.com/b/vcblog/archive/2014/11/12/cross-platform-mobile-development-with-visual-c.aspx

[C++] https://isocpp.org/std/the-standard

[C++Builder] http://www.embarcadero.com/products/cbuilder

[Crawford2013] http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

[cURL] http://curl.haxx.se/

[Deployd] http://docs.deployd.com/docs/getting-started/what-is-deployd.html

[Dignan2015] http://www.zdnet.com/article/apple-wwdc-2015-ios-android-enter-service-pack-phase/

[Djinni] https://github.com/dropbox/djinni

[Dropbox1] http://oleb.net/blog/2014/05/how-dropbox-uses-cplusplus-cross-platform-development/

[Dropbox2] http://channel9.msdn.com/Events/CPP/C-PP-Con-2014/015-A-Deep-Dive-into-2-Cross-Platform-Mobile-Apps-Written-in-CPP

[Dropbox3] http://channel9.msdn.com/Events/CPP/C-PP-Con-2014/Practical-Cross-Platform-Mobile-CPP-Development-at-Dropbox

[EmbarcaderoMacPA] http://docwiki.embarcadero.com/RADStudio/XE6/en/Mobile_Tutorial:_Set_Up_Your_Development_Environment_on_the_Mac_%28iOS%29

87

[EmbarcaderoWinSetupAndroid] http://docwiki.embarcadero.com/RADStudio/XE6/en/Mobile_Tutorial:_Set_Up_Your_Development_Environment_on_Windows_PC_%28Android%29

[EmbarcaderoWinSetupiOS] http://docwiki.embarcadero.com/RADStudio/XE6/en/Mobile_Tutorial:_Set_Up_Your_Development_Environment_on_Windows_PC_%28iOS%29

[EventsC++] https://msdn.microsoft.com/en-us/library/hh755799.aspx

[EventsNativeC++] https://msdn.microsoft.com/en-us/library/ee2k0a7d(v=vs.71).aspx

[fabric.io] https://dev.twitter.com/fabric/ios

[Gartner2014] http://www.gartner.com/technology/reprints.do?id=1-20TPY1B&ct=140903&st=sb

[GoogleInbox] http://arstechnica.com/information-technology/2014/11/how-google-inbox-shares-70-of-its-code-across-android-ios-and-the-web/

[GoogleLocationServices] https://developer.android.com/training/location/receive-location-updates.html

[GWT] http://www.gwtproject.org/

[Hartman2011] Gustavo Hartmann, Geoff Stead, Asi DeGani. Cross-platform mobile development. Tribal, 2011

[HTML5] http://www.w3.org/TR/html5/

[IDC] http://www.idc.com/prodserv/smartphone-os-market-share.jsp

[InfoQ2013] http://www.infoq.com/news/2013/07/state-mobile-2013

[iOS build issue] https://connect.microsoft.com/VisualStudio/feedback/details/1370422/cant-build-c-on-ios

[iOSGCD] http://www.raywenderlich.com/4295/multithreading-and-grand-central-dispatch-on-ios-for-beginners-tutorial

[iOSSQLite] http://www.appcoda.com/sqlite-database-ios-app-tutorial/

[J2ObjC] http://j2objc.org/

[JavaThreading] http://docs.oracle.com/javase/tutorial/essential/concurrency/runthread.html

[JNI] http://docs.oracle.com/javase/8/docs/technotes/guides/jni/

[Kantar] http://www.kantarworldpanel.com/global/smartphone-os-market-share/

[Magenic1] http://magenic.com/Blog/Post/4/Mobile-Development-Platform-Performance

[Magenic2] http://magenic.com/Blog/Post/59/Mobile-Development-Platform-Performance-Part-2-Native-Cordova-Classic-Xamarin-Xamarin-Forms

[MSOffice1] https://isocpp.org/blog/2014/10/office-cross-platform

88

[MSOffice2] http://channel9.msdn.com/Events/CPP/C-PP-Con-2014/024-Microsoft-w-C-to-Deliver-Office-Across-Different-Platforms-Part-I

[MSOffice3] http://channel9.msdn.com/Events/CPP/C-PP-Con-2014/030-Microsoft-w-C-to-Deliver-Office-Across-Different-Platforms-Part-II

[mx3] https://github.com/libmx3/mx3

[NewtonSoft] http://www.newtonsoft.com/json

[Otto] http://www.vogella.com/tutorials/JavaLibrary-EventBusOtto/article.html

[Plaisted2013] David A. Plaisted, "Source-to-Source Translation and Software Engineering," Journal of Software Engineering and Applications, Vol. 6 No. 4A, 2013, pp. 30-40. doi: 10.4236/jsea.2013.64A005.

[QT] http://doc.qt.io/qt-5/qtlocation-index.html

[RexStJohn2015] http://rexstjohn.com/is-react-native-cross-platform-snake-oil/

[Titanium1] http://en.wikipedia.org/wiki/Appcelerator#Titanium

[Twitcurl] https://github.com/swatkat/twitcurl

[VC++ iOS] https://msdn.microsoft.com/en-us/library/dn707598(v=vs.140).aspx

[VisionMobile2014Q3] http://www.visionmobile.com/product/developer-economics-q3-2014/

[VisionMobile2015Q1] http://www.visionmobile.com/product/developer-economics-q1-2015-state-developer-nation/

[VS2015] http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/311

[Wikipedia-1] http://en.wikipedia.org/wiki/Multiple_phone_web-based_application_framework

[Wikipedia-VM] http://en.wikipedia.org/wiki/Virtual_machine

[Xam.Plugin.Geolocator] https://github.com/jamesmontemagno/Xamarin.Plugins/tree/master/Geolocator

[XamariniOSBuild] https://developer.xamarin.com/guides/ios/getting_started/installation/windows/offline.pdf

[Xcode] https://developer.apple.com/xcode/

89

Appendix A – A research in technologies, products and

vendors

Researched vendors This is the complete lists of researched vendors in the mobile app development

market.

*included #HelloWorld $Prototype

2VizCon Too sparse information and documentation to motivate further research

Adobe Air *

Alpha Software *

AML Only Android

Andanza Technologies Only Spanish information

AnyPresence *

Apigee Only API platform, not app

Appcelerator *

Appery.io *

AppFurnace *

AppGyver *

Apple $ Only iOS

Application Craft *

appMobi Too sparse information and documentation to motivate further research

Apportable Too sparse information and documentation to motivate further research, Only iOS and Android

appsFreedom *

Appspresso Not maintained and website gone

Appticles *

Backbase *

Bedrock Out of business

Bizmatica Too sparse information and documentation to motivate further research

bMobilized *

Bootstrap *

Canappi Too sparse information and documentation to motivate further research

Capriza Too sparse information and documentation to motivate further research

Catavolt Only for data analysis in the manufacturing industry

ClickSoftware *

Codename One *

Convertigo *

Cordova *

Corona *

CouchOne Out of business

Dojo *

DSI *

90

DudaMobile *

Embarcadero *#

Enyo *

Facebook (React Native) *

FeedHenry *

FieldSync Standard solution adaptable for your business data. Not for general development

freedomone mobile Apparently out of business

GameSalad *

Globo *

goMobi *

Good Technology Standard solution adaptable for your business data. Not for general development

Google $ Only Android

Grapple Only media house open for consulting

Gumby *

Helium Too sparse information and documentation to motivate further research

Hipcricket Targeted advertising and marketing with no information about general development

HP *

i-exceed *

IBM *

Icinetic *

Infor No information about general development

iPFaces Website gone

iUI Apparently not maintained

Jembe Too sparse information and documentation to motivate further research

JMango360 Apparently limited to commerce

Jo *

jQuery *

JQTouch Out of Business

July Systems *

Kinvey *

Kivy *

Kony *

Mad Mobile Apparently limited to commerce

Magic Software *

Marmelade *

Mendix *

Microsoft *#$

MicroStrategy *

Midnight Coders Apparently limited to handle the connection (integration) between e.g. mobile applications and different backends

Mobify Apparently limited to commerce

MobileIron Standard solutions adaptable for your business data. Not for general development

Mobl *

Modo Labs Apparently limited to server-side middleware

Modomodo Apparently limited to marketing

91

MoFuse *

MooFwd *

Moovweb Apparently just for transforming desktop sites into mobile experiences

MoSync *

MotherApp Only implementor, open for consulting

Movilizer *

Neosperience Apparently limited to commerce

Netbiscuits Apparently limited to mobile analytics and detection

Next *

Nomalys Apparently limited to front Salesforce, SugarCRM and Microsoft Dynamics on mobile devices

NSBasic *

Openstream Too sparse information and documentation to motivate further research

Oracle *

Paradise Apps *

Pegasystems *

PhoneGap *

Photon Too sparse information and documentation to motivate further research

Phunware (former Digby) Targeted marketing with no information about general development

Pro Gamma *

Progress Software *

QT *

QuickConnectFamily Apparently not maintained for three years

Retriever Communications *

Resco Apparently toolkit is limited to charting

RhoMobile *

RoboVM *

Rocket Software *

RubyMotion *

RunRev *

salesforce.com High coupling with salesforce.com (backend)

SAP *

Sencha *

ShieldUI Only a components toolkit for web based development

Sita Apparently not for general development

Skeleton *

Spring Mobile Solutions Standard solutions adaptable for your business data. Not for general development

StackMob Acquired by PayPal and closed

Tabris *

Telerik *

Tibco Software Apparently limited to server-side middleware

Tigerspike Apparently only consulting and development with no products for mobile development

Unity *

Usablenet Apparently a company that implements mobile sites that have an in-house platform, which has very limited

92

availability externally.

Velti Apparently limited to advertising and marketing

Verivo Software *

Volantis Acquired by Antenna Software, which was later acquired by Pegasystems

Webalo Standard solutions adaptable for your business data. Not for general development

WebApp.net *

WidgetPad Out of business

Winksite Apparently just a mobile website builder including hosting

Xamarin *#$

Xui *

Zebra Technologies (former Motorola Solutions)

Too sparse information and documentation to motivate further research

Zurb * Table A-1 Vendors researched

Cross Platform Development Options This is the list of cross platform mobile development options for that is found to be

currently on the market.

Language Product URL Type Approach License

JS Adobe Air http://www.adobe.com/dk/products/air.html

Framework VM Proprietary

HTML5, CSS3, JS

Alpha Software

http://www.alphasoftware.com/

Framework Hybrid Commercial

HTML5, JS, Native languages

AnyPresence

http://www.anypresence.com/platform/

Platform Native, hybrid, webapps

Commercial

JS Appcelerator Titanium

http://www.appcelerator.com/titanium/

Platform VM [Titanium1] Open source


appery.io https://appery.io/ Platform Hybrid, webapps Commercial

HTML5, CSS3, JS

AppFurnace http://appfurnace.com/ Platform Hybrid Commercial

HTML5, CSS3, JS

AppGyver Supersonic

http://www.appgyver.com/supersonic

Framework Hybrid Proprietary

HTML5, CSS3, JS

Application Craft

http://www.applicationcraft.com/

Platform Webapps Commercial

Code-free AppsFreedom

http://www.appsfreedom.com/


HTML5 Appticles http://www.appticles.com Platform Hybrid, webapps Commercial

HTML5, CSS3, JS

Backbase http://www.backbase.com/ Platform Hybrid, webapps Commercial

HTML5, CSS3, JS

bMobilized https://bmobilized.com/ Framework Webapps Commercial

HTML5, CSS3, JS

Bootstrap http://getbootstrap.com/ Framework Webapps Open source

C++ C++ Builder http://www.embarcadero.co Platform Native Commercial

93

XE7 m/products/cbuilder

C++ Clang http://clang.llvm.org/ Compiler Cross-compilation Open sources

Code-free ClickSoftware

http://www.clicksoftware.com/mobile-application-development-platform

Platform Hybrid Commercial

Java Codename One

http://www.codenameone.com/

Platform VM Commercial

HTML5, CSS3, JS

Convertigo http://www.convertigo.com/

Platform Hybrid Open source GPL License or Enterprise License

HTML5, JS Cordova http://cordova.apache.org/ Framework Hybrid Open source

Lua Corona http://coronalabs.com/ Scripting language

Platform Commercial

HTML5, CSS3, JS

Dojo http://dojotoolkit.org/ Framework Webapps Open source

Code-free DSI Mobile Platform

http://www.dsiglobal.com/products/mobile-platform/

Platform Hybrid, webapps Commercial

HTML5, CSS3, JS

dudaMobile https://www.dudamobile.com/


C++, Object Pascal


http://www.appmethod.com/

Platform Native Commercial

HTML5, CSS3, JS

Enyo JS http://enyojs.com/ Framework Webapps Open source


FeedHenry http://www.feedhenry.com/ Platform, Framework

Native, hybrid, webapps

Commercial

Code-free Gamesalad http://gamesalad.com/ Platform Cross-compilation Proprietary

HTML5, CSS3, JS

Globo http://www.globoplc.com/ Platform Hybrid Commercial

HTML5, CSS3, JS

goMobi http://gomobi.info/ Platform Webapps Commercial

HTML5, CSS3, JS

Gumby Framework

http://gumbyframework.com/

Framework Webapps Open source

HTML5, CSS3, JS

HP Anywhere

http://www8.hp.com/us/en/software-solutions/mobile-application-development.html



IBM MobileFirst

http://www.ibm.com/mobilefirst/us/en/

Platform, Framework

Native, hybrid, webapps

Commercial

Code-free Icinetic AppWorks

http://www.icinetic.com/products/appworks/

Platform Native using VM, hybrid, webapps

Commercial

HTML5, CSS3, JS

i-exceed Appcillon

http://appzillon.com/en/ Platform Hybrid, webapps Commercial

Java j2objc http://j2objc.org/ Translator Source translation Open source

HTML5, JS Jo http://joapp.com/ Framework Webapps Open source

HTML5, JS JQuery Mobile

http://jquerymobile.com/ Framework Webapps Open source

94

Code-free July Systems http://julysystems.com/mobile-development-products/july-mx/

Platform Native using VM, hybrid, webapps

Commercial

Java JUniversal http://juniversal.org/ Translator Source translation Open source


Kinvey http://www.kinvey.com/ Platform Native, hybrid, webapps

Commercial

Python Kivy http://kivy.org/ Framework Cross-compilation Open source


Kony http://www.kony.com/ Platform Native, hybrid, webapps

Commercial

Code-free Magic Software

http://www.magicsoftware.com/magic-xpa-application-platform

Platform Native using VM, webapps

Commercial

C++ Marmalade https://www.madewithmarmalade.com/

Framework Cross-compilation Commercial

Code-free Mendix https://www.mendix.com/ Platform Webapps Commercial

Code-free MicroStrategy Mobile Apps

https://www.microstrategy.com/us/mobile


Mobl Mobl http://www.mobl-lang.org/ Platform Webapps Open source

Code-free mofuse http://mofuse.com/ Platform Webapps Commercial

Code-free MooFWD Zubron

http://www.moofwd.com/developers/


C/C++, JS, HTML5

MoSync http://www.mosync.com/ Framework Cross-compilation Open source

XML, .Net, Java, ABAP

Movilizer http://movilizer.com/ Platform Native using VM, hybrid, webapps

Commercial

Java Next http://nextinterfaces.com/ Framework Webapps Open source

JS, Basic NSBasic https://www.nsbasic.com/ Platform Hybrid, webapps Commercial

Java, HTML5, JS


http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html

Framework Hybrid Commercial

Code-free Paradise App Designer

http://www.paradiseapps.net/


Code-free Pega Mobile http://www.pega.com/products/pega-7#mobile


HTML5, JS PhoneGap http://phonegap.com/ Framework Hybrid Open source

C#, Java Pro Gamma Instant Developer

http://www.instantdeveloper.com/


Code-free Progress Pacific

https://www.progress.com/products/pacific


C++, QML/JS QT http://www.qt.io/mobile-app-development/

Framework Cross-compilation Open source

JS React Native https://facebook.github.io/react-native/

Framework Native with JS engine

Open source

Visual Basic Retriever http://retrievercommunicati Platform Native using VM Commercial

95

RADE ons.com/%E2%80%A2rade-for-application-development/

Ruby RhoMobile http://rhomobile.com/ Platform Cross-compilation using VM

Commercial

Java RoboVM http://www.robovm.com/ Platform Compilation + VM Commercial

HTML5, CSS3, JS

Rocket LegaSuite Mobile

http://www.rocketsoftware.com/products/rocket-legasuite-mobile


Ruby RubyMotion http://www.rubymotion.com/

Language Cross-compilation Commercial

LiveCode script, HTML5, CSS3, JS

Runrev LiveCode

http://livecode.com/products/livecode-platform

Platform Cross-compilation native, hybrid

Open source GPL3 License or Commercial


SAP Mobile Platform

http://global.sap.com/campaigns/digitalhub-mobile-platform/index.html

Platform Native, hybrid, webapps

Commercial

HTML5 Sencha Touch

http://www.sencha.com/products/touch/


HTML5, CSS3, JS

Skeleton http://getskeleton.com/ Framework Webapps Open source

Java Tabris http://eclipsesource.com/tabris/

Framework VM Open source

HTML5, JS Telerik AppBuilder

http://www.telerik.com/appbuilder


HTML5, JS Telerik KendoUI

http://www.telerik.com/kendo-ui


UnityScript, C#, Boo

Unity 3D http://unity3d.com/pages/mobile

Platform Cross-compilation Proprietary

Java, HTML5, JS, Native languages

Verivo Akula http://www.verivo.com/ Platform Native, hybrid, webapps

Commercial

C++ Visual C++ for Cross-Platform Mobile Development

http://www.visualstudio.com/en-us/explore/cplusplus-mdd-vs.aspx

Platform Cross-compilation Commercial

HTML5, JS WebApp.net Framework Webapps Open source

C# Xamarin http://xamarin.com/ Platform Compilation + VM Commercial

JS Xui https://github.com/xui/xui Framework Webapps Open source

HTML5, CSS3, JS

Zurb http://foundation.zurb.com/apps/


Table A-2 - Development options

96

Definitions for table A-2 – Development options

Type Description

Framework A set of libraries, software components and architecture guidelines that provides a comprehensive toolkit to build a complete mobile application.

Platform A set of frameworks, tools and services that not only allow the user to build a complete mobile application but also to configure, package and distribute it to app stores or the cloud. Platforms normally include integrated development environment (IDE) to ease app construction, documentation, support and automation tools.

Language Programming language

Translator Translates from on language to another

Compiler Builds executable from source code

Table A-3 Type definitions

Approach Description

Cross-compilation, Compilation

Compiling of source code into executables for selected platforms

Native Native apps are installed via an application store. They are built specifically for one platform, and can take full advantage of all the device features. Native apps can use the device’s notification system and can work offline.

Hybrid A web application hosted in native container. Installed on the phone via an application store

Webapps A web application utilized via web browser

VM Virtual Machine, provides an execution environment for an application where only the VM needs to adapt to the different platforms

Source translation

Translating og source code from on language to another

Table A-4 Aproach definitions

License Description

Proprietary The vendor is not charging for the use of the product

Commercial The vendor is charging for the use of the product

Open source The product is free to use, and the source is open

Table A-5 License definitions

97

Appendix B – Hardware and OS specifications The prototypes etc. have been developed using a Windows PC and a Mac Mini. The

main specifications are described here (table B-1).

Table B-1 Specifications

Windows Desktop PC

Processor: Intel Core i5-4690K CPU @ 3.50 GHz x64

Memory (RAM): 16.0 GB

OS: Windows 8.1 Pro x64

100 Mbit LAN connection

Mac Mini

Processor: Intel Core i5 CPU @ 2.30 GHz

Memory (RAM): 2.0 GB

OS: OSX Yosemite version 10.10.2

100 Mbit LAN connection

98

Appendix C – Hello World Tests A walkthrough of the Hello World tests executed with selected platforms.

C.1 Xamarin with Visual Studio This is an evaluation of how the hello world app can be created for the three

platforms using Xamarin with a platform specific UI layer, and common library for

business logic.

C.1.1 Xamarin iOS Development

To develop for iOS using Xamarin, you can choose to either develop on Mac using

Xamarin Studio or on Windows using Xamarin Studio or Visual Studio. To develop on

Windows you will need a Mac computer to do the actual build of the app. If you like

Visual Studio for development, then one option is to run Windows in a VM on the

Mac, and then make a connection between the host and guest for being able to

execute the builds on the host (Mac).

I already had Visual Studio 2015 (preview) on my Windows machine, so I chose to

setup my Mac as a Build Host, and connect my two physical machines10.

The setup

Having Visual Studio 2015 (preview) already installed.

1. Install Xamarin on my Windows machine

2. Create Xamarin account (30 day trial)

3. Connect Visual Studio with my Xamarin account

4. Install Xamarin on my Mac

5. Connect Xamarin Studio with my Xamarin account on the Mac

6. Disable Firewall on Mac

7. Start the Xamarin Build Host on the Mac

8. From Visual Studio connect to the Build Host (fig. C-2)

a. First try: Xamarin in Visual Studio is version 8.6 and on the Build

Host it is version 8.8 (Note: I have installed Xamarin on these two

machines simultaneously!)

b. Google the error: One hit on the opposite scenario

c. Let's try updating Xamarin in Visual Studio

d. Second try: Pairing successful. Yay!

Implementing iOS

1. Create a new project using the template Visual C# -> iOS -> iPhone ->

Single View App (storyboard support). This includes creating a new

10 See Appendix B for hardware specifications

99

solution in Visual Studio. (Note: I notice that the iOS Designer cannot be

used unless there exists a connection to the Mac Build Host!)

2. Add a new project for the shared code base using template Visual C# ->

Class Library (Portable) - PCL

3. In the class library I create a method, hello (fig. C-1), to be called by each

platform

Fig. C-1 Library

4. Add a reference to the shared library in the iPhone project

5. In the iOS project, I add two labels, a textbox and a button. I hookup the

button's event handler, and call the hello method of the shared library.

6. Launching: Trying to start the app on the iPhone Simulator. Nothing

happens for a while. I press the button "Show iOS Simulator", and receive

an error after a while, stating that the simulator couldn't start. I try again,

same error. Suddenly I notice that the simulator is starting on the Mac. I

wait till it looks ready. I launch the app using Visual Studio again. I while

after the app starts in the simulator on the Mac.

7. I test the app (fig. C-3), entering my name and push the button. It works!

First impression of developing for iOS on Windows with a build host on Mac (fig. C-2)

is, it is slow. Well, I don't have the newest top of the line Mac computer, but it

shouldn't require that many resources to build the simplest of apps, and showing it in

the simulator. According to the requirements [XamariniOSBuild] only the OS version

of OSX Mavericks or higher is a must. The fact that you need a Mac for designing and

building apps is just a poor strategy made by Apple. They want to make money on the

apps that is developed for iOS, but they will not provide solutions that make it easier

to develop the apps. I notice a few error messages while running the app. 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 even if you know one or the other beforehand.

public class Shared

{

public string hello(string world)

{

return "Hello " + world;

}

}

100

Fig. C-2 iOS build setup

C.1.2 Xamarin Android Development

1. Add new project to solution using template Visual C# -> Android -> Blank App

(Android)

2. Add a reference to the shared library

3. I add two labels, a textbox and a button. I hookup the button's eventhandler,

and call the hello method of the shared library.

4. Launching: Trying to start the app on the default Android Emulator. The

emulator starts, but not the app. I try again - no luck. I select another

emulator that I have used earlier with Android Studio, a Nexus 5 with Api 19. I

launch the app successfully.


My impression on creating the Android app: It's is easy. Referencing the shared library

is not a problem at all with this simple case. 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.

C.1.3 Xamarin Windows Phone Development

1. Add new project to solution using template Visual C# -> Store Apps ->

Windows Phone Apps -> Blank App (Windows Phone)

2. Add a reference to the shared library

3. I add two labels, a textbox and a button. I hookup the button's event

handler, and call the hello method of the shared library.

101

4. Launching: The default Windows Phone Simulator is launched and the

app runs successfully.


Impressions on the Windows Phone Development: It works as I expected. No surprise

here. It is the native way to develop Windows Phone apps. You usually don't need to

move source code into a library, but in this case we want to separate our business

logic from the UI logic, so we can use the business logic for iOS and Android as well.

Fig. C-3 Xamarin Hello World iOS

Fig. C-4 Xamarin Hello World Android

Fig. C-5 Xamarin Hello World WP

C.2 Embarcadero C++ Builder XE7 This is an evaluation of how the hello world app can be created for the three

platforms using C++ Builder with a platform specific UI layer, and common library for

business logic.

iOS Development with C++ Builder

If you want to develop for iOS using C++ Builder, then you have two options. You can

install C++ Builder on a Mac and use that for your development of iOS apps, or you

can install C++ Builder on a Windows machine, and install the Platform Assistant on a

Mac, connect these two, and then develop iOS apps on Windows. The C++ compiler in

C++ Builder can only compile for a physical iOS device, so you will not be able to use

the emulator. An iPhone must be connected to test the apps.

Setup

102

1. Install C++ Builder on Windows computer

2. Install Platform Assistant on Mac [EmbarcaderoMacPA]

3. Setup physical device for debugging with Xcode

4. Start Platform Assistant on Mac, and set password for the connection

5. Start C++ Builder, and add connection to the Mac using Connection Profile

Manager. [EmbarcaderoWinSetupiOS]

6. Use the SDK Manager to setup device and iOS version, and update local file

cache necessary for the selected SDK. (Very slow and I don't know if the files

are downloaded from my Mac, or from Embarcadero online). 4 hours later,

no progress, I cancel.

7. Retry SDK Manager. I notice a message about updating files from remote

machine, which must mean that files are fetched from the Mac. 2 minutes

later the SDK Manager has the files needed.

8. Use SDK Manager to add Android. Select NDK path and JDK path, and

everything is fine. [EmbarcaderoWinSetupAndroid]

Hello World

I want to make a simple test of creating an app for the three platforms using C++

Builder.

C.2.1 C++ Builder iOS Development

1. Create a new blank project.

2. Add controls

3. Hook up the buttons event handler

iOS impressions: Slow, slow, slow. Deployment to the iPhone is erroneous and slow.

1. XE7 upd1 => no luck

2. Googling shows a lot of people having trouble setting up for the development

of iOS apps.

3. Downgrading to XE7

4. Spending more than 10 hours, I give up on C++ Builder XE7

C.2.2 C++ Builder Android Development

1. Deploy project to Android => problem free deployment. The UI (fig. C-6) is a

bit messed up compared to the designer (fig. C-5).

C.2.3 C++ Builder Windows Phone Development

No support

103

Fig. C-6 C++ Builder Designer

Fig. C-7 C++ Builder Hello World Android

C.3 Visual C++ for Cross-Platform Mobile Development (VC++) The setup

Having:

Visual Studio 2015 (RC) installed

Android Studio installed

Xcode 6.3 installed

iOS requires a Mac for building the software, and a build host (vcremote) must be

configured on a Mac computer. The Windows machine with Visual Studio needs a

connection to the build host [VC++ iOS].

Hello World

I want to make a simple test of creating an app for the three platforms using VC++.

104

C.3.1 VC++ Windows Phone Development

1. Create a new project using the template Visual C++ -> Cross Platform ->

Shared Library (Android, iOS). This includes creating a new solution in Visual

Studio.

2. Add another project for the Windows Phone App using template Visual C++ ->

Windows -> Windows 8 -> Windows Phone -> Blank App (Windows Phone)

3. In the shared library I create a method, hello (fig. C-8), to be called by each

platform

Fig. C-8 Library

4. Add a reference to the shared library in the WP app project

5. In the WP app project, I add two labels, a textbox and a button. I hookup the

button's event handler, and call the hello method of the shared library.

6. Add intermediate wrapper class between UI and the shared library to handle

type casts

7. I test the app (Fig. C-9), entering my name and push the button

The WP app uses some Windows specific data types that need to be parsed to types

that can be used on all platforms.

C.3.2 VC++ Android Development

1. In Android Studio; create new Android app project

2. Create a new java class to wrap the native c++ shared library including the

hello method.

3. In the Android app project, I add two labels, a textbox and a button. I hookup

the button's event handler, and call the hello method of the shared library

4. Use javah to create c++ header file based on the shared library wrapper

5. In Visual Studio, add the just generated header file, and implement the hello

method, and have it call the c++ shared library

6. Build the Android shared library

7. Copy the .so file to the Android app project

8. I test the app (fig. C-10), entering my name and push the button

public class Shared

{

public string hello(string world)

{

return "Hello " + world;

}

}

105

C.3.3 VC++ iOS Development

Build issue with VC++ and the build host vcremote. For the Hello World test, this was

resolved by changing approach. This meant that the common library part of the

source code was included in the iOS project in Xcode. Note: This is not the VC++ way

of developing for iOS.

1. In Xcode; create a new iOS project

2. Add controls to storyboard

3. Create Objective-C++ wrapper

4. I test the app (fig. C-11), entering a name and push the button

Fig. C-9 VC++ Hello World WP

Fig. C-10 VC++ Hello World Android

Fig. C-11 VC++ Hello World iOS

106

Appendix D – Prototype Details All prototype measurements ordered by implementation sequence (table D-1).

Story Time LOC Seq11

1 (Android) 00:44:24 S1 + S2 1

2 (Android) 00:37:21 283 (MainActivity.java, activity_main.xml, Tekst.java, TekstDao.java)

2

1 (iOS) 02:05:08 S1 + S2 3

2 (iOS) 00:49:58 330

(DbManager.h+.m, AppDelegate.h+.m,

ViewController.h+.m)

4

1 (Xamarin Android)

03:47:15 S1 + S2 5

2 (Xamarin Android)

00:25:58 271

(Main.axml, MainActivity.cs, IDBManager.cs,

DBManager.cs, Tekst.cs)

6

1 (Xamarin iOS)

00:26:29 S1 + S2 7

2 (Xamarin iOS)

00:39:33 197

(AppDelegate.cs, Main.cs,

RootViewController.cs, TableSource.cs)

8

1 (Xamarin WP)

00:32:20 S1 + S2 9

2 (Xamarin WP)

00:06:20 104 (MainPage.xaml, MainPage.xaml.cs) 10

3 (Android) 01:44:54 276 (MyApplication.java, RestActivity.java, activity_rest.xml, TwitterApi.java, TwitterApiImpl.java, LastTweetLoadedEvent.java, LoadLastTweetEvent.java)

11

3 (Xamarin Android)

02:12:14 192

(Twitter.axml, TwitterActivity.cs,

ITwitterApi.cs, TwitterApi.cs,

LastTweetLoadedEvent.cs,

LoadLastTweetEvent.cs)

12

11 Seq shows the sequence of the overall prototype development.

107

3 (Xamarin iOS)

00:44:43 84

(TwitterViewController.cs)

13

3 (Xamarin WP)

00:21:37 78

(Twitter.xaml, Twitter.xaml.cs)

14

3 (iOS) 02:54:20 179

(TwitterViewController.h+.m,

TwitterApi.h+.m)

15

4 (iOS) 02:03:27 209

(RestViewController.h+.m, RestAPI.h+.m,

Comment.h+.m)

16

5 (iOS) 01:12:42 296 - 209 = 87

(Additions to RestViewController.h+.m,

RestAPI.h+.m)

17

6 (iOS) 01:09:48 73

(GPSViewController.h+.m)

18

4 (Android) 01:48:34 298 (RestActivity.java, activity_rest.xml, Comment.java, RestApi.java, RestApiImpl.java, PostCommentEvent.java, CommentPostedEvent.java)

19

5 (Android) 01:11:43 64 + (412 - 298) = 178 (GetCommentsEvent.java, CommentsReceivedEvent.java, AndroidBus.java and additions to: RestActivity.java, activity_rest.xml, Comment.java, RestApi.java, RestApiImpl.java)

20

6 (Android) 01:30:21 176 (GPSActivity.java, activity_gps.xml)

21

4 (Xamarin Android)

02:57:18 247

(Rest.axml, RestActivity.cs, IRestApi.cs,

RestApi.cs, Comment.cs,

PostCommentEvent.cs,

CommentPostedEvent.cs)

22

5 (Xamarin Android)

00:52:35 361 - 247 = 114

(GetCommentsEvent.cs,

CommentsReceivedEvent.cs, and additions to

Rest.axml, RestActivity.cs, IRestApi.cs,

RestApi.cs, Comment.cs)

23

4 (Xamarin iOS)

01:25:21 79

(RestViewController.cs)

24

108

5 (Xamarin iOS)

03:40:44

36 + (90 - 79) = 47

(CommentsTableSource.cs, and additions to

RestViewController.cs)

25

4 (Xamarin WP)

00:19:08 81

(Rest.xaml, Rest.xaml.cs)

26

5 (Xamarin WP)

00:15:59 94 - 81 = 13

(Additions to Rest.xaml, Rest.xaml.cs)

27

6 (Xamarin Android)

01:42:20 193

(GPS.axml, GPSActivity.cs, ILocationApi.cs,

LocationApi.cs, LocationReceivedEvent.cs)

28

6 (Xamarin iOS)

01:02:25 64

(GPSViewController.cs)

29

6 (Xamarin WP)

00:47:13 80

(GPS.xaml, GPS.xaml.cs)

30

1 (VC++ WP)

02:33:55 S1 + S2 31

2 (VC++ WP)

03:23:01 UI: 128 (MainPage.xaml, MainPage.xaml.h, MainPage.xaml.cpp) Lib: 197 (DBManager.h, DBManager.cpp, TextDao.h, TextDao.cpp, Text.h, Text.cpp)

32

1 (VC++ Android)

09:51:52 UI: 162 (activity_main.xml, MainActivity.java) Java lib: 139 (TextDao.java, TextDaoImpl.java, Text.java) JNI: 179 (Android_TextDao.h+.cpp, handle.h) C++ Lib: 242 (Additions to DBManager.h, DBManager.cpp, TextDao.h, TextDao.cpp, Text.h, Text.cpp)

33

2 (VC++ Android)

- - 34

3 (VC++ WP)

05:28:35 UI: 101 (Twitter.xaml, Twitter.xaml.h, Twitter.xaml.cpp) Lib: 123 (TwitterApi.h, TwitterApi.cpp)

35

4 10:25:29 UI: 109 36

109

(VC++ WP) (Rest.xaml, Rest.xaml.h, Rest.xaml.cpp) Lib: 139 RestApi.h, RestApi.cpp, Comment.h, Comment.cpp)

4 (VC++ Android)

01:27:40 Trying to compile and link the common library for Android with the Poco library was a failure and wasn’t resolved. Therefore no Android specific JNI binding and UI development was executed.

37

3 (VC++ Android)

02:29:14 Trying to compile and link the common library for Android with the Twitcurl integration was a failure and wasn’t resolved. Therefore no Android specific JNI binding and UI development was executed.

38

5 (VC++ WP)

- Not implemented; see chapter 4.5.4 -

6 (VC++ WP)


5 (VC++ Android)


6 (VC++ Android)


Table D-1 Prototype measurements

D.1 Android Details

Story 1 – SQLite

1. Create new Android project in Android Studio

2. Add controls to main activity

3. Implement SQLite function to save a simple object to the local database

Story 2 – SQLite

1. Use main activity from Story 1, and add controls

2. Implement SQLite function to retrieve a list of simple object from the local

database

Story 3 – Twitter

1. Add Fabric: Twitter Kit for Android

2. Initialize Fabric in AppDelegate

3. Add new activity: TwitterActivity

4. Add controls

5. Implement Twitter API integration using TwitterKit

110

6. Implement async integration between UI and Twitter Api using Otto event

bus


1. Add new activity - RestActivity - and set it as launch activity in the run

configuration

2. Add controls

3. Implement REST Api: POST comment to Deployd's REST interface

4. Implement async integration between UI and REST Api using

org.apache.http.client.HttpClient, Otto event bus and java.lang.Thread


1. Implement REST Api: GET comments from Deployd's REST interface

2. Add controls to ViewController used in Story 4

3. Extend the async integration between UI and REST Api

Story 6 – GPS

1. Add new activity - GPSActivity - and set it as launch activity in the run

configuration

2. Add controls

3. Add permission to manifest: ACCESS_FINE_LOCATION

4. Implement Location services, and show longitude and latitude.

D.2 iOS Details

Story 1 – SQLite

1. Create Xcode project - Single view application

2. Add controls to the ViewController (root) on storyboard

3. Implement SQLite function to save a simple object to the local database

Story 2 – SQLite

1. Use ViewController from Story 1, and add controls

2. Implement SQLite function to retrieve a list of simple object from the local

database

Story 3 – Twitter

1. Add Fabric: Twitter Kit

2. Initialize Fabric in AppDelegate

3. Add new View Controller: TwitterViewController. Both in storyboard and as

source files (.h+.m).

4. Add controls

5. Implement Twitter API integration using TwitterKit: The request to retrieve

the Twitters last tweet had to be handcoded, as the TwitterKit didn't have the

request integrated

111

6. Implement async integration between UI and Twitter Api using Grand Central

Dispatch


1. Add new view controller to storyboard, and set it as root view controller

2. Add controls

3. Implement REST Api: POST comment to Deployd's REST interface

4. Implement async integration between UI and REST Api using Grand Central

Dispatch



2. Add controls to ViewController used in Story 4

3. Implement async integration between UI and REST Api using Grand Central

Dispatch

Story 6 – GPS

1. Add new view controller to storyboard, and set it as root view controller

2. Add controls

3. Implement Location Manager, and show longitude and latitude.

D.3 Xamarin Details


Android

1. Find option for SQLite: SQLitePCL

2. Add nuget SQLitePCL to Commonlibrary project

3. Implement entity object class Tekst.cs and data access with database

mananger DBManager.cs in Commonlibrary project

4. Add PCL reference to Android project

5. Add controls to activity

6. Hook up button to insert data object to SQLite using PCL

7. Hook up load event to retrieve data objects from SQLite using PCL

iOS

1. Add PCL reference to iOS project

2. Add controls to view controller



WP

1. Add PCL reference to WP project

112

2. Add controls to xaml



Story 3 – Twitter

Android

1. Find option for Twitter API: Tweetinvi

2. Find option for messaging in Xamarin: mvvmcross messenger

3. Add nuget Tweetinvi and mvvmcross messenger to Commonlibrary project

4. Add nuget Tweetinvi and mvvmcross messenger to AndroidApp project

5. Implement Tweetinvi in Commonlibrary

6. Implement messaging using MvxMessenger (mvvmcross messenger) in

Commonlibrary

7. Add new activity and add controls

8. Implement messaging using MvxMessenger in AndroidApp in the new activity

9. Implement button action: Publish LoadLastTweetEvent

WP

1. Add nuget mvvmcross messenger

2. Add blank page and set as root page in app.xaml.cs

3. Add controls

4. Implement messaging using MvxMessenger


iOS

1. Add nuget mvvmcross messenger

2. Add new view controller, and set it as root

3. Add controls

4. Implement messaging using MvxMessenger



Android

1. Add new activity and add controls. Set new activity as the launcher activity

2. Implement REST Api in CommonLibrary: POST comment to Deployd's REST

interface

3. Implement async integration between UI and REST Api using MvxMessenger

iOS

1. Add new view controller, and set it as root

113

2. Add controls


WP

1. Add blank page. Set new page as root page in app.xaml.cs

2. Add controls



Android


2. Add controls to Activity used in Story 4


iOS

1. Add controls to View Controller used in Story 4


WP

1. Add controls to page used in Story 4


Story 6 – GPS

Android

1. Add new activity and add controls. Set new activity as the launcher activity

2. Implement LocationApi using nuget Xam.Plugin.Geolocator

3. Implement async integration from LocationApi to UI using MvxMessenger

When working with the simulator you have to remember to initialise the geolocation

of the virtual device. With Android that is done through telnet (fig. D-1).

Fig. D-1 Set Android location

iOS

1. Add nuget Xam.Plugin.Geolocator to iOS project

2. Add new View Controller, and set it as root

3. Add controls

4. Connect the UI to the LocationApi using MvxMessenger

telnet localhost 5554 geo fix 55 11

114

WP

1. Add nuget Xam.Plugin.Geolocator to WP project

2. Add new

3. Add controls

4. Connect the UI to the LocationApi using MvxMessenger

D.4 VC++ Details

Story 1 – SQLite

WP

1. Create a new project using the template Visual C++ -> Cross Platform ->

Shared Library (Android, iOS). This includes creating a new solution in Visual

Studio.

2. Add another project for the Windows Phone App using template Visual C++ ->

Windows -> Windows 8 -> Windows Phone -> Blank App (Windows Phone)

3. Install nuget in WP app proj: sqlite

4. Install nuget in CommonLibrary proj: sqlite

5. Add controls to xaml

6. Hook up button to insert data object to SQLite using CommonLibrary

Android

1. Find option for SQLite: SQLitePCL

2. Add nuget SQLitePCL to Commonlibrary project

3. Implement entity object class Tekst.cs and data access with database

mananger DBManager.cs in Commonlibrary project

4. Add PCL reference to Android project

5. Add controls to activity



Story 2 – SQLite

WP

1. Add controls to show the list of texts from SQLite

2. Implement a method for querying in CommonLibrary

3. Integrate UI and CommonLibrary, having the UI query the SQLite db using

CommonLibrary

Story 3 – Twitter

WP 1. Find option for Twitter API: Twitcurl

115

2. Find option for messaging in C++: Native C++ event handling

[EventsNativeC++]

3. Find another option for WP event handling [EventsC++]

4. Implement Twitcurl in Commonlibrary

5. Implement messaging using WP event handling in WP project

6. Add blank page and set as root page in app.xaml.cs

7. Add controls

8. Implement messaging using Native C++ event handling in AndroidApp in the

new activity


Android 1. Build Common Library for Android

2. Add Java class to integrate with native C++ library

3. Generate JNI C++ wrapper using javah

4. Implement JNI wrapper

5. Build Common Library for Android to include JNI wrapper

6. Add new activity – TwitterActivity

7. Add controls

8. Implement event handling using Otto event bus



WP 1. Add blank page, Rest, and set as root page in app.xaml.cs

2. Add controls

3. Implement event handling as in story 3

4. Implement Rest Api in Common Library using the Poco library

5. JSON serialization

6. Http client request

7. Implement button action: Publish PostCommentEvent

Android 1. Build Common Library for Android

2. Add Java class to integrate with native C++ library

3. Generate JNI C++ wrapper using javah

4. Implement JNI wrapper

5. Build Common Library for Android to include JNI wrapper

6. Add new activity, Rest Activity, and add controls. Set new activity as the

launcher activity

7. Implement event handling using Otto event bus

8. Implement button action: Publish PostCommentEvent

116

Appendix E – Source Repositories All source code is stored in public Git repositories at Github (table E-1).

Application URL

Android Native reference https://github.com/bobbyz-dk/android-master-ref

iOS Native reference https://github.com/bobbyz-dk/ios-master-ref

Xamarin Hello World https://github.com/bobbyz-dk/cross-xamarin-hello

VC++ Hello World https://github.com/bobbyz-dk/cross-cpp-hello

Xamarin prototype https://github.com/bobbyz-dk/cross-xamarin-prototype

VC++ prototype https://github.com/bobbyz-dk/cross-cpp-prototype

Table E-1 Repositories

https://github.com/bobbyz-dk/android-master-ref

https://github.com/bobbyz-dk/ios-master-ref

https://github.com/bobbyz-dk/cross-xamarin-hello

https://github.com/bobbyz-dk/cross-cpp-hello

https://github.com/bobbyz-dk/cross-xamarin-prototype

https://github.com/bobbyz-dk/cross-cpp-prototype

Documents

Cross Platform Mobile Development - Computer Science …cs.au.dk/.../site_files/cs/...SoftwareDevelopment.pdf · Cross Platform Mobile Development ... The primary focus is on native