XAMARIN AND PHONE GAP - · PDF file/////XAMARIN AND PHONE GAP: A COMPARISON 4 // MAGENIC...

////

E•BOOK

IntroductionToday’s mobile landscape is fragmented like never before. In the consumer space, the sheer number of mobile devices and their operating system variants—not to mention constant innovation and new product introductions—is a huge challenge for the enterprise on all platforms. The rise of Bring Your Own Device (BYOD) and consumer-grade experience expectations within enterprises also pose difficult questions.

Brad DeanKevin FordKen Ross

XAMARIN AND PHONE GAPA Comparison of Two Approaches to Cross-Platform Mobile Development

http://magenic.com

/ / / / / XAMARIN AND PHONE GAP: A COMPARISON

i // MAGENIC

TABLE OF CONTENTSOverview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 About Xamarin . . . . . . . . . . . . . . . . . . . . . . 5 About PhoneGap . . . . . . . . . . . . . . . . . . . . . 5

Methodology . . . . . . . . . . . . . . . . . . . . . . . 6 A note about performance testing . . . . . 6

Developer Experience . . . . . . . . . . . . . . 7 Languages Used . . . . . . . . . . . . . . . . . . . . . .7 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Code Reuse . . . . . . . . . . . . . . . . . . . . . . . . 8 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Code Reuse Caveats . . . . . . . . . . . . . . . . . . 9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Developer Tooling . . . . . . . . . . . . . . . . . 10 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11

UI Development . . . . . . . . . . . . . . . . . . . 11 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Long Term Maintenance . . . . . . . . . . . . 12 Ecosystem Stability . . . . . . . . . . . . . . . . . . . 13 Code Maintenance . . . . . . . . . . . . . . . . . . . 13 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . 13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .14

Code Organization . . . . . . . . . . . . . . . . . 14 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .15

Compile Time . . . . . . . . . . . . . . . . . . . . . 15 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .16

Access to Native Functionality & APIs 16 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . .16 PhoneGap Windows App Support . . . . . . 17 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Developer Ecosystem . . . . . . . . . . . . . . . . . 17 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .18

Performance Metrics . . . . . . . . . . . . . . 18 App Size . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Start Time . . . . . . . . . . . . . . . . . . . . . . . . . .19 Display Long List . . . . . . . . . . . . . . . . . . . . .19 Memory Usage . . . . . . . . . . . . . . . . . . . . . . .19 Performance Summary . . . . . . . . . . . . . . 20 CPU Intensive Tasks . . . . . . . . . . . . . . . . . 20 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21

User Experience Comparison . . . . . . . 21 Differences in Technology . . . . . . . . . . . . . 21 Side-By-Side Comparison . . . . . . . . . . . . . 21

ANDROID. . . . . . . . . . . . . . . . . . . . . . . . . . .22 Login Screen Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 22 Dashboard Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 23 Wait Indicator Xamarin/PhoneGap . . . . . . . . . . . . . . . . . .24 Add Incident Picker Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 25 Worker Queue Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 26 Incident Detail Xamarin/PhoneGap . . . . . . . . . . . . . . . . . .27 Context Menu Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 28

iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Login Screen Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 29 Dashboard Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 30 Wait Indicator Xamarin/PhoneGap . . . . . . . . . . . . . . . . . .31 Add Incident Picker Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 32 Worker Queue Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 33 Incident Detail Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 34 Context Menu Xamarin/PhoneGap . . . . . . . . . . . . . . . . . 35

Responsiveness . . . . . . . . . . . . . . . . . . . 35 Touching vs . Keyboard/Mouse . . . . . . . . . . . 35 Long Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Page Transitions . . . . . . . . . . . . . . . . . . . . 36 New Features . . . . . . . . . . . . . . . . . . . . . . . .37 Compliance with Platform Design

Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .37

Other Factors . . . . . . . . . . . . . . . . . . . . . 37 Importance of Xamarin Build Settings . .37 MDM Products . . . . . . . . . . . . . . . . . . . . . . 38

Toolset Licensing Cost . . . . . . . . . . . . . 38 Licensing Costs . . . . . . . . . . . . . . . . . . . . . 39 Other Licensing Considerations . . . . . . 39 Third Party Libraries . . . . . . . . . . . . . . . . 40 Application Updates . . . . . . . . . . . . . . . 40

Summary . . . . . . . . . . . . . . . . . . . . . . . 41

http://magenic.com


1 // MAGENIC

When beginning new mobile product development or reevaluating existing mobile product portfolios, a key strategic decision point is selecting the mobile development platform that will best support realization of business objectives, as well as integrate with the enterprise ecosystem . There is an ever-increasing variety of factors which must be considered, each coming with advantages and tradeoffs, when evaluating competing mobile development approaches, such as native, hybrid, or cross-platform development .

Committing to a mobile framework requires more than just considering the technology . Factors include:

• Innovating quickly and fully exploiting a mobile device’s capabilities• Maintaining the codebase on a long-term basis• Re-usability of existing code and extension libraries• Developer knowledge of the framework and availability of talent• User experience and app performance

In this e•Book, we will examine and compare two popular cross-platform mobile development tools, Adobe PhoneGap and Xamarin Platform . Adobe PhoneGap, a hybrid HTML solution, is the commercial version of Apache’s open source Cordova project and uses HTML5 and JavaScript for development . Xamarin Platform is a cross-platform development tool that uses C# to develop mobile applications compiled to native binaries . We will explore how these development technologies’ very different approaches to the cross-platform challenge work well or leave room for improvement .

The basis for our comparison is an application we created for both the iOS and Android smartphone ecosystems . It is an incident tracking application backed by Azure App Service, Storage, and Azure Active Directory services . It contains features that would normally be included in an enterprise-class application such as authentication, authorization, access to the device’s hardware, and persistence of the application’s data in the cloud . This simple incident tracking system allows a manager to enter new incidents that need resolving, assign them to workers, and see the progress and comments on incidents in a worker’s queue . Since the application is for both iOS and Android, it is assumed that any information, including pictures and recordings entered on one platform, are usable by the other . The following shows a high level layout of the application screens without platform-specific design elements . Later in this document we will go over the UI in detail and compare the platform-specific designs that were able to be achieved on both the Xamarin Platform and Cordova .

http://magenic.com


2 // MAGENIC

It is crucial to understand which of these two cross-platform development approaches is best suited for your organization’s mobile product development program before embarking on a lengthy and cost-intensive development project . We will explore the relative strengths of these two platforms based on our development experience to help provide an overview of the merits of each .

OverviewWhen determining which mobile platform technology to use to build a mobile application, we find the following checklist of questions effectively surface important considerations . This matrix illustrates which platform will better solve different criteria that may go into your development platform decision . It is important to note that there is no platform that is best at everything, so selecting the best mobile development platform is always an exercise in weighing tradeoffs . Based on our mobile development experiences and the comparative sample application development for this e•Book, here are our conclusions:

http://magenic.com


3 // MAGENIC

Criterion Description e•Book Discussion Best Platform

Target Audience and UX Level

Who is your audience and what are their UX expectations? If your users are very sensitive to having the app feel “right” on the platform or you are representing your brand, then a more

native experience is preferable.

UX Comparison Xamarin

CPU Utilization

Are you writing a CPU intensive application? Do you have a client side application with CPU

intensive tasks or need access to graphics libraries (games are a great example of this type

of application)?

Performance Metrics Xamarin

API Access

Do you need low level API access? Do you need to do something that involves working with

the intricacies of the native platform, such as selecting the container and encoding type for

audio recordings?

Developer Experience Xamarin

Initial Investment

Is cost a significant factor? Is your primary concern the cost of licensing and initial

development cost? The more platforms you write for, the larger the cost advantage of PhoneGap

usually is.

Toolset Licensing Cost PhoneGap

Initial Development Timeline

Is time to develop a large factor? Do you have an immediate deadline and need the technology that is likely to do the initial development of the

application faster?Please Note: PhoneGap only excels in this area if little or no work is needed for custom plugins,

otherwise this may be a tie.

Developer Experience PhoneGap

EMM (Enterprise Mobility Management)

Integration

Are you working with an EMM system that wraps native binaries? If you already know that you need to integrate with an EMM system, it is

critical to make sure the development platform will work with it.

Developer Experience Tie

Internal Skill Sets

What is the skill set of your internal staff? If you have an internal skillset in .NET or HTML5/CSS/JavaScript, it may help speed development on

one platform or the other.

Developer Experience Depends on internal skill set

http://magenic.com


4 // MAGENIC

Criterion Description e•Book Discussion Best Platform

UI Customization

Do you have existing single page applications that you want to leverage part of the technology,

want an HTML experience, or use a design firm that created an application that looks and feels similar to your website? Some designers want an open canvas to create applications that feel the same on both platforms, which HTML5/CSS

tends to be better at than trying to reskin native controls to look the same. Also, it is possible that

some existing HTML5 applications, particularly ones written as single page applications, can be converted to mobile applications with a potential

to save code.Please Note: As a standard practice we do not

recommend this approach for mobile design; for most mobile scenarios it is preferable to

make an application that adheres to platform design standards.

UX Comparison PhoneGap

Developer Productivity

Do you want the benefit of compile/runtime type checking for development and testing? In many

cases, errors can be identified in the compilation process for languages with compile time type

checking. It can be argued that this helps speed up the development process and creates a more

stable and maintainable product.


Ecosystem Stability

Can you work with an ecosystem that may have significant flux? Flux in a development platform’s ecosystem can cause portions of an application

to be rewritten or the underlying libraries to become unsupported. There is a level of flux

in all platforms, but some have more than others. Currently the number of libraries and

frameworks in the HTML5/CSS/JS ecosystem are in a high state of flux.

Other Factors Xamarin

Feature Support

Do you need access to the platform’s latest features, such as 3D Touch? Do you need an

application with access the latest features of a platform? Xamarin has tended to offer Day One

support for most new features. PhoneGap usually has a delay before Cordova and associated

plugins are updated.


Open Source Utilization

Do you have any restrictions on the use of Open Source technologies or license types? You are likely to need to pull in some open source

libraries for both platforms. There are also commercial options of both platforms.

Other Factors Tie

http://magenic.com


5 // MAGENIC

About XamarinXamarin Platform [“Xamarin”] is a cross-platform development technology from Xamarin, a San Francisco-based mobile development technologies company . Xamarin grew out of the Mono project in 2011 and allows C# developers to create native executable apps for OSX, iOS (including Apple Watch), Android (including Android Wear), Windows Phone, Windows Store, and Windows 10 Universal apps .

Developers can use the Visual Studio environment to develop, build, and debug, or use Xamarin Studio, a lightweight IDE, on Mac or Windows .

Xamarin apps can be written in one of two “flavors”: using the “classic” Xamarin Platform and the new Xamarin .Forms framework which is a library that sits on top of the Xamarin Platform .

Xamarin .Forms, first released in 2014, allows both reusable backend code as well as UI, enabling up to 95% code reuse . UIs are rendered in native controls on iOS, Android, and Windows Phone, staying true to the host platform’s overall user experience .

The Xamarin Platform, either Xamarin .iOS or Xamarin .Android, targets a specific mobile platform . While back end code and libraries are still reusable, it allows 100% API access and granular control of the UI and platform-specific functionality (e .g ., Android Material Design, Apple Pay, Google Play Services) .

In brief, select the Xamarin Platform when you want to create truly native user interfaces for each platform, possibly with significant UI differences . Select Xamarin .Forms when sharing the UI code (creating a single UI) is more important than creating unique platform UIs .

Note that Xamarin .Forms also has the capability to implement platform-specific features and UI to help create experiences unique to each platform . However, frequent use of those features may indicate the Xamarin Platform may be the better choice; it’s the choice we’ve made for this e•Book’s sample application .

Xamarin applications of either flavor can be distributed through public or private app stores .

About PhoneGapPhoneGap is the Adobe-branded version of Apache’s open source Cordova project . It is a mobile development technology referred to as a hybrid . Hybrid applications run in a native container on the device but applications are created primarily using HTML5, JavaScript, and CSS .

The advantages of a hybrid development technology like PhoneGap over a traditional website is that a device’s native hardware can be accessed through plugins, allowing for Java and Objective-C/Swift code to be used to control the device . Since these plugins are exposed as PhoneGap plugins, the developer only needs to know HTML5 and JavaScript to take advantage of them . However, if a plugin does not exist, it requires the developer to write the necessary functionality in Java or Objective-C/Swift .

http://magenic.com

https://xamarin.com/

http://phonegap.com/

http://cordova.apache.org/


6 // MAGENIC

Additionally, unlike mobile web sites, PhoneGap applications can be distributed through public or private app stores .

MethodologyWe compared Xamarin and PhoneGap’s approach to mobile development from a variety of different angles . Determining the appropriate development technology is rarely as one dimensional as looking at which tool performs better in some narrow field or which enables a given user experience; there are many factors that should be considered individually and together to decide which is the best development technology for a given scenario .

We compared four primary areas we believe are relevant to building enterprise applications using the sample application, including:

• Developer Experience• Performance• User Experience • Cost

In addition, when results were particularly notable in other areas of enterprise interest, we made note of them .

The sample application was developed using the PhoneGap and Xamarin ecosystems based on the same design and requirements . Please note that the sample application was not explicitly designed to benchmark performance or UI differences, but instead to simulate a common enterprise mobile application scenario .

A note about performance testingPerformance testing on HTML5/CSS/JavaScript applications can be notoriously difficult to measure . This is mostly due to the asynchronous nature of many HTML5 and JavaScript operations and knowing when operations actually complete .

From a user’s perspective, performance can be measured in terms of simple things, for example: how long does my application take to load, how long does it take for a page transition to take place so I can see everything and start using it, and how responsive is the application to user input .

For strict start-and-stop timings we exercised the application through the UI, paying attention to when operations began and ended . For those interactions where the user could see a clear start and stop, such as opening the application, we repeated the function ten times, recording the results on a GoPro camera . The recordings were then examined to determine precisely when the operation began and, from the user’s perspective, when it was complete .

http://magenic.com


7 // MAGENIC

Developer ExperienceDeveloper experience has a large impact on the ease with which an application can be created, how easy it is to maintain, and what help a developer is likely to require when writing the application .

Choosing a technology with little or no support—or with an inferior development experience—can result in an application that is unstable and difficult to find qualified developers to maintain . In addition, support is a determining factor in readily finding developers who are able and willing to work with a given technology .

Languages UsedWe used a variety of libraries and frameworks that are likely to be found in Xamarin and PhoneGap applications for our sample so it would be representative of what may be created and deployed using these technologies . Other than the cost of the Xamarin tooling and Visual Studio IDE, all libraries used were open source or otherwise had no direct cost .

XamarinThe Xamarin application followed a Model/View/View Model (MVVM) pattern to take advantage of cross-platform binding opportunities . Other packages were used to allow cross-platform code sharing .

• MVVMCross An MVVM library to create cross platform applications . The current version (3 .5 .1) was used, though some classes from the upcoming versions were pulled in to work with Android Material Design components .

• ACR MVVMCross Plugins Extensions to the MVVMCross platform to allow native cross-platform functions such as dialogs and networking .

• URLImageViewHelper A library for downloading, caching, and displaying images over http for Android .

• SDWebImage A library for downloading, caching, and displaying images over http for iOS .

• Xamarin.Mobile Cross-platform library for accessing media files on a device .

• JSON.NET Newtonsoft’s library for manipulating JSON in .NET .

http://magenic.com


8 // MAGENIC

PhoneGapIt is possible to create a simple app using nothing but the PhoneGap .js / Cordova .js library . However, mobile UI development libraries like Ionic are becoming increasingly popular and make development easier . This is because the user is given a CSS framework to create mobile applications that look like mobile applications instead of starting with HTML’s blank canvas . Our PhoneGap application follows a Model View Controller (MVC) pattern and uses the following libraries:

• PhoneGap Wraps our HTML and CSS into a native app .

• Ionic Provides Angular directives for PhoneGap apps and provides a strong UI framework .

• ngCordova A collection of AngularJS extensions for the Cordova / PhoneGap API .

• AngularJS A framework for creating MVC applications, usually a single page application (SPA) .

• Other Plugins Plugins needed to access hardware components such as images or the camera .

Code Reuse

XamarinXamarin has several ways to reuse code . The most common structural ways are through the use of shared projects and portable class libraries . There are also coding patterns, such as MVVM, that help support the concept of separation of concerns and as such create a reusable pattern . As noted previously, we used MVVMCross to achieve this .

LINES OF CODE % OF TOTAL

Shared Code 2,612 42%

Android-Specific Code 1,282 21%

iOS-Specific Code 2,357 38%

Total 6,251

PhoneGapPhoneGap had nearly 100% code reuse . Views and controllers work on all devices and do not need to be shared . We did, at times, check in the controller for the current platform type (iOS and Android) and then use IF statements in the views to show different HTML based on that value . For example, the add button on the dashboard is shown in the title bar in iOS and as a floating button on Android .

http://magenic.com


9 // MAGENIC

LINES OF CODE % OF TOTAL

Shared Code 1,152 99%*

Android-Specific Code 4 < 1%

iOS-Specific Code 4 < 1%

Total 1,160

*although, the PhoneGap application did not fully satisfy the app requirements

Code Reuse CaveatsCounting lines of code is not the most accurate measure of code reuse or the associated effort to create the application . Different languages are more likely to have more lines or longer lines than others . For example, the opening parenthesis for PhoneGap was placed on the same line as the control structure, which is a common convention for JavaScript . In Xamarin, the opening parenthesis went on a new line after a control structure, as per normal C# convention, which had the impact of inflating the overall Xamarin line count .

Additionally, Xamarin uses the storyboard designer for iOS, so there are no direct lines of code written and the XML generated is quite lengthy . For these comparisons, all HTML, interface XML, and storyboard efforts were not counted; only custom C# code for Xamarin and custom JavaScript code for PhoneGap were used .

Finally, it is important to note that the PhoneGap application did not fully satisfy the requirement that the recordings be able to be played back on either platform . In order to satisfy that requirement, we would have had to write Objective-C/Swift and Java custom plugin logic for both the iOS and Android PhoneGap applications . This would have had the impact of increasing the lines of code written for the PhoneGap application, reducing the percent of shared code and introducing other languages into the mix .

ConclusionIn general PhoneGap enjoyed a large advantage, both in terms of percentage of code that was cross-platform and much less code being written overall . However, if you have to work with features not supported by PhoneGap, you need to write custom plugins in the platform-specific languages for each target platform . If we had done that, this advantage would have been significantly less than this test indicates .

Based on our experience with Xamarin .Forms, we are confident we would have seen over 90% code reuse if we had used that instead of the Xamarin Platform .

http://magenic.com


10 // MAGENIC

Developer ToolingThe following toolsets were used in the development of the Xamarin and PhoneGap projects:

Xamarin• Visual Studio 2013• Resharper (https://www .jetbrains .com/resharper/)• XCode [for iOS Storyboard work]

We used Visual Studio, Microsoft’s premier development environment with a long history of enhancements, as the IDE for the Xamarin work on this project . Built into Visual Studio are a variety of tools, including source control integration and package management using Nuget and the Xamarin Component Store . Both of the package management tools were used in the solution and they were found to offer a good ability to find, reference, and manage the versions of different packages .

Visual Studio’s integration with Xamarin also allowed advanced debugging capabilities . Break points were added and worked as expected to step through code . Ultimately, the debug experience was good when connected to the iOS simulator, Android emulators, or physical devices .

For work with iOS, we paired our Windows Machines to OSX devices with Xamarin installed . This allowed us to compile and deploy out to physical iOS devices or run our application in the simulator . If iOS is a target platform, an OSX machine has to be involved and are generally paired, one per developer, for Xamarin development .

XCode was used for iOS UI development work in the Storyboard . There is the ability to work with Storyboards as well when using Xamarin in either Visual Studio or Xamarin Studio, but we have found that XCode offers a more reliable storyboard editing environment, particularly when it comes to constraints . However, there is no difficulty in editing the storyboard in XCode and using it in the Xamarin project .

Resharper offered many tools in the Xamarin solution to help maintain the quality and consistency of the codebase . This type of tooling can be customized to identify issues with the codebase as well as help enforce development standards .

PhoneGap• Atom (atom .io)• Ionic Lab (lab .ionic .io)• OSX Terminal

The development environment for the PhoneGap project used open source tools like GitHub’s Atom editor . While this is a decent editor it doesn’t have the power of the Visual Studio environment and provided an experience that was not as integrated as the one provided by Xamarin’s Visual Studio integration .

http://magenic.com

https://www.jetbrains.com/resharper/

https://atom.io/

http://lab.ionic.io/


11 // MAGENIC

These tools do provide for package management and build integration with Bower, Grunt, and Gulp . They generally require a fair amount of scripting and have less of a visual interface as compared to Nuget or the Xamarin Component Store . Additionally, Bower does not have as nice a visual catalog . Having said that, the underlying scripting ability of Grunt and Gulp can create a powerful configuration management tool for the build process .

Debugging was primarily done using the debugging tools in Chrome and Safari . Both of these tools allowed remote debugging on physical devices and simulators . These were effective tools but were outside the bounds of the Atom IDE . This left a more disconnected development environment than was provided by Visual Studio . Additionally, it is unclear if something like TypeScript were used in such a project if the TypeScript would be debugged or the generated JavaScript .

ConclusionA fair amount of discussion could be had of the comparative merits of such toolsets . A free tool is not necessarily a poor quality tool; Google’s recent Android Studio is a good example of a toolset that is both high quality and free . Having said that, the combination of Visual Studio and Resharper that were used to create the Xamarin project is a well-respected and powerful combination .

UI Development

XamarinThe Xamarin Platform allows for the creation of native UIs, normally StoryBoards in iOS and XML in Android . Inside Visual Studio both platforms allowed for a visual designer . This allowed us to take advantage of platform-specific design paradigms like Android’s material design and adhering to iOS’s changing Human Interface Guidelines .

The experience in Visual Studio for Android XML development provides a strong designer experience . Usually design was done in the XML layout screen, switching to the designer to get a visual idea of how it will be rendered at runtime . The MVVM Cross library allowed for data binding that could be put directly inline with the Android XML . For those that created coded UIs that capability is allowed as well, so the designer and Android XML could be skipped entirely .

This iOS experience was not as clean . Visual Studio allows for the editing of StoryBoards but not of Xibs . Additionally, the Visual Studio instance needed to be constantly connected to an OSX machine . We found that the Visual Studio storyboard integration was not always reliable, particularly when it came to creating constraints . In most cases we edited the storyboard directly in XCode . It is important to note that editing the storyboard in XCode and using it in our Xamarin project provided no technical problems for us .

http://magenic.com


12 // MAGENIC

Unlike with Android, the MVVM Cross bindings could not be directly added to the physical design and had to be created in code for the iOS project . Also, creating UIs with flexible layouts was not nearly as easy with iOS’s constraint system as it was with Android XML or HTML5 . The storyboard also contained multiple screens and was problematic from a source control merging perspective if multiple developers work on different screens at the same time . Like with Android a coded UI could be created, skipping the use of storyboards .

PhoneGapThe PhoneGap UI creation experience was similar to what you would expect when creating an HTML5 application . Generally the HTML was coded by hand without the use of a designer . The UI work was checked by running the application in a browser . This was a reasonably quick experience but didn’t provide the same interactive view of the UI being created as was possible in the Xamarin project .

The use of the Ionic framework made creating a UI that looks correct for the platform relatively straightforward . However, displaying layouts differently on each platform did require a certain amount of extra coding . For example, showing a floating action add button on Android and a add button in the navigation bar in iOS required some slightly different html . With Ionic it was relatively easy to specify what HTML to be used for a platform but it had to be checked for accuracy at runtime .

ConclusionXamarin definitely had the better design time tooling for user interface creation . Designs could be created and usually viewed for accuracy all within the development environment . However, the technologies were not the same requiring the user interface to be written twice . It is also important to note that the Android development experience was far superior to iOS with Xamarin . This was partly due to the Xamarin storyboard designer’s connection to the OSX machine being somewhat slow and unreliable and partly due to weaknesses in the underlying iOS storyboard and constraint technologies that are outside of Xamarin’s direct control .

PhoneGap’s tooling wasn’t nearly as nice and applications needed to be run to see the results of the HTML design . However, much less interface code was written and in general much less time was required by the developer dealing with view logic and creation . The developer also had the advantage of only needing to know a single user interface development technology stack when the Xamarin development required knowledge of both the Android and iOS native development technologies .

Long Term MaintenanceBoth the Xamarin and PhoneGap solutions were created using supplemental third-party frameworks that provided structure and enhanced maintainability .

http://magenic.com


13 // MAGENIC

Ecosystem StabilityThe HTML5/JavaScript/CSS ecosystem has gone through a high degree of flux over the last several years . Even popular frameworks are not immune to this phenomenon . For example, the PhoneGap solution was created using Ionic, which sits on top of the AngularJS framework . The Angular team announced that Angular 2 .0 will fundamentally redesign parts of the framework with no direct upgrade path and will likely require substantial refactoring of existing Angular 1 .x projects to use .

While many developers may know HTML5/JavaScript/CSS, there is significant fragmentation within that community regarding the frameworks themselves, as well as new frameworks like Facebook’s React, that frequently come up and take mindshare among the community . This makes it difficult to chose the right framework for PhoneGap that will support a long term maintenance scenario .

While this sort of flux does happen on occasion with similarly popular .NET frameworks, it is not nearly as common as with the HTML5/JavaScript/CSS ecosystem . Xamarin solutions require fewer dependent frameworks, relying more on design patterns and core C# language skills, with extensibility provided from readily available NuGet packages or via the Xamarin Component Store

Code MaintenanceThe underlying languages themselves take very different approaches . C# has a type system that supports compile and runtime type checking while JavaScript currently does not . There are arguments to be made that compile time type checking leads to more stable and maintainable applications . As mobile applications change or grow, compile and runtime type checking makes it easier for developers to maintain functioning code . It seems that the value of this has not been lost in the JavaScript world, where extensions like TypeScript that do transpile checking are popping up . This is an area where if you currently find type checking to be important to long term maintenance, then C# and Xamarin are better positioned to deliver .

Unit TestingA final thought on maintenance: as mobile applications become more common in the enterprise, they are being increasingly held to enterprise development standards . One way this manifests itself is in the need for unit testing and associated build server tie-ins . Both Xamarin and PhoneGap can deliver in this space . Xamarin works with standard .NET nUnit testing frameworks, while PhoneGap uses common JavaScript testing frameworks like Jasmine . Optimal unit test design revolves around isolating units of work, which is commonly done via dependency injection and mocking . Dependency injection and mocking frameworks are quite common in the .NET world and many such libraries work with Xamarin . However, care must be taken so that any unit test that runs on a physical iOS device is not written in such a way that the mocking framework uses disallowed functionality such as reflection .

http://magenic.com


14 // MAGENIC

Due to the lack of type safety in JavaScript, dependency injection and mocking frameworks are uncommon and other methods must be used to isolate units of work . In fact, an argument can be made that development and unit testing may need to be more complex to handle the potentially unknown nature of data that is passed into a unit of work to make sure it properly reacts to unexpected inputs .

ConclusionXamarin provides compile and runtime type checking that many consider important for long term maintenance stability of a product . Unit testing is possible on both frameworks with Xamarin having the edge due to more common .NET inversion of control and mocking frameworks . While both ecosystems have some level of flux, JavaScript is normally considered the more dynamic of the two . Having said that, the HTML/CSS/JavaScript ecosystem isn’t tied to any particular vendor and will likely stay in play for the foreseeable future . .NET is supported by Microsoft and similarly will likely stay in play for the lifecycle of any present mobile projects . Xamarin itself, is a smaller company and does represent a higher level of risk as their financial picture is not as clear . Even then, companies such as Microsoft have an interest in keeping Xamarin’s technologies in play so we would classify the risk of their product disappearing as low .

Code Organization

XamarinThe Xamarin project uses a standard .NET cross platform project structure with a portable class library (PCL) to contain shared code and two platform-specific libraries (one for iOS one for Android) . External packages were added using Nuget and the Xamarin Component store .

All of the shared application logic was contained in the PCL, including models, view models, data access, and common interfaces . Additionally, it was found that some value converters for binding were able to be shared as well so they also were located within the PCL . The PCL represented a reusable unit that could be distributed outside of this solution as well and used in other projects that the profile supported . Our PCL targeted profile 111 which would allow the library to also be used in .NET 4 .5 applications and in Windows Phone 8 .1 applications .

Within each of the platform-specific projects are the storyboards and view controllers (iOS), and the XML views and activities (Android) required to make platform-specific UIs . Additionally, platform-specific code to access the hardware, such as fine control over audio recording formats, is within the platform-specific projects . Platform-specific code to access the hardware is called by the ViewModels within the PCL through the shared interfaces, using the inversion of control (IoC) container that MVVM Cross provides to resolve out the appropriate platform-specific implementation at run time .

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

http://magenic.com


15 // MAGENIC

PhoneGapThe project structure is a modified version of the Ionic default folder structure that follows John Papa’s Angular Style guide (https://github .com/johnpapa/angular-styleguide) .

The default Ionic structure to have all controllers in one file, all services in one file, etc . As John Papa explains in his style guide, this isn’t a very clean way to do things . Our project structure moves each controller, service, and template to its own file and groups items by their type . For larger projects an alternative structure is to group by functional area and not by type, but we felt that wasn’t necessary here and would lead to a large number of subfolders for such a small app . In this respect the layout was somewhat similar to what it was with the Xamarin project, where individual concepts have their own file (controller, service, directive, etc) . One large difference would be if this code needed to be shared among different projects, instead of passing around a single .dll like with Xamarin, a collection of JavaScript files would have to be distributed .

ConclusionBoth Xamarin and PhoneGap can create project structures with a reasonable way of handling code organization within to project . With Xamarin through Microsoft’s shared projects and PCLs there is also a mechanism to organize code for use in multiple projects . The PhoneGap solution could do it all in one project but sharing code outside of that unit would not have been as neat . It is also notable that if the sound issues in the Cordova project were addressed with platform-specific projects then that would have included two additional projects of different technologies (Java and Objective-C/Swift)

Compile TimeThe amount of time it takes to compile an application can have a significant impact on developer productivity . The following compile times were all taken on the same machine, a MacBook Air 6 .2 with 4Gb of Ram and a 1 .4 Ghz Intel Core 5 processor . The PhoneGap project was build from XCode on the Mac and the Xamarin project was done from Visual Studio on a machine paired with the Mac, as that mirrored the Xamarin approach taken . The compile times here are for a release build, which takes significantly longer than a debug build . For example, Xamarin built the same project in 34 seconds for iOS and 32 seconds for Android .

XAMARIN PHONE GAP

iOS 70 seconds 18 seconds

Android 40 seconds 25 seconds

The PhoneGap project has a noticeable advantage when it comes to compile times . While the MacBook Air is not a powerful machine, it seems that it is more than adequate for a PhoneGap project .

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

http://magenic.com

https://github.com/johnpapa/angular-styleguide


16 // MAGENIC

ConclusionIf you plan on doing work in Xamarin you will need a high end Mac to minimize the impact of compile time . It is recommended that a high speed MacBook Pro or better be used to minimize build times .

Access to Native Functionality & APIsXamarinThe Xamarin team has wrapped 100% of the native iOS and Android APIs for direct access via C# from a Xamarin application . In general, any native API that can be accessed in a Java Android or Objective-C/Swift iOS application can also be accessed in a Xamarin application . The Xamarin team has also reshaped many of these APIs to be more familiar to .NET developers without losing functionality .

For libraries—particularly third party libraries—that are not currently wrapped and accessible from .NET, bindings libraries can be created . These are created using .NET code to wrap the native library . In general, this process is pretty straightforward for components with simple APIs . However, the documentation and support can be somewhat sparse when wrapping more complex APIs .

The ability for Xamarin to access native APIs became critical when recording sound . We found that sound needed to be recorded in a format and codec that was available on both platforms . Since the Android MediaRecorder and iOS AVAudioRecorder APIs were directly available, the sound could be recorded in MP4 using AAC, a format available on both platforms .

PhoneGapAccess to native functions are handled with plugins on PhoneGap . Apache maintains an extensive plugin repository at plugins .cordova .io, which currently has over 500 plugins . If you need a plugin that isn’t currently available, you can write your own using Java (for Android) and Objective-C / Swift (for iOS) . Writing custom plugins is outside the scope of this e•Book and isn’t something we looked into .

The Ionic team has started their own collection of extensions, ngCordova, that wraps many of the popular plugins in Angular extensions . This makes it very simple to add a plugin and then use the prewritten Angular extension to take a photo or record audio .

We used plugins for connecting to Azure, taking photos, recording audio, and playing back audio, though as mentioned later these default plugins did not give us the full functionality we required .

http://magenic.com


17 // MAGENIC

The audio plugins gave us a problem . We used the standard device .capture calls to record audio as described in the Cordova docs . This worked fine, however it records using the device’s audio recording application and, as such, does not provide any way to change the audio format being used . We found when doing this we could not play files recorded on Android on iOS devices and vice-versa .

Even searching for other plugins we were unable to find an audio recording plugin that allowed us to record in a standard format that would allow for playback on all devices . This left us with two options: convert the audio in the service layer or write our own audio recording plugin in Java and Objective-C/Swift . Neither was in the scope of this project and the PhoneGap apps were left without the ability to record and playback audio in a cross platform fashion . The implication here is that if your PhoneGap application needs functionality outside of what existing plugins provide you may need to plan on some level of native development or server side conversion to bridge that gap .

PhoneGap Windows App SupportWhile PhoneGap support for Android and iOS is very high, Windows apps are supported but not as well .

We did not build a Windows app for this project, but we have seen problems using PhoneGap and Ionic with Windows Universal apps . Some workarounds are needed, including an MSDN shim and using the $compileProvider directive .

Xamarin provides good support for Windows Phone and Windows Store apps, with recently released Windows 10 Universal support .

ConclusionIf you need full access to the native device APIs then Xamarin will likely be a better solution than PhoneGap . If you do decide to use PhoneGap, you should understand that may mean eventually writing platform-specific plugins in native languages . This is particularly true of targeting the Windows ecosystem . While code sharing technologies like shared projects and Portable Class Libraries will serve to get your code to run on Windows and access to the native APIs through inversion of control, the same cannot be said of PhoneGap . With PhoneGap the Windows and Windows Phone plugin support is far behind what is available for iOS and Android . If your PhoneGap application needs to deploy to Windows or Windows Phone there is a much higher possibility of needing to write a custom plugin .

Dev EcosystemThe HTML and .NET worlds each have vibrant and strong ecosystems of third party tools and libraries, both commercial and open source . Substantial and popular libraries and frameworks can be found in either realm .

http://magenic.com

https://github.com/MsopenTech/winstore-jscompat

https://github.com/MsopenTech/winstore-jscompat

http://stackoverflow.com/questions/23358114/windowsphone-8-phonegap-and-angularjs-routeprovider-not-working


18 // MAGENIC

.NET has a large and thriving developer and partner ecosystem . With millions of .NET developers worldwide, Xamarin provides an opportunity to extend their existing skills into mobile . Additionally, there are thousands of NuGet packages that can be reused for Xamarin projects, as well as a growing number of open-source and commercial components to extend Xamarin capability through cross-platform UI controls, data visualization, connectivity, and security .

The HTML5/CSS/JavaScript ecosystem is going through more flux, thus entailing more concerns around long-term maintenance of the solution . Breaking changes and the rapid rise and fall of HTML frameworks should make developers wary about which ones they make a long-term bet on .

ConclusionBoth platform ecosystems provide vibrant and wide ranging third party libraries and frameworks . There are many more HTML5/CSS/JavaScript developers, but Xamarin also has a considerable following . In general, the .NET stack that Xamarin sits on top of has less flux than PhoneGap’s HTML5 ecosystem .

Performance Metrics

App SizeWhen looking at the size of compiled applications there are two things to consider . First, how large is the file that is downloaded? Second, how much space does the application consume on the device once installed? When looking at the size of the application on the device, we made sure to clear any cached data on the device that the application may have downloaded . In all cases the PhoneGap application was smaller .

For the Xamarin application the linker setting was set to “SDK assemblies only .” This setting provides a moderate level of removal of unneeded code from Xamarin applications; in particular, it removes any portions of the SDK and the Mono framework that it determines are not used, but leaves in all referenced third-party libraries . In iOS the application architecture selected was arm64 and arm7 for both the Xamarin and PhoneGap projects . It is important to note that these simple applications had very little in the way of image assets . In many cases enterprise applications have a large footprint of included image assets which would reduce the size difference on a percentage basis, that is to say it would be less of a factor .

/ / / / / / / / / / / / / / /

/ / / / / / / / / / / / / / /

http://magenic.com


19 // MAGENIC

Start TimeOne thing a user will notice is how long an application takes to initially load and for the user to start interacting with the application . Many times a user will keep an app running and not need to restart, so the impact on this test can still be limited . However, it gives the user the first impression of your application . The Xamarin versions of the app showed consistently faster app load times, loading 25% faster on Android versus the PhoneGap version . Long load times will not only affect the overall perception of the app, but if used many times daily can be a source of frustration and dissatisfaction .

The test devices used for these timings were:• iOS: iPhone 5 32GB, iOS 8 .4 .1• Android: Google Nexus 5, Android 5 .1 .1

Display Long ListWe purposely set up data so one user would have 1,000 items in their resolved queue . We then displayed this list to the user and measured that amount of time it took to display and for the user to start interacting with it . Loading lists of items is a common scenario in mobile applications and thus one where users are likely to notice differences in performance loading a page .

Memory UsageMemory tests were performed multiple times on physical devices with frequent resets in order to ensure no artifacts or caching carried over from one test to the next .

For the iOS test, the application was exercised in exactly the same way and the session recorded in order to provide a means of reliable review . The final figures here are an average of the recorded values taken at the end of each test run using XCode Instruments . Persistent bytes represent the amount of memory the application is currently using at the end of the test . The Total Heap + Virtual show the cumulative memory that was allocated by the app and iOS for the duration of the test . The tests indicate that Xamarin iOS application ended using a larger memory footprint but the PhoneGap application consumed and released a much large amount of memory while the test was running .

For the Android test, the current memory usage was queried after a similar walkthough of the application while monitoring with Android Debug Bridge (ADB) . Overall, we found that the PhoneGap application used more memory than the Xamarin application . Two particular areas where PhoneGap seemed to consume memory were ashmem (asynchronous shared memory) and unknown memory usage (memory usage that could not be classified) .

/ / / / / / / / / / / / / / /

/ / / / / / / / / / / / / / /

http://magenic.com


20 // MAGENIC

XAMARIN PHONE GAP

iOS Persistent Bytes: 470 MB 125 MB

Total Heap + Virtual: 3 GB 6 GB

Android PSS Total: 165.1 MB 231.5 MB

Private Dirty + Clean: 160.0 MB 225.7 MB

Performance SummaryOn iOS we found significant differences between PhoneGap and Xamarin in terms of CPU utilization .

PhoneGap put significantly higher load on the iPhone CPU overall which, depending on the application, may translate into lower battery life even if the user didn’t notice a “lag” in the application’s interactions . We should also note that we did experience significant lag on PhoneGap when scrolling and loading images in lists .

The graph at right describes the total CPU time at the end of each test run . As you can see, PhoneGap utilized significantly more CPU even though the exact same data was used and the same test script was followed in each case . Significantly higher CPU usage can result in poorer performance, noticeable user interaction lag (which we noted), and reduction in battery life if high CPU usage is sustained for long .

We experienced a similar CPU usage pattern on the Android platform though were not able to have the same level of metrics over time from ADB as we saw from XCode Instruments . From monitoring the app during the walkthrough we found the Xamarin app spiked at 53% CPU usage and usually was less than 10% . The PhoneGap application spiked at 73% using the same incident . We collected this information while monitoring the results of an ADB shell top | FINDSTR [app id] . This monitoring also verified the memory figures collected previously . Overall, the PhoneGap application was found to use more memory and CPU time to achieve the same results .

CPU Intensive TasksThe sample application we created didn’t contain any CPU intensive tasks . We did want to cover this topic, however, and it is one that we have covered in previous testing between Xamarin and Cordova . (see: http://magenic .com/Blog/Post/4/Mobile-Development-Platform-Performance) The previous testing should give us an equivalent picture .

In our previous test we created a Sieve or Erastenies for each platform . This test calculates prime numbers, or to be more accurate, calculates numbers that can’t be prime starting with two and then what’s left is known to be prime . For our tests we found the largest prime up to 50,000,000 . For these tests we found Cordova to be 22 times slower than Xamarin on the Android platform and 14 times slower on iOS .

/ / / / / / / / / / / / / / /

http://magenic.com

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



21 // MAGENIC

While it is interesting to look at the performance of CPU intensive tasks, it is only fair to point out that although CPU load causes battery drain, most enterprise mobile applications are not particularly CPU intensive . Even then, given that PhoneGap is significantly slower, it is likely to cause higher CPU load even during common application tasks . This observation proved true when looking at CPU usage our non-CPU intensive sample applications as well . Additionally, tablets that can run multiple applications side-by-side are becoming more common; consequently, applications may have to share the CPU with another foreground application (See Windows 8 .1/10 tablets and Apple’s iOS 9) .

ConclusionThe overall tests show that apps ran significantly more efficiently on Xamarin vs . PhoneGap on iOS and Android platforms . The applications started faster, used less memory, and ran normal tasks with greater speed . Given the nature of the underlying technologies this isn’t particularly surprising . This is one of those areas where you need to ask yourself what do your mobile applications need to do and is this difference in performance material to your needs?

User Experience Comparison

Differences in TechnologyAs previously indicated, the PhoneGap solution uses a combination of HTML5 and CSS for its visual display while Xamarin uses the interface components native to each platform . For the sample application, modern iOS design standards were used along with Material Design on the Android platform .

The PhoneGap application used the Ionic framework to simulate these same iOS and Android designs . Some minor platform-specific tweaking was used to get items like the floating action button on the Android platform . However, no extraordinary measures were used to get it to look perfectly native . The purpose of this comparison is to see how close a platform like PhoneGap can get to a native user experience without expending significant effort .

Side-by-Side ComparisonIn the following comparisons, the native Xamarin UI is shown on the left while the PhoneGap version using Ionic is on the right . The screen captures for Android were taken on a OnePlus One (https://oneplus .NET/one) running Cyanogenmod for Android version 5 .1 .1 . The iPhone screen captures were taken on an iPhone 6 running iOS 8 .4 .

http://magenic.com

https://oneplus.net/one


22 // MAGENIC

ANDROID

Login ScreenXamarin PhoneGap

Outside of some minor control placement issues, the most noticeable difference is in the “Sign In” button itself . The native UI uses the application theme so the button shows up blue with white text and highlights with a darker blue when you click on it . The Ionic experience didn’t, by default, honor an Android-looking theme for the button without having written custom platform-specific styles .

http://magenic.com


23 // MAGENIC

DashboardXamarin PhoneGap

The PhoneGap application does a good job of mimicking the Android material design . With a few lines of platform-specific code we created a floating action button (this is located lower right hand corner of the screen; the round green add button) but that looks close to native . There are some differences, though . The floating action button by default had a transparent + in the center and the spacing of the status items wasn’t as tight as on the native implementation .

Another interesting layout feature was that the PhoneGap screen did not provide the same level of fine control over the spacing as was achieved in the native UI . With further work this was likely possible by setting negative margins but the native UI offered us an easier time giving precise control over the spacing than the HTML5/Ionic CSS controls did in PhoneGap .

http://magenic.com


24 // MAGENIC

Wait IndicatorXamarin PhoneGap

In this comparison we look at the wait indicator . The reason we selected the OnePlus One for this comparison is because it has a distinctive octagonal spinner for a wait indicator . This is the kind of detail that PhoneGap applications can rarely match and leads to the application not quite feeling right on the platform, even if the user does not consciously pick up on the difference .

http://magenic.com


25 // MAGENIC

Add Incident PickerXamarin PhoneGap

Several things are slightly off on this screen, the most noticeable being the dropdown list is far different than what would be expected with Android Material Design . There are some other subtle differences, as well, including the underline of the test input fields not being correct on the PhoneGap application and the control that produced the picker looking like a normal HTML dropdown .

http://magenic.com


26 // MAGENIC

Worker QueueXamarin PhoneGap

The item of difference here is the appearance of the tab control . The slight red underline on the native Android Xamarin honors the Android theme of the application; this detail is missing from the PhoneGap application .

http://magenic.com


27 // MAGENIC

Incident DetailXamarin PhoneGap

For the incident detail screen there were things in the design that were harder to do in the PhoneGap application . For example, the navigation bar in the design was transparent . This comparison shows what a true cross-platform implementation of the PhoneGap application would look like . Most noticeably absent is the floating action button of the Android native design achieved with Xamarin .

http://magenic.com


28 // MAGENIC

Context MenuXamarin PhoneGap

The context menu in the PhoneGap application looks like a reasonable facsimile of the native implementation, with the most prominent difference being the height of the menu and the white space within it .

http://magenic.com


29 // MAGENIC

iOS

Login ScreenXamarin PhoneGap

As with the Android application, the “Sign In” button is a good example of some of the differences between a native UI and one created with PhoneGap . As per modern UI standards, the iOS button has no border; however, the button on the PhoneGap application looks exactly like it did on Android .

http://magenic.com


30 // MAGENIC

DashboardXamarin PhoneGap

For the Dashboard the results were very good . The PhoneGap application used a plus in the navigation bar as is expected in iOS instead of the navigation button . This bit of code was iOS-specific as the floating action button code was Android-specific .

One item of interest for the PhoneGap application is that the numbers for the bars do not show up inside the bars as they do on the Android application . This is probably something to do with the CSS used by Ionic to recreate these controls . Custom coding or changes to the CSS files would likely be required to correct it .

http://magenic.com


31 // MAGENIC

Wait IndicatorXamarin PhoneGap

The wait indicator for PhoneGap is similarly missing as it was for the Android application . It is interesting to see that the pull-to-refresh indicator is correct, just as it was for Android .

http://magenic.com


32 // MAGENIC

Add Incident PickerXamarin PhoneGap

Picking a name is very close to the native iOS implementation . Like Android, the dropdown control itself looks like what would be expected in an HTML application . Another item of interest is that the navigation bar’s menu is displaying with Android’s stacked dots instead of the expected iOS Action icon .

Also, what isn’t visible is that the Xamarin native UI implementation has a “Save Incident” button on the form instead of the Android style “Send” button in the navigation bar that the PhoneGap version has . Normally a visual layout seen on Android devices, iOS users may be confused by the icon and the flow to save in this scenario .

Both of these items could have been implemented in the PhoneGap application to give a more native feel if platform-specific HTML had been used .

http://magenic.com


33 // MAGENIC

Worker QueueXamarin PhoneGap

The Worker Queue screen uses a native segmented control for the native iOS UI . The same tabbed navigation is displayed as was used in the Android design in the PhoneGap application . To make this screen look the same as the Xamarin implementation for a native look, platform-specific code would need to be employed .

http://magenic.com


34 // MAGENIC

Incident DetailXamarin PhoneGap

Once again the PhoneGap application does a good job in matching the look of the native UI . Most of the differences could be matched with platform-specific code, including using the correct navigation bar menu icon for the different platforms .

http://magenic.com


35 // MAGENIC

Context MenuXamarin PhoneGap

This is an area where there is a more substantial difference between the native Xamarin implementation and PhoneGap’s . While PhoneGap used a more iOS-like dropdown than it did on the Android application, it didn’t match the native experience .

ResponsivenessWhile generally looking native, a PhoneGap application is technically very different under the hood since it is built on top of HTML5, CSS, and JavaScript—all technologies that were not designed with touch mobile devices in mind . This causes some usability issues when implemented in a mobile environment, where touch interaction and fluid response are paramount .

Touching vs. Keyboard/Mouse InteractionWhen handling click events, web browsers pause for 300 ms after receiving a touch event before processing it as a click . This is done because the browser is waiting to see if the user is going to click again, which would act as a double click . This is expected behavior when navigating a web page with a mouse, but when building hybrid mobile apps with PhoneGap, a 300ms delay is noticeable to the user . Since the user will never double click on a touch centric device, it’s also unnecessary .

http://magenic.com


36 // MAGENIC

There are solutions for the 300 ms delay . FastClick .js is an example of a library that solves the issue by removing the 300ms delay . Ionic also has a solution built in; its ngClick directive is what we used to remove the 300ms delay in our sample PhoneGap application . However, we have seen cases where libraries like FaskClick .js have conflicts with some third-party JavaScript controls .

Another limitation of PhoneGap is its lack of ability to take advantage of the newest interactions with iOS 9, specifically 3D Touch . PhoneGap won’t be able to use this feature, whereas Xamarin can support pressure-sensitive interactions with its 100% access to iOS APIs and events .

Long ListsAs indicated in the performance testing section we had created a test with 1,000 incidents and loaded them in a list to show them on a single page .

Xamarin sometimes showed a longer initial loading time as items were first loaded from Azure into models and then mapped to 1,000 individual View Models . This isn’t necessarily a problem with Xamarin, but more an advantage of the MVC pattern used by the PhoneGap application when compared to how we implemented the MVVM code . However, when this list was loaded, the scrolling was extremely quick and the items appeared to fly by on the Xamarin iOS and Android apps . This is because of how native Android and iOS list management works, which Xamarin automatically takes advantage of . A paging scheme is used on both platforms where only the cells currently visible to the user plus one are loaded . As the user scrolls through the list, the cells are recycled and loaded with data from the list items currently displayed . This makes for an extremely fast scrolling experience .

PhoneGap did not handle this list well . As detailed above, scrolling to the bottom of this list consumed a massive amount of memory . This is due to the fact that there is no paging scheme in use and all 1,000 items were immediately loaded into the UI . The user experience was incredibly laggy and scrolling was very slow .

This is a well known problem for HTML/CSS/JavaScript applications . To correct this, Ionic is spending a lot of effort working out a solution . Although still in testing, and Android only, there are new features coming that will allow large lists to use native scrolling but are currently unavailable . This link explains those efforts: http://blog .ionic .io/native-scrolling-in-ionic-a-tale-in-rhyme/

Page TransitionsCertain page transitions occurred slowly on the PhoneGap platform . In particular there was a delay when navigating backwards to previous pages where the screen would noticeably freeze for a few seconds . This may be related to some of the high CPU usage we noticed on the PhoneGap platform . Experiences like these will frustrate users who are required to use the app for productivity multiple times a day .

http://magenic.com

http://blog.ionic.io/native-scrolling-in-ionic-a-tale-in-rhyme/

http://blog.ionic.io/native-scrolling-in-ionic-a-tale-in-rhyme/


37 // MAGENIC

New FeaturesRecently Apple introduced 3D Touch on their new iPhones . 3D touch relies on the reaction to interface interactions based on how hard the user is pressing on the screen . Given Xamarin’s technology and direct usage of native APIs, they were able to support this as part of their normal day one support for API changes . It is a little harder to imagine how PhoneGap will easily support this concept given that HTML5 does not have a concept for detecting pressure . New features like this also currently only exist on the iOS platform, so any UI code that takes advantage of it would by necessity be platform-specific UI code .

Compliance with Platform Design GuidelinesAs previously stated, the designers of these development platforms tried to maintain compliance with the latest iOS design guidelines as well as Android Material Design . The Xamarin team has no difficulty meeting these goals because Xamarin is using native controls on each platform . However, it should also be noted that to achieve good results, a developer does need to have a thorough understanding of the two different UI technologies and the common UI conventions of each target platform .

The Ionic platform did a reasonable job of mimicking the designs, but the side-by-side comparisons demonstrate that the results were not perfect . Since HTML5/CSS alone starts from a blank canvas, it is conceivable that platform design guidelines could be mimicked perfectly . However, current frontrunner frameworks in this area still fail to achieve that on their own and it is unlikely that most organizations could do better without spending substantial time carefully working through platform differences .

ConclusionNative technologies are undoubtedly the best when done correctly to maintain compliance with platform design guidelines . However, these come at a cost of needing developers who are familiar with multiple UI technologies, as well as a potentially substantial investment in coding to write a UI for both platforms .

PhoneGap can be coupled with frameworks like Ionic to produce a pretty good user experience . They require deep familiarity with only one UI coding platform and substantial amounts of the UI coding will be shared between the platforms . The drawback of this approach is that a truly native user experience will not be achieved . For users of an application written in PhoneGap, there will always be something that feels off .

Other Factors

Importance of Xamarin Build SettingsDuring our tests we found that different Xamarin build settings can have a significant impact on the overall performance of the application, compile time, and even the size of the compiled binaries . More so than with PhoneGap, there are a wide variety of build settings that can have a substantial impact .

http://magenic.com


38 // MAGENIC

For example, the following APK sizes were created for Android when changing the Linking setting:

• No Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 MB• Link SDK Assemblies Only . . . . . . . . . . . . . . . . . . 15.1 MB• Link SDK and User Assemblies . . . . . . . . . . . 9.8 MB

Xamarin developers need to be more aware of the build settings selected than do PhoneGap developers . There are different garbage collectors that can be selected and different optimization and linking settings . Each of these can have a significant impact on build time, the size of the compiled binary, speed of execution, and memory usage .

MDM ProductsBoth Xamarin and PhoneGap create APKs and IPAs that can be signed and installed on devices . As such, they can both can be deployed through the normal distribution mechanisms of Enterprise Mobile Management (EMM, or formerly MDM) products .

Many of these EMM products also come with SDKs that can be referenced from within the code of the app itself . For example, HockeyApp has an API that has existing bindings for Xamarin and plugins that can be referenced from PhoneGap . However, if no existing bindings or plugins are available, then new Xamarin binding projects would need to be created in .NET for the Xamarin solution and plugins in Objective-C/Swift and java for PhoneGap .

There are some EMM solutions that wrap existing binaries (APKs and iPAs) to inject things like secured networking, login, and storage . However, these tools expect the binaries to be created in the native toolsets and languages . While an IPA written using Xamarin or PhoneGap may run fine on an iOS device, an EMM tool’s wrapping mechanism may have trouble recognizing and working with them . If an EMM tool is used, particularly one that wraps binaries with its own functionality, then care should be taken when selecting either one of these tools to ensure they work correctly with the EMM solution .

Toolset Licensing CostGenerally the creation of a PhoneGap application can be done with no licensing or extra cost outside of the hardware to build and compile the applications .

On the other hand, for Xamarin licensing is the norm to create applications . Licensing is per developer, per platform and can be paid either on an annual or monthly basis . There are different subscription levels available depending on if the developer only wants the use Xamarin Studio, if they would like Visual Studio, or if they want more inclusive enterprise support options . Full information on Xamarin’s current pricing can be found here:

https://store .xamarin .com/

http://magenic.com

https://store.xamarin.com/


39 // MAGENIC

While PhoneGap applications can be created for free there are many surrounding products and services that can cost money within the PhoneGap ecosystem . Chief among these is PhoneGap Enterprise which offers application distribution and support services .

http://enterprise .phonegap .com/

Adobe has additional services that can be purchased for the PhoneGap ecosystem . One of the more popular services is PhoneGap Build which offers a build server that will compile applications for Android, iOS, and Windows Phone . This is particularly popular for developers who don’t have direct access to a Mac (regardless of the tools you use, you must use a Mac OSX machine to build iOS binaries) .

https://build .phonegap .com/

There are developer toolsets available that also have associated costs . For PhoneGap one of the more popular ones is Telerik’s Kendo UI Mobile which offers a substantial suite of user controls . Telerik also makes toolsets for the Xamarin platform as well as the UI for Xamarin product, and the “Telerik Platform” is yet another PhoneGap services offering, similar to Adobe’s (and, like Adobe’s, is not free) .

http://www .telerik .com/platform

Licensing CostsFor the extremely budget conscious on upfront cost, PhoneGap projects can be created from start to finish with no investment in the toolset or IDE . Having said that, the amount of money that is spent in tooling for a standard Xamarin project is usually insignificant to the cost of a full application . While the cost of the license may be a factor in the decision making process, it shouldn’t be the primary factor; long term development and support cost considerations should be a larger cost consideration than toolset licensing costs .

Other Licensing ConsiderationsPhoneGap is created from Cordova and as such is under the open source Apache License, 2 .0 . This license does obligate you to include a copy of it [the license] with any software you distribute built with PhoneGap .

http://magenic.com

http://enterprise.phonegap.com/

https://build.phonegap.com/

http://www.telerik.com/platform#overview


40 // MAGENIC

Third Party LibrariesThe third party ecosystem is large for both the .NET and HTML5/CSS/JavaScript platforms . Distribution of packages for Xamarin is done through Nuget or the curated Xamarin Component store, the latter offering a mechanism for reviewing the quality of components in the store . Components acquired using Nuget are usually open source and have no review mechanism other than the number of downloads . The Xamarin Component Store contains a mix of free and commercial add-ons and some of the best [free] components have been developed by teams and individuals at Xamarin . Because of Xamarin’s focus on the enterprise market they have also attracted the attention of all major commercial control vendors, including Infragistics, Syncfusion, Telerik, and several others .

PhoneGap Plugins can be acquired on the PhoneGap website as well as more generic Cordova plugins on the Cordova plugin registry . Additional components can be found in various repositories including Github . PhoneGap can also take advantage of many of the CSS/JavaScript libraries that are available through distribution mechanisms like Nuget in Visual Studio . For example, AngularJS can be acquired and used in a Cordova project using Nuget .

As previously mentioned the ecosystem of components and libraries for HTML5/CSS/JavaScript seem to be in a higher state of flux than they are for .NET . The good news with this ecosystem is there is an ever widening variety of frequently changing toolsets and frameworks available to use . The bad news is the same as the good news . In the .NET world with Xamarin the toolsets and patterns seem to be more stable and mature .

Application UpdatesNormally a new version of an app needs to be distributed to each client device when updating a compiled application . However, a PhoneGap application is mostly interpreted, at least for the non-plugin portions . In practice it is just a container that runs HTML5/CSS and JavaScript . Technically, that code could be downloaded and run right within the application without any redeployment .

This is certainly true for Android PhoneGap apps, even ones deployed through the Play Store . The Apple Store has been more restrictive . Apple requires that the majority of the application’s functionality be deployed with the application itself and any changes must go through the normal approval process . That means that a PhoneGap app that is little more than a redirect to a public website is probably not going to be approved . However, there is a clause in the developer agreement that allows the updating of code when using browser technologies . While this clause is subject to some level of interpretation, it seems that “small” fixes that don’t substantially change the primary functionality of the PhoneGap application could be directly downloaded without going through the [re]certification process . For Xamarin applications, all changes require a redistribution of the package via an app store [or via an enterprise EMM technology] unless internally it also uses portions that are hybrid but such parts of the app would have essentially the same advantages and disadvantages as our PhoneGap implementation .

http://magenic.com


41 // MAGENIC

This e•Book is for informational purposes only. Magenic Technologies, Inc., makes no warranties, express or implied, in this summary. Other product and company names mentioned herein might be the trademarks of their respective owners. © 2015 Magenic Technologies Inc. All rights reserved.

SummaryIn general PhoneGap and Xamarin offer great solutions for creating cross-platform mobile applications . But neither are a one-size-fits-all solution . Care should always be taken to choose the best mobile development platform technology solution based on your mobile application’s requirements .

While both technologies allow you to create compelling mobile application experiences, each requires trade-offs in terms of productivity, performance, and cost . Which approach you choose may vary based on the requirements of the specific application you’re intending to develop, as the importance of each platform’s strengths and weaknesses will also vary with the nature of the application .

As we found when creating our sample application that there were challenges with maintaining a native look-and-feel on the PhoneGap side, and the requirement for recording audio notes that could be shared cross-platform could only be done in PhoneGap by writing native plug-ins in both Object-C/Swift for iOS and Java for Android . However, if those requirements weren’t as constringent, the ability to share nearly all of the code and UI via PhoneGap would be quite compelling, particularly if those new requirements resulted in PhoneGap maintaining a more reasonable CPU load .

Finally, while outside of the scope of the tests performed for this e•Book, we would be remiss if we failed to mention Xamarin .Forms . If, in your evaluation of platform selection criteria, you found yourself at odds between Xamarin performance benefits and PhoneGap code-sharing benefits, you’d do well to take a look at Xamarin .Forms .

Xamarin .Forms is a UI library that sits on top of the standard Xamarin Platform we’ve been talking about and enjoys the same native execution benefits, while also allowing you to create a single UI that is rendered in native controls across all platforms . The primary drawback of Xamarin .Forms from a user experience perspective is that it constrains the user interface design to follow certain paths and patterns .

Xamarin .Forms is a good technology but not a one-size-fits-all solution; you do experience longer startup times than the Xamarin Platform (see: http://magenic .com/Blog/Post/4/Mobile-Development-Platform-Performance) and some complex UI layouts can also suffer performance penalties . Xamarin .Forms has a version in pre-release that pre-compiles the Xaml so it will be interesting to see if that improves these results and by how much . Still, you can achieve nearly 90% code reuse using Xamarin .Forms so it should also be taken into account when selecting your mobile technology platform .

About MagenicFounded in 1995 by the same technical minds that still run the company, Magenic delivers software results on the most complex modern application projects.

Visit us at magenic.com or call us at 877.277.1044 to learn more or to engage Magenic today.

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

http://magenic.com

http://magenic.com



http://magenic.com

XAMARIN AND PHONE GAP - · PDF file/////XAMARIN AND PHONE GAP: A COMPARISON 4 // MAGENIC...

Documents

Transcript of XAMARIN AND PHONE GAP - · PDF file/////XAMARIN AND PHONE GAP: A COMPARISON 4 // MAGENIC...