Cross Platform Mobile Development - Computer Science...
Transcript of Cross Platform Mobile Development - Computer Science...
Cross Platform Mobile Development
Master’s Thesis
Software Development
Author
20097733 Bobby Nielsen
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%
Jan Feb Mar Apr May Jun Jul Aug Sep Okt Nov Dec
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%
Jan Feb Mar Apr May Jun Jul Aug Sep Okt Nov Dec
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
Investigate cross-platform frameworks.
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
Investigate cross-platform frameworks.
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
Visual C++ for Cross-Platform Mobile Development
MoSync
Clang
Telerik AppBuilder
Kony
SAP Mobile Platform
Pega Mobile
Salesforce Mobile
MicroStrategy Mobile Apps
Oracle Mobile Application Framework
DSI Mobile Platform
Embarcadero AppMethod
Verivo Akula
ClickSoftware
Other
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
Visual C++ for Cross-Platform Mobile Development
MoSync
Clang
Telerik AppBuilder
Kony
SAP Mobile Platform
Pega Mobile
Salesforce Mobile
MicroStrategy Mobile Apps
Oracle Mobile Application Framework
DSI Mobile Platform
Embarcadero AppMethod
Verivo Akula
ClickSoftware
Other
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
hello(string text):string
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
hello(string text):string
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
helloWorld(std::string text):std::string
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*
helloWorld(std::string text):std::string
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)
Fig. 4-32 Android Story 4
Android project: 01:45 276 LOC
Android project: 01:48 298 LOC
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)
Fig. 4-33 Android Story 5
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.
Android project: 01:12 178 LOC
Android project: 01:30 176 LOC
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.
Story 1 + 2 – SQLite
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
iOS project: 02:54 179 LOC
55
Fig. 4-39 Story 3
Fig. 4-40 Story 4
Fig. 4-41 Story 5
56
Story 4 – REST POST
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.
Story 5 – REST GET
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
postNotificationName(NSString name, NSObject object)
:RestApi
onPostComment(NSNotification* notif)
postNotificationName(NSString name, NSObject object)onCommentPosted(NSNotification* notif)
Fig. 4-43 iOS Story 4
Fig. 4-42 Story 6
57
:RestViewController :NSNotificationCenter
BtnGet(id sender):IBAction
postNotificationName(NSString name, NSObject object)
:RestApi
onGetComment(NSNotification* notif)
postNotificationName(NSString name, NSObject object)onCommentReceived(NSNotification* notif)
Fig. 4-44 iOS Story 5
Story 6 – Location
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
iOS project: 01:10 73 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.
Story 1 + 2 – SQLite
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
iOS project: 01:06 197 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
Android project + library: 02:12 192 LOC
iOS project: 00:45 84 LOC
Windows Phone project: 00:22 78 LOC
61
Fig. 4-47 Story 3 Android
Fig. 4-48 Story 3 iOS
Fig. 4-49 Story 3 WP
Story 4 – REST POST
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)
Fig. 4-50 Xamarin Windows Phone Story 4
Story 5 – REST GET
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
Android project + library: 02:57 247 LOC
iOS project: 01:25 79 LOC
Windows Phone project: 00:19 81 LOC
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)
Fig. 4-51 Xamarin Windows Phone Story 5
Android project + library: 00:53 114 LOC
iOS project: 03:41 47 LOC
Windows Phone project: 00:16 13 LOC
64
Fig. 4-52 Story 4 + 5 Android
Fig. 4-53 Story 4 + 5 - iOS
Fig. 4-54 Story 4 + 5 WP
Story 6 – Location
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
Android project + library: 01:42 193 LOC
iOS project: 01:02 64 LOC
Windows Phone project: 00:47 80 LOC
66
Measurements – Xamarin Android
Story Time LOC Main outcome Seq
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
Story Time LOC Main outcome Seq
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
Story Time LOC Main outcome Seq
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.
Story 1 + 2 – SQLite
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
query(char* query):vector<vector<string> >
query(char* query):vector<vector<string> >
: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.
Story 4 – REST POST
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 – REST GET
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.
Story 6 – Location
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
Story Time LOC Main outcome Seq
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
Story Time LOC Main outcome Seq
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.
Story 4 – REST POST
Again Xamarin is ahead when we want our app to target all three platforms: less time
and less code - less code to maintain.
Story 5 – REST GET
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.
Story 6 – Location
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 Android) 02:12:14 192
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 Android) 02:57:18 247
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++ Android) - Not implemented; see chapter 4.5.4
5 (VC++ WP) - Not implemented; see chapter 4.5.4
5 (Xamarin Android) 00:52:35 114
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++ Android) - Not implemented; see chapter 4.5.4
6 (VC++ WP) - Not implemented; see chapter 4.5.4
6 (Xamarin Android) 01:42:20 193
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
HTML5, JS, Native languages
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/
Platform Webapps Commercial
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/
Platform Webapps Commercial
C++, Object Pascal
Embarcadero AppMethod
http://www.appmethod.com/
Platform Native Commercial
HTML5, CSS3, JS
Enyo JS http://enyojs.com/ Framework Webapps Open source
HTML5, JS, Native languages
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
Platform Webapps Commercial
HTML5, JS, Native languages
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
HTML5, JS, Native languages
Kinvey http://www.kinvey.com/ Platform Native, hybrid, webapps
Commercial
Python Kivy http://kivy.org/ Framework Cross-compilation Open source
HTML5, JS, Native languages
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
Platform Hybrid Commercial
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/
Platform Webapps Commercial
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
Oracle Mobile Application Framework
http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html
Framework Hybrid Commercial
Code-free Paradise App Designer
http://www.paradiseapps.net/
Platform Webapps Commercial
Code-free Pega Mobile http://www.pega.com/products/pega-7#mobile
Platform Hybrid, webapps Commercial
HTML5, JS PhoneGap http://phonegap.com/ Framework Hybrid Open source
C#, Java Pro Gamma Instant Developer
http://www.instantdeveloper.com/
Platform Hybrid Commercial
Code-free Progress Pacific
https://www.progress.com/products/pacific
Platform Hybrid, webapps Commercial
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
Platform Hybrid, webapps Commercial
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
HTML5, JS, Native languages
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/
Framework Webapps Open source
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
Platform Hybrid Commercial
HTML5, JS Telerik KendoUI
http://www.telerik.com/kendo-ui
Platform Webapps Commercial
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/
Framework Webapps Open source
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.
5. I test the app (fig. C-4), entering my name and push the button. It works!
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.
5. I test the app (fig. C-5), entering my name and push the button. It works!
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)
- Not implemented; see chapter 4.5.4 -
5 (VC++ Android)
- Not implemented; see chapter 4.5.4 -
6 (VC++ Android)
- Not implemented; see chapter 4.5.4 -
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
Story 4 – REST POST
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
Story 5 – REST GET
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
Story 4 – REST POST
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
Story 5 – REST GET
1. Implement REST Api: GET comments from Deployd's REST interface
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
Story 1 + 2 – SQLite
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
3. Hook up button to insert data object to SQLite using PCL
4. Hook up load event to retrieve data objects from SQLite using PCL
WP
1. Add PCL reference to WP project
112
2. Add controls to xaml
3. Hook up button to insert data object to SQLite using PCL
4. Hook up load event to retrieve data objects from SQLite using PCL
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
5. Implement button action: Publish LoadLastTweetEvent
iOS
1. Add nuget mvvmcross messenger
2. Add new view controller, and set it as root
3. Add controls
4. Implement messaging using MvxMessenger
5. Implement button action: Publish LoadLastTweetEvent
Story 4 – REST POST
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
3. Implement async integration between UI and REST Api using MvxMessenger
WP
1. Add blank page. Set new page as root page in app.xaml.cs
2. Add controls
3. Implement async integration between UI and REST Api using MvxMessenger
Story 5 – REST GET
Android
1. Implement REST Api: GET comments from Deployd's REST interface
2. Add controls to Activity used in Story 4
3. Extend the async integration between UI and REST Api
iOS
1. Add controls to View Controller used in Story 4
2. Extend the async integration between UI and REST Api
WP
1. Add controls to page used in Story 4
2. Extend the async integration between UI and REST Api
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
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
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
9. Implement button action: Publish LoadLastTweetEvent
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
9. Implement button action: Publish LoadLastTweetEvent
Story 4 – REST POST
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