Cross Platform Mobile Development

Transcription

1 Cross Platform Mobile Development Master s Thesis Software Development Author Bobby Nielsen bobby@cs.au.dk Supervisor Henrik Bærbak Christensen Department of Computer Science, University of Aarhus Aabogade 34, 8200 Aarhus N, Denmark

2 Abstract This thesis presents a research and comparison of options for cross platform mobile development. What are the options in the market, and how does the mobile development industry see the options for cross platform development? The high level goal is to be able to build an app that has a single codebase in one language for several mobile platforms. A framework for evaluating cross platform mobile development options against this goal will be presented, and evaluations of some of these options using prototyping e.g. Xamarin. The primary focus is on native app development with Android, ios and Windows Phone, and not on hybrid or mobile web development. 2

3 Contents 1. Motivation Hypothesis/Problem statement Method Approaches for Cross Platform Development Survey and Interviews Cross Platform Languages/options Evaluation of Cross Platform Development options Hello World Prototyping Analyses and Results Approaches to cross platform mobile development Researched languages and products Conclusion on development options The industry view Survey Interviews Conclusion on the mobile development industry The Dilemma Selecting the mobile strategy Which and Why? Hello World Xamarin with Visual Studio Embarcadero C++ Builder Visual C++ for Cross-Platform Mobile Development (VC++) Hello World conclusion Prototypes Android Native reference ios/iphone Native reference Xamarin Visual C++ for Cross-Platform Mobile Development (VC++) Conclusion on prototypes Related works

4 6. Discussion Conclusion Conclusion on the Hypotheses References Appendix A A research in technologies, products and vendors Researched vendors Cross Platform Development Options Appendix B Hardware and OS specifications Appendix C Hello World Tests C.1 Xamarin with Visual Studio C.1.1 Xamarin ios Development C.1.2 Xamarin Android Development C.1.3 Xamarin Windows Phone Development C.2 Embarcadero C++ Builder XE C.2.1 C++ Builder ios Development C.2.2 C++ Builder Android Development C.2.3 C++ Builder Windows Phone Development C.3 Visual C++ for Cross-Platform Mobile Development (VC++) Appendix D Prototype Details D.1 Android Details D.2 ios Details D.3 Xamarin Details D.4 VC++ Details Appendix E Source Repositories

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

6 70,0% 60,0% 50,0% 40,0% 30,0% 20,0% Android Blackberry ios Windows Other 10,0% 0,0% Jan Feb Mar Apr May Jun Jul Aug Sep Okt Nov Dec Fig. 1-2 Great Britain Smartphone OS market share ,0% 80,0% 70,0% 60,0% 50,0% 40,0% 30,0% 20,0% 10,0% 0,0% Jan Feb Mar Apr May Jun Jul Aug Sep Okt Nov Dec Android Blackberry ios Windows Other Fig. 1-3 Germany Smartphone OS market share

7 90,0% 80,0% 70,0% 60,0% 50,0% 40,0% 30,0% 20,0% Android Blackberry ios Windows Other 10,0% 0,0% Jan Feb Mar Apr May Jun Jul Aug Sep Okt Nov Dec 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. 7

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

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? 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. 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. 9

10 Code-free 1 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. 10

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? 11

12 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 codefree 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? 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. 12

13 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? 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. 13

14 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? 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 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 ). This Hello World test will also test the ability to create a User Interface (UI) with a native look and feel. SharedLibrary.hello( Bobby ) returns Hello Bobby Fig. 3-4 Pseudo code for Hello World 14

15 :App :SharedLibrary Fig. 3-5 Sequence Diagram for Hello World 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 15

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): Storage (Local Persistance) 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. API Integration (Twitter) Story 3 Let the user write a twitter name in a textbox. Retrieve the last tweet of the twitter given. REST Service Integration Story 4 Post a comment (comment, , creation date) to a backend service (Deployd) Story 5 Retrieve (get) list of all comments (comment, , creation date) from a backend service (Deployd) Device Hardware Functions Story 6 Using the GPS, show the coordinates of the current location 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. 16

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 While developing the prototypes, the defined metrics (fig. 3.7) will be considered. Metrics for prototype development 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. Fig. 3-7 Metrics 17

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. 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. Fig. 4-1 Cross-compilation strengths and weaknesses 18

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. 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. Mobile Web App Webapp(s) Fig. 4-2 Virtual Machines strengths and weaknesses 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. 19

20 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. 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. 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. Fig. 4-4 Hybrid strengths and weaknesses 20

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. 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. Fig. 4-5 Source translation strengths and weaknesses 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. 21

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 list 2. 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 general 3 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. 22

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 C++ Mobile Development Xamarin C# Table 4-1 Options for cross development (delimited) 23

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]. 24

25 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 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]. 25

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 o o o Mobile App Design, Development & Promotion Android iphone Software Design Patterns and Architecture The Enterprise Architecture Network 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. 26

27 Respondent location France Switzerland Germany Denmark Spain Faroe Islands Great Britain India Jordan Philippines Serbia Sweden US 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. How would you approach the development of an app for Android? Using the Android Development Kit from Google (the maker of Android) and Java B4A Cordova google sdk + c++/objc/asm Investigate cross-platform frameworks. Wait for React Native to work on Android Xamarin Fig. 4-8 Android approach 27

28 How would you approach the development of an app for iphone (ios)? Using Xcode and Objective-C and/or Swift, which is provided by Apple. B4i C++ Cordova IntelliJ Idea Investigate cross-platform frameworks. React Native Fig. 4-9 ios approach How would you approach the development of an app for Windows Phone? Using Visual Studio provided by Microsoft and C# or VB. Cordova IntelliJ idea Investigate cross-platform frameworks. Xamarin Fig 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. 28

29 Which frameworks do you know for cross platform mobile development? Other ClickSoftware Verivo Akula Embarcadero AppMethod DSI Mobile Platform Oracle Mobile Application Framework MicroStrategy Mobile Apps Salesforce Mobile Pega Mobile SAP Mobile Platform Kony Telerik AppBuilder Clang MoSync Visual C++ for Cross-Platform Mobile Development AML Jo Xui WebApp.net J2objc RoboVM Kinvey FeedHenry Tabris IBM MobileFirst Corona RhoMobile (Rhodes) Sencha Touch QT JUniversal JQuery Mobile Adobe Air Appcelerator Titanium Cordova PhoneGap Marmalade Codename One Xamarin Native (Android Development Kit, Xcode, Visual Fig 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 29

30 means that to create an app for more than one platform, a tool for each platform is preferred. Which product(s) do you prefer for mobile development? Other ClickSoftware Verivo Akula Embarcadero AppMethod DSI Mobile Platform Oracle Mobile Application Framework MicroStrategy Mobile Apps Salesforce Mobile Pega Mobile SAP Mobile Platform Kony Telerik AppBuilder Clang MoSync Visual C++ for Cross-Platform Mobile Development AML Jo Xui WebApp.net J2objc RoboVM Kinvey FeedHenry Tabris IBM MobileFirst Corona RhoMobile (Rhodes) Sencha Touch QT JUniversal JQuery Mobile Adobe Air Appcelerator Titanium Cordova PhoneGap Marmalade Codename One Xamarin Native (Android Development Kit, Xcode, Visual Fig 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. 30

31 Which strategy do you prefer for mobile development? Do you know of any code-free solutions for mobile development? Native Hybrid Webapps Other No Yes Fig Mobile strategy preferred Fig 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. 31

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. bluefragments redweb Novasa Interactive Nodes ideal Development Dwarf Lector AppTown Centic No answer No answer No answer No answer The purpose was to get an understanding of how developers work with app creation and to understand the challenges of mobile 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. 32

33 1.a. What do you think about developing an app for all of ios, Android and WP - Three languages? 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 codewise 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.b. Do you focus on other platforms? 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. 33

34 2. Do you know if it is possible to use one language for all the three platfroms? A. Hedegren: We require such large demands for code quality, UX, response time and futureproofing 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.a. Would you like to use a single language? 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. 3. Are developers generally aware of cross platform development possibilities? A. Hedegren: It is our impression that many developers are. T. Steen: It is my understanding that many developers use Cross Platform udvilking. 3.a. That are not webapps? 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. 34

35 4. Which strategy do you prefer for the development of apps and why (Native, hybrid or webapps)? 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. 5. Which products do you prefer for mobile development? 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. 35

36 6. Do you know any code-free solutions for mobile development? 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. 7. What is the greatest challenge within 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. 8. Do you see any issues with cross platform 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. 9. Other comments regarding mobile development? A. Hedegren: It is difficult, expensive, and it shows if you cut costs. 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 36

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 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-free 4. 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. 37

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

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

40 C++ is used for apps like Dropbox [Dropbox1][Dropbox2][Dropbox3] and MS Office apps [MSOffice1][MSOffice2][MSOffice3]. 4.4 Hello World 5 Using the candidates identified as interesting for cross development, simple hello world prototypes will be created to confirm that a common library can be created that can be used to hold common logic/functionality that can be reused on the selected platforms without modifications Xamarin with Visual Studio 6 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 40

41 C# :ViewController :Shared btnhello_touchupinside hello(string text):string Fig 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. C# :MainActivity :Shared btnhello.click hello(string text):string Fig 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. 41

42 C# :MainPage :Shared btnhello_click hello(string text):string Fig Xamarin Windows Phone Fig Xamarin Hello World ios Fig Xamarin Hello World Android Fig 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 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. 42

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 Layout designer Fig UI on Android 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. 43

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). 44

45 C++ :MainPage :CommonLibrary.WP :CommonLibrary btnhello_click helloworld(string^ world):string^ helloworld(std::string text):std::string Fig 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++. Java JNI C++ :MainActivity :CommonLibrary :CommonLibrary.A ndroidw :CommonLibrary hello(view view) hello(string world):string Java_dk_bobbyz_helloworldvcppandroidapp_CommonLibrary_hello(jstring world):jstring helloworld(std::string text):std::string Fig VC++ Android 45

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 26 th 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). Objective-C Objective-C++ C++ :ViewController :CommonLibraryFacade :CommonLibrary hello(id sender):ibaction hello(nsstring* world):nsstring* helloworld(std::string text):std::string Fig 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. 46

47 Fig VC++ Hello World WP Fig VC++ Hello World Android Fig VC++ Hello World ios 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. 47

48 GO! 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. NO GO! Fig Hello World: GO/NO GO 4.5 Prototypes 7 To compare and evaluate the development of apps using native solutions provided by OS vendors and other third party solutions, the case consisting of six stories will be implemented and measured according to defined metrics (see chapter 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 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 48

49 Story 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 :SQLiteDatabase newtext(view view) addtext(text text) filllist() getalltexts():list<text> insert(string table, String nullcolumnhack, ContentValues values) close() query(string table, String[] columns, null):cursor Fig Android Story Android project: 01: LOC 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. 49

50 :TwitterActivity :Bus :TwitterApi lasttweet(view view) post(loadlasttweetevent event) onstoriesloaded(lasttweetloadedevent event) onloadlasttweet(loadlasttweetevent event) post(lasttweetloadedevent event) Fig Android Story 3 Android project: 01: LOC 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 :RestApi postcomment(view view) post(postcommentevent event) oncommentposted(commentpostedevent event) onpostcomment(postcommentevent event) post(commentpostedevent event) Fig Android Story 4 Android project: 01: LOC 50

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 :RestApi getcomments(view view) post(getcommentsevent event) ongetcomments(getcommentsevent event) post(commentsreceivedevent event) oncommentreceivted(commentsreceivedevent event) Fig Android Story 5 Android project: 01: LOC 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: LOC 51

52 Measurements Android Native reference Story Time LOC Main outcome Seq :44:24 S1 + S2 Easy SQLite integration :37: (MainActivity.java, activity_main.xml, Tekst.java, TekstDao.java) 3 01:44: (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 :48: (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 :11: ( ) = 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 :30: (GPSActivity.java, activity_gps.xml) Table 4-3 Android measurements 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) Seq shows the sequence of the overall prototype development. 52

53 Fig Story 3 Fig Story Fig Story 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 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. 53

54 :ViewController :DBManager btngemtekst(uibutton sender):ibaction executequery(nsstring* query) loaddata() loaddatafromdb(nsstring* query):nsarray* runquery(char* query, boolean isqueryexecutable) Fig ios Story ios project: 02: LOC 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 :TwitterApi btnretrievetweet:(id sender):ibaction postnotificationname(nsstring name, NSObject object) onloadlasttweet(nsnotification* notif) onlasttweetloaded(nsnotification* notif) postnotificationname(nsstring name, NSObject object) Fig ios Story 3 ios project: 02: LOC 54

55 Fig Story 3 Fig Story 4 Fig Story 5 55

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. Fig Story 6 :RestViewController :NSNotificationCenter :RestApi BtnPost(id sender):ibaction postnotificationname(nsstring name, NSObject object) onpostcomment(nsnotification* notif) oncommentposted(nsnotification* notif) postnotificationname(nsstring name, NSObject object) Fig ios Story 4 56

57 :RestViewController :NSNotificationCenter :RestApi BtnGet(id sender):ibaction postnotificationname(nsstring name, NSObject object) ongetcomment(nsnotification* notif) oncommentreceived(nsnotification* notif) postnotificationname(nsstring name, NSObject object) Fig ios Story 5 ios project: Story 4: 02: LOC ios project: Story 5: 01:12 87 LOC 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: 01:10 73 LOC 57

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 2 00:49: developer community has (DbManager.h+.m, documented many examples AppDelegate.h+.m, that can help the ViewController.h+.m) implementation :54: (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 :03: (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 :12: = 87 (Additions to RestViewController.h+.m, RestAPI.h+.m) No issues :09:48 73 (GPSViewController.h+.m) Table 4-4 ios measurements Only issue was to test the app using the simulator. A real device was the easy solution 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 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 nuget 9 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. 58

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) newtext(string text) runquery(string query, bool isqueryexecutable) FillList() LoadDataFromDB(string query):list<object> runquery(string query, bool isqueryexecutable) Fig Xamarin Windows Phone Story Android project + library: 04: LOC ios project: 01: LOC Windows Phone project: 00: LOC 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 59

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 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 :ITwitterApi btnretrievetweet_click(object sender, RoutedEventArgs e) Publish<LoadLastTweetEvent>(LoadLastTweetEvent event) OnLoadLastTweet(LoadLastTweetEvent event) OnLastTweetLoaded(LastTweetLoadedEvent event) Publish<LastTweetLoadedEvent>(LastTweetLoadedEvent event) Fig Xamarin Windows Phone Story 3 Android project + library: 02: LOC ios project: 00:45 84 LOC Windows Phone project: 00:22 78 LOC 60

61 Fig Story 3 Android Fig Story 3 ios Fig 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. 61

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 :IRestApi btnpost_click(object sender, RoutedEventArgs e) Publish<PostCommentEvent>(PostCommentEvent event) OnPostComment(PostCommentEvent event) OnCommentPosted(CommentPostedEvent event) Publish<CommentPostedEvent>(CommentPostedEvent event) Fig Xamarin Windows Phone Story 4 Android project + library: 02: LOC ios project: 01:25 79 LOC Windows Phone project: 00:19 81 LOC 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 62

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 :IRestApi btnget_click(object sender, RoutedEventArgs e) Publish<GetCommentsEvent>(GetCommentsEvent event) OnGetComments(GetCommentsEvent event) OnCommentsReceived(CommentsReceivedEvent event) Publish<CommentsReceivedEvent>(CommentsReceivedEvent) Fig Xamarin Windows Phone Story 5 Android project + library: 00: LOC ios project: 03:41 47 LOC Windows Phone project: 00:16 13 LOC 63

64 Fig Story Android Fig Story ios Fig Story 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. 64

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. Android project + library: 01: LOC ios project: 01:02 64 LOC Windows Phone project: 00:47 80 LOC Fig Story 6 Android Fig Story 6 ios Fig Story 6 WP 65

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 2 00:25: help of the added nuget (Main.axml, SQLitePCL. MainActivity.cs, IDBManager.cs, DBManager.cs, Tekst.cs) 3 02:12: (Twitter.axml, TwitterActivity.cs, ITwitterApi.cs, TwitterApi.cs, LastTweetLoadedEven t.cs, LoadLastTweetEvent.c s) 4 02:57: (Rest.axml, RestActivity.cs, IRestApi.cs, RestApi.cs, Comment.cs, PostCommentEvent.c s, CommentPostedEvent.cs) 5 00:52: = 114 (GetCommentsEvent. cs, CommentsReceivedEv ent.cs, and additions to Rest.axml, RestActivity.cs, IRestApi.cs, RestApi.cs, Comment.cs) 6 01:42: (GPS.axml, GPSActivity.cs, ILocationApi.cs, LocationApi.cs, LocationReceivedEven t.cs) Both Tweetinvi and MvxMessenger were fairly easy to get started with, and had good documentation to help the implementation. 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. Minor trouble deserializing the array of Comment objects. 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. 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, 2 00:39: which needs connection to (AppDelegate.cs, Mac Build Host. Deployment Main.cs, to device is also slow, and RootViewController.c sometimes halts for no s, TableSource.cs) obvious reason. 3 00:44:43 84 (TwitterViewControlle r.cs) 4 01:25:21 79 (RestViewController.c s) 5 03:40: (90-79) = 47 (CommentsTableSour ce.cs, and additions to RestViewController.cs ) 6 01:02:25 64 (GPSViewController.c s) Again problems with the ios Designer. Testing on simulator was a failure, both success on physical device. The ios Designer was quicly available and usable. Missing references regarding MvvmCross was easily solved by updating the nuget. Not functioning on physical device, but works on simulator. Again issues with ios Designer. The Xamarin Geolocator plugin works great. 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 2 00:06:20 version of Sqlite dll was 104 required. (MainPage.xaml, MainPage.xaml.cs) :21:37 78 (Twitter.xaml, Twitter.xaml.cs) The xaml designer did not work this time, and the UI was handcoded :19:08 81 (Rest.xaml, Rest.xaml.cs) 5 00:15: = 13 (Additions to Rest.xaml, Rest.xaml.cs) No issues 26 No issues :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. Table 4-7 Xamarin Windows Phone measurements 30 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. 68

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 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 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 69

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 :TextDao :DBManager btninsert_click(platform::object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e) insert(text text) query(char* query):vector<vector<string> > FillList() findall():vector<text*> Fig VC++ Windows Phone Story Java JNI C++ :MainPage :TextDao Android_TextDao :TextDao :DBManager inserttext (View view) insert(text text) Java_dk_bobbyz_crosscppandroidapp_commonlibrary_impl_TextDaoImpl_insert(jObject atext) insert(text text) query(char* query):vector<vector<string> > FillList() findall():list<text> Java_dk_bobbyz_crosscppandroidapp_commonlibrary_impl_TextDaoImpl_findAll() query(char* query):vector<vector<string> > Fig VC++ Android Story Windows Phone project + library: 05: LOC Android project: 09: LOC Failed 70

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. Windows Phone project + library: 05:29 Failed Android project: 02:29 Failed 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. 71

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 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. Windows Phone project + library: 10:25 Failed Android project: 01:28 Failed 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? 72

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 2 03:23:01 UI: 128 integration in C++ and put it (MainPage.xaml, in a library. MainPage.xaml.h, Using JNI requires some MainPage.xaml.cpp) research, and takes some Lib: 197 time to get into and get right. (DBManager.h, DBManager.cpp, TextDao.h, TextDao.cpp, Text.h, Text.cpp) :28:35 UI: 101 (Twitter.xaml, Twitter.xaml.h, Twitter.xaml.cpp) Lib: 123 (TwitterApi.h, TwitterApi.cpp) 4 10:25:29 UI: 109 (Rest.xaml, Rest.xaml.h, Rest.xaml.cpp) Lib: 139 RestApi.h, RestApi.cpp, Comment.h, Comment.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. 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 As Story 5 is supposed to build on Story 4, which was a failure, then Story 5 is a failure 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 33 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 As the insert into the database failed, the data retrieval hasn t been resolved :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 :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

75 5 - - As Story 5 is supposed to build on Story 4, which was a failure, then Story 5 is a failure 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 The library developers haven t had much time to build new versions that support e.g. the Windows Phone specifics delivered with Visual Studio

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 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 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 76

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: (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 77

78 1 (Xamarin WP) 00:32:20 S1 + S2 2 (Android) 00:37: (ios) 00:49: (VC++ Android) - Not implemented; see chapter (VC++ WP) 03:23: (Xamarin Android) 00:25: (Xamarin ios) 00:39: (Xamarin WP) 00:06: (Android) 01:44: (ios) 02:54: (VC++ Android) 02:29:14 Failed 3 (VC++ WP) 05:28: (Failed) 3 (Xamarin Android) 02:12: (Xamarin ios) 00:44: (Xamarin WP) 00:21: (Android) 01:48: (ios) 02:03: (VC++ Android) 01:27:40 Failed 4 (VC++ WP) 10:25: (Failed) 4 (Xamarin Android) 02:57: (Xamarin ios) 01:25: (Xamarin WP) 00:19: (Android) 01:11: (ios) 01:12: (VC++ Android) - Not implemented; see chapter (VC++ WP) - Not implemented; see chapter (Xamarin Android) 00:52: (Xamarin ios) 03:40: (Xamarin WP) 00:15:

79 6 (Android) 01:30: (ios) 01:09: (VC++ Android) - Not implemented; see chapter (VC++ WP) - Not implemented; see chapter (Xamarin Android) 01:42: (Xamarin ios) 01:02: (Xamarin WP) 00:47:13 80 Table 4-10 Story comparison 79

80 5. Related works Back in 2011 the Department of the Navy Grant N , 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. 80

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) 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. 81

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 82

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

84 Conclusion on the Hypotheses The hypotheses presented in chapter 2 are all evaluated to be valid. 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. 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. 84

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

86 References (Ordered alphabetically) [Android Studio] [AndroidSQLite1] [AndroidSQLite2] [AndroidTwitter] [ApacheHttpClient] [Appcelerator2014Q3] q3-mobile-report/ [AppceleratorGartner2014] [Appcelerator-IDC2014] [Asthana2014] [C++] [C++Builder] [Crawford2013] [curl] [Deployd] [Dignan2015] [Djinni] [Dropbox1] [Dropbox2] Cross-Platform-Mobile-Apps-Written-in-CPP [Dropbox3] Mobile-CPP-Development-at-Dropbox [EmbarcaderoMacPA] ment_environment_on_the_mac_%28ios%29 86

87 [EmbarcaderoWinSetupAndroid] ment_environment_on_windows_pc_%28android%29 [EmbarcaderoWinSetupiOS] ment_environment_on_windows_pc_%28ios%29 [EventsC++] [EventsNativeC++] [fabric.io] [Gartner2014] [GoogleInbox] [GoogleLocationServices] [GWT] [Hartman2011] Gustavo Hartmann, Geoff Stead, Asi DeGani. Cross-platform mobile development. Tribal, 2011 [HTML5] [IDC] [InfoQ2013] [ios build issue] [iosgcd] [iossqlite] [J2ObjC] [JavaThreading] [JNI] [Kantar] [Magenic1] [Magenic2] Part-2-Native-Cordova-Classic-Xamarin-Xamarin-Forms [MSOffice1] 87

88 [MSOffice2] Deliver-Office-Across-Different-Platforms-Part-I [MSOffice3] Deliver-Office-Across-Different-Platforms-Part-II [mx3] [NewtonSoft] [Otto] [Plaisted2013] David A. Plaisted, "Source-to-Source Translation and Software Engineering," Journal of Software Engineering and Applications, Vol. 6 No. 4A, 2013, pp doi: /jsea A005. [QT] [RexStJohn2015] [Titanium1] [Twitcurl] [VC++ ios] [VisionMobile2014Q3] [VisionMobile2015Q1] state-developer-nation/ [VS2015] [Wikipedia-1] [Wikipedia-VM] [Xam.Plugin.Geolocator] [XamariniOSBuild] [Xcode] 88

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 * 89

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 90

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 91

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 Framework VM Proprietary products/air.html HTML5, CSS3, Alpha Framework Hybrid Commercial JS Software om/ HTML5, JS, AnyPresenc Platform Native, hybrid, Commercial Native languages e m/platform/ webapps JS Appcelerato Platform VM [Titanium1] Open source r Titanium m/titanium/ HTML5, JS, appery.io Platform Hybrid, webapps Commercial Native languages HTML5, CSS3, AppFurnace Platform Hybrid Commercial JS HTML5, CSS3, AppGyver Framework Hybrid Proprietary JS Supersonic upersonic HTML5, CSS3, Application Platform Webapps Commercial JS Craft com/ Code-free AppsFreedo Platform Webapps Commercial m m/ HTML5 Appticles Platform Hybrid, webapps Commercial HTML5, CSS3, Backbase Platform Hybrid, webapps Commercial JS HTML5, CSS3, bmobilized Framework Webapps Commercial JS HTML5, CSS3, Bootstrap Framework Webapps Open source JS C++ C++ Builder Platform Native Commercial 92

93 XE7 m/products/cbuilder C++ Clang Compiler Cross-compilation Open sources Code-free ClickSoftwar Platform Hybrid Commercial e m/mobile-applicationdevelopment-platform Java Codename Platform VM Commercial One om/ HTML5, CSS3, JS Convertigo / Platform Hybrid Open source GPL License or Enterprise License HTML5, JS Cordova Framework Hybrid Open source Lua Corona Scripting Platform Commercial language HTML5, CSS3, Dojo Framework Webapps Open source JS Code-free DSI Mobile Platform Hybrid, webapps Commercial Platform roducts/mobile-platform/ HTML5, CSS3, JS dudamobile m/ Platform Webapps Commercial C++, Object Pascal Embarcader o AppMethod m/ Platform Native Commercial HTML5, CSS3, Enyo JS Framework Webapps Open source JS HTML5, JS, FeedHenry Platform, Native, hybrid, Commercial Native languages Framework webapps Code-free Gamesalad Platform Cross-compilation Proprietary HTML5, CSS3, Globo Platform Hybrid Commercial JS HTML5, CSS3, gomobi Platform Webapps Commercial JS HTML5, CSS3, Gumby Framework Webapps Open source JS Framework m/ HTML5, CSS3, JS HP Anywhere software-solutions/mobileapplicationdevelopment.html Platform Webapps Commercial HTML5, JS, Native languages Code-free IBM MobileFirst efirst/us/en/ Platform, Framework Native, hybrid, webapps Commercial Icinetic Platform Native using VM, Commercial AppWorks ducts/appworks/ hybrid, webapps HTML5, CSS3, i-exceed Platform Hybrid, webapps Commercial JS Appcillon Java j2objc Translator Source translation Open source HTML5, JS Jo Framework Webapps Open source HTML5, JS JQuery Mobile Framework Webapps Open source 93

94 Code-free July Systems ile-developmentproducts/july-mx/ Platform Native using VM, hybrid, webapps Commercial Java JUniversal Translator Source translation Open source HTML5, JS, Kinvey Platform Native, hybrid, Commercial Native languages webapps Python Kivy Framework Cross-compilation Open source HTML5, JS, Native languages Code-free Kony Platform Native, hybrid, webapps Magic Software om/magic-xpa-applicationplatform Platform Native using VM, webapps Commercial Commercial C++ Marmalade Framework Cross-compilation Commercial malade.com/ Code-free Mendix Platform Webapps Commercial Code-free MicroStrate Platform Hybrid Commercial gy Mobile Apps com/us/mobile Mobl Mobl Platform Webapps Open source Code-free mofuse Platform Webapps Commercial Code-free MooFWD Platform Webapps Commercial Zubron evelopers/ C/C++, JS, MoSync Framework Cross-compilation Open source HTML5 XML,.Net, Movilizer Platform Native using VM, Commercial Java, ABAP hybrid, webapps Java Next Framework Webapps Open source JS, Basic NSBasic Platform Hybrid, webapps Commercial Java, HTML5, JS Code-free Oracle Mobile Application Framework Paradise App Designer network/developertools/maf/overview/index.ht ml t/ Framework Hybrid Commercial Platform Webapps Commercial Code-free Pega Mobile Platform Hybrid, webapps Commercial ucts/pega-7#mobile HTML5, JS PhoneGap Framework Hybrid Open source C#, Java Pro Gamma Platform Hybrid Commercial Instant Developer r.com/ Code-free Progress Platform Hybrid, webapps Commercial Pacific products/pacific C++, QML/JS QT Framework Cross-compilation Open source JS React Native Framework Native with JS Open source eact-native/ engine Visual Basic Retriever Platform Native using VM Commercial 94

95 RADE ons.com/%e2%80%a2radefor-applicationdevelopment/ Ruby RhoMobile Platform Cross-compilation Commercial using VM Java RoboVM Platform Compilation + VM Commercial HTML5, CSS3, JS Rocket LegaSuite Mobile com/products/rocketlegasuite-mobile Ruby RubyMotion m/ LiveCode Runrev script, LiveCode s/livecode-platform HTML5, CSS3, JS HTML5, JS, Native languages HTML5 SAP Mobile Platform aigns/digitalhub-mobileplatform/index.html ducts/touch/ Platform Hybrid, webapps Commercial Language Cross-compilation Commercial Platform Platform Cross-compilation native, hybrid Native, hybrid, webapps Open source GPL3 License or Commercial Commercial Sencha Touch Framework Webapps Open source HTML5, CSS3, Skeleton Framework Webapps Open source JS Java Tabris Framework VM Open source bris/ HTML5, JS Telerik Platform Hybrid Commercial AppBuilder builder HTML5, JS Telerik Platform Webapps Commercial KendoUI do-ui UnityScript, Unity 3D Platform Cross-compilation Proprietary C#, Boo obile Java, HTML5, Verivo Akula Platform Native, hybrid, Commercial JS, Native webapps languages C++ Visual C++ for Cross- Platform Mobile Developmen t m/en-us/explore/cplusplusmdd-vs.aspx Platform Cross-compilation Commercial HTML5, JS WebApp.net Framework Webapps Open source C# Xamarin Platform Compilation + VM Commercial JS Xui Framework Webapps Open source HTML5, CSS3, Zurb Framework Webapps Open source JS apps/ Table A-2 - Development options 95

96 Definitions for table A-2 Development options Type Framework Platform Language Translator Compiler Description A set of libraries, software components and architecture guidelines that provides a comprehensive toolkit to build a complete mobile application. 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. Programming language Translates from on language to another Builds executable from source code Table A-3 Type definitions Approach Crosscompilation, Compilation Native Hybrid Webapps VM Source translation Description Compiling of source code into executables for selected platforms 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. A web application hosted in native container. Installed on the phone via an application store A web application utilized via web browser Virtual Machine, provides an execution environment for an application where only the VM needs to adapt to the different platforms Translating og source code from on language to another Table A-4 Aproach definitions License Proprietary Commercial Open source Description The vendor is not charging for the use of the product The vendor is charging for the use of the product The product is free to use, and the source is open Table A-5 License definitions 96

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). Windows Desktop PC Mac Mini Processor: Intel Core i5-4690k 3.50 GHz x64 Processor: Intel Core i GHz Memory (RAM): 16.0 GB Memory (RAM): 2.0 GB OS: Windows 8.1 Pro x64 OS: OSX Yosemite version Mbit LAN connection 100 Mbit LAN connection Table B-1 Specifications 97

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 machines 10. 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 98

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 public class Shared { public string hello(string world) { return "Hello " + world; } } 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. 99

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

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 101

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 102

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 public class Shared { public string hello(string world) { return "Hello " + world; } } 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 104

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 105