Cross Platform Application Development Fundamentals with Xamarin

Xamarin, founded in 2011 by Miguel de Icaza and now owned by Microsoft, is an open source platform that allows developers to create native iOS, Android, and Windows UWP applications using the .NET framework and C#.  With Xamarin, developers have a powerful tool that can be used to deliver cross platform applications from a single codebase.  As with all tools, failure or success is based on knowledge of how best to use the tool and this applies to Xamarin.  Xamarin is very powerful and requires some fundamental knowledge to maximize the value of its design goals.

Xamarin utilizes a number of items to create cross platform applications.

  • C# Language - Allows developers to use a modern language with advanced features

  • Mono .NET framework - A cross platform version of the .NET framework

  • Visual Studio for Windows and Mac - An advanced IDE that developers use to create, build, and deploy software

  • Compiler - Produces an executable for each of the target platforms

For developers currently utilizing the C# and the .NET framework, these items should be familiar.

To access platform-specific features, Xamarin exposes SDK’s via a familiar C# syntax.  Here is a breakdown by platform:

iOS

Android

Windows

Xamarin.iOS exposes the CocoaTouch SDK as namespaces that can be referenced from C#

Xamarin.Android exposes the Android SDK as namespaces that can be referenced from C#

Windows UWP applications can only be built using Visual Studio for Windows selecting the corresponding project type.  There are namespaces available that can be referenced from C#

 

Building cross platform applications with Xamarin follow the familiar process of code, compile, and deploy.  During the compilation step for Xamarin, the C# code is converted into native applications for each target platform but the output is quite different.  For iOS, the C# code is ahead-of-time (AOT) compiled to ARM assembly language.  The .NET framework is included minus any unused classes.  For Android, the C# code is compiled to Intermediate Language (IL) and packaged with the Mono runtime with Just In Time (JIT) compilation.  As with the iOS scenario, the .NET framework is included minus any unused classes.  The Android application runs side-by-side with Java/ART (Android runtime) and interacts with native types using JNI. (Java Native Interface)  For Windows UWP, the C# code is compiled to Intermediate Language (IL) and executed by the built-in runtime.  Windows UWP applications do not use Xamarin directly.  Despite these differences, Xamarin provides a seamless experience for writing C# code that can be reused for all target platforms.

Visual Studio for Windows or Visual Studio for Mac can be used for Xamarin development.  Which IDE you choose will determine which platforms you can target with your application.  Here is a quick breakdown by IDE:

Visual Studio for Windows

Visual Studio for Mac

  • Xamarin.iOS (requires a Mac)

  • Xamarin.Android

  • Xamarin.UWP

  • Xamarin.iOS

  • Xamarin.Android

 

If your plan is to target iOS, Android, and UWP, Visual Studio for Windows is your choice for IDE but you must have access to a Mac running macOS for build and licensing. Here is a link for more information on system requirements for Xamarin.

In order to deliver cross platform applications with Xamarin that inherently support code reuse, the application architecture is a key component to success.  Following object oriented programming principles such as encapsulation, separation of concerns/responsibilities, and polymorphism can contribute positively to code reuse.  Structuring the application in layers that focus on specific concerns (i.e. data layer, data access layer, business logic layer, user interface layer) and utilizing common design patterns such as Model-View-ViewModel (MVVM) and Model-View-Controller (MVC) also support code reuse.  These concepts/patterns when used appropriately minimizes duplication and complexity, effectively organizes, and positions the code to be leveraged for multiple platforms.

Sharing code is also a key component to successfully using Xamarin to deliver cross platform applications.  There are several options for sharing code between target platforms. Shared Projects, Portable Class Libraries (PCL), and .NET Standard Libraries are the options and each have unique features which are summarized below:

Shared Projects

Portable Class Libraries(PCL)

.NET Standard Libraries

Allows code to exist in a common location that can be shared between target platforms



Allows code to exist in a common location that can be shared between target platforms



Allows code to exist in a common location that can be shared between target platforms

Shared Projects can contain platform specific code/functionality


Compiler directives are used to include/exclude platform-specific functionality for each platform target

PCL’s cannot contain any platform-specific code

PCL’s have a profile that describes which features are supported (the broader the profile the smaller the number of available features)

.NET Standard Libraries cannot contain any platform-specific code

.NET Standard Libraries have a larger number of available features than PCL’s

.NET Standard Libraries have a uniform API for all .NET platforms supported by the version of the library

During the build process, the code in the shared project is included in each of the platform target assemblies (there is no output assembly for the shared project)

PCL’s are referenced by other projects and there is an output assembly after the build

.NET Standard Libraries are referenced by other projects and there is an output assembly after the build

More Shared Project information

More PCL information

More .NET Standard information

Microsoft released .NET Standard 2.0 in late 2017.  In this release, the number of API’s supported increased by over 20,000 from the previous version (1.6) of the .NET Standard.  This increase allows developers to place even more code into reusable libraries.  The .NET Standard 2.0 is supported by the following .NET implementations:

  • .NET Core 2.0

  • .NET Framework 4.6.1

  • Mono 5.4

  • Xamarin.iOS 10.14

  • Xamarin.Mac 3.8

  • Xamarin.Android 8.0

  • Universal Windows Platform 10.0.16299

As you can see by the list, if your goal is maximum code reuse and your platform targets are supported by the .NET Standard 2.0, a .NET Standard 2.0 Library is where you should place all of your reusable code.  For Xamarin, having code reuse central to your software architecture design goal allows you to deliver your mobile application faster to multiple platforms.

When exploring Xamarin, make sure you spend adequate time learning and understanding these fundamental design and project organizational concepts. Understanding and using them are necessary to take full advantage of Xamarin as a tool to effectively and efficiently deliver cross platform applications.

Keep Right’in Code!

Richard

Why Unit Testing?

Throughout my career in the software development industry, unit testing has been a practice that I have known about, somewhat understood the benefits, but never had a real opportunity to practice.  When you are a part of a small development team and you are looking for ways to deliver value to your customers more quickly, skipping unit testing “feels” like you are doing the right thing.  But if your project becomes more successful, more complicated, and your team grows, not having unit tests becomes risky and costly.

Unit testing is a software testing approach by which a unit of work within your source code is tested to determine if it functions properly.  You can think of a unit (unit of work) as the smallest testable part of your code.  A unit test is code a developer creates to test a unit.  It is basically code written to test code.  For example, let’s say some code has a function that accepts an array of numbers and returns the sum of the values.  Several unit tests (code) can be written to test the function by providing arrays of known values as input and comparing the result to the known sum of the of the values in the input array.  If the sum returned by the function matches the known sum, the unit test passes.  So big deal, the function can correctly calculate the sum of the values in an input array.  What’s the value in creating unit tests for that?  

Well let’s expand our thinking for a moment.  You have an idea that might improve the efficiency of the function by 10x and it requires that you refactor how the function sums the values of the input array.  Let’s make this a little more interesting and assume you are not the original author of the function and the output of the function should be the same as before your refactor.  Without unit tests in place, how do you determine if the function is still working correctly after your refactor? In this scenario is where unit testing adds tremendous value.

There are a couple of items in this scenario that contribute to increased risk and cost.  All non-trivial applications/libraries will have code refactored at some point which introduces risk.  Without unit testing, the only way to ensure that code continues to function correctly after refactoring is to perform manual testing and in some scenarios the code that was refactored can only be tested indirectly as a part of a larger operation.  This leads to increased cost because resources (developers/testers) have to be allocated to a manual testing effort and human resources are the most expensive part of any business.  In addition, this manual testing effort requires time which delays the delivery of value to the end users.

Returning to our scenario, let’s assume there were unit tests available and the tests were setup to execute as a part of the build process.  After the refactor, you rebuild the code which kicks off the execution of the unit tests.  Almost instantaneously you will get feedback on your code changes.  Assuming that the unit tests are correctly testing the function (big assumption) and the unit tests are still passing after your refactor, you can be fairly confident that you have not introduced errors.  This does not eliminate the need for all manual testing but it is safe to conclude that the manual testing efforts can be minimized and the unit testing has reduced, not eliminated, risks and cost.

Based on my view of the software development world, I would say that most development shops do not actively use unit testing as a tool to mitigate risk and cost.  To the inexperienced, unit testing is overhead in the software development process that can be eliminated to deliver value to users faster.  But what happens when the “overhead” is eliminated for years, the project has become more complicated, and more software developers have been added or experienced developer have departed.  The result: a huge amount of risk to the project when changes are made, increased cost in time to test, and delayed delivery of value to the end users - a mountain of technical debt.  Unit testing is a tool, if used properly, to help teams of all sizes be more efficient and minimize technical debt.  It should not be viewed as “overhead” or a barrier to delivering value to the end users.

If you are developing software using the .NET (Microsoft) technology stack, there are several unit testing frameworks available.  The most popular are Microsoft Unit Testing Framework for Managed Code (MSTest), NUnit, and xUnit.Net.  All get the job done and warrant evaluation if you are considering adding unit testing to your project.

Unit testing is a tool and with all tools they can cause problems if not used properly.  But when used properly, unit testing is a powerful tool in the tool chest.  If you are starting a new project or supporting a legacy codebase, unit testing should be in your tool belt to help minimize risk and cost while delivering value to your end users.

Keep Right’in Code!
Richard

Why Choose Xamarin?

Today there are many options to choose from when building a mobile application.  What’s clear is that if you do not support both iOS and Android at a minimum, you run the risk of alienating potential users.  Many organizations have mitigated that risk by investing heavily in creating multiple teams that have different skills and use different tools to deliver applications targeted for the various mobile platforms.  For some, that investment may seem like a duplication of effort and potentially presents an opportunity to consolidate and reduce costs.  Again there are several options to consider when evaluating this opportunity but if your organization has a current investment in the .NET (Microsoft) framework using C#, Xamarin could be a solution that allows you to leverage that investment to extend the value your organization creates into the mobile space.

Xamarin, founded in 2011 by Miguel de Icaza and now owned by Microsoft, is an open source platform that allows developers to create native iOS, Android, and Windows applications using the .NET framework and C#.  For organizations/teams that currently develop using the .NET framework, this is very familiar territory because Xamarin is fully integrated into Visual Studio and Visual Studio for Mac which are core development tools in this space.  So if you are looking to leverage existing .NET/C# skills, the Xamarin story starts to become compelling; but there is more....

Developers have a myriad of options when creating software to solve problems.  Without guidance and experience, they can get into trouble really quickly.  Of all the guidance available (and there is plenty), there are two things that I consider paramount for success as a developer; 1 - Keep things simple, 2 - Don’t repeat yourself (DRY which contributes to #1).  Code reuse should be a top priority when developing production software.  

Because the Xamarin platform utilizes the .NET framework, there are some tools, cross platform capabilities, and code reuse strategies available that enhances the Xamarin story.  For example, C# is used to create applications with the Xamarin platform and the language provides features that can be leveraged with intentional design to achieve code reuse. (i.e. class inheritance, generics, etc.)  Also, the .NET framework supports Shared Projects, Portable Class Libraries (PCL), and .NET Standard Libraries.  Placing core business logic in those project/libraries, allows them to be used in solutions for all .NET framework target platforms including those supported by Xamarin.  For example, one could have core business calculations or operations in a Shared Project, PCL, or .NET Standard Library and reuse that code for windows, web, and Xamarin applications.  Here is a quick break down of the features/options for the project/library types:

Shared Projects

Portable Class Libraries(PCL)

NET Standard Libraries

Allows code to exist in a common location that can be shared between target platforms Allows code to exist in a common location that can be shared between target platforms Allows code to exist in a common location that can be shared between target platforms
Compiler directives are used to include/exclude platform-specific functionality located in the code

PCL’s cannot contain any platform-specific code

PCL’s have a profile that describes which features are supported (the broader the profile, more selected platform targets, the smaller number of available features)

.NET Standard Libraries cannot contain any platform-specific code

.NET Standard Libraries have a larger number of available features than PCL’s

.NET Standard Libraries have a uniform API for all .NET platforms supported by the version of the library

During the build process, the code in the shared project is included in each platform target assemblies. (there is no output assembly for a shared project) PCL’s are referenced by other projects and there is an output assembly after the build .NET Standard Libraries are referenced by other projects and there is an output assembly after the build
More Shared Project information More PCL information More .NET Standard information

 

Microsoft released .NET Standard 2.0 in late 2017.  In this release, the number of API’s supported increased by over 20,000 from the previous version (1.6) of the .NET Standard.  This increase allows developers to place even more code into reusable libraries.  The .NET Standard 2.0 is supported by the following .NET implementations:

  • .NET Core 2.0

  • .NET Framework 4.6.1

  • Mono 5.4

  • Xamarin.iOS 10.14

  • Xamarin.Mac 3.8

  • Xamarin.Android 8.0

  • Universal Windows Platform 10.0.16299

As you can see by the list, if your goal is maximum code reuse and your platform targets are supported by the .NET Standard 2.0, a .NET Standard 2.0 Library is where you should place all of your reusable code.  For Xamarin, having code reuse central to your software architecture design goal allows you to deliver your mobile application faster to multiple platforms, but there is more...

What if you could take code reuse to the user interface?  Well, you can with Xamarin Forms.  Xamarin Forms allows developers to build native user interfaces for iOS, Android, and Windows using C# and XAML.  Developers use abstractions of user interface controls to construct the user interface and at compile time those abstractions are converted to native user interface elements. By connecting a Xamarin Forms user interface with shared backend code, developers can build a fully native iOS, Android, and Windows application from a single code base and depending on the application and technical design, can achieve over 96% code reuse.

Until now we have covered all the advantages to using Xamarin for cross platform mobile development but what are the disadvantages?  I have been using Xamarin for about a year.  My largest hurdle has been learning about developing for the target platforms and their requirements.  This is not a disadvantage of Xamarin but a entry cost to anyone new to mobile development and selecting any tool would require paying this cost.  So, I would say that Xamarin can be used for most mobile applications.  Unless your application requires use of specific platform features or special hardware, Xamarin is real compelling option for delivering mobile applications on multiple platforms and a potential cost saver if your organization/team already has .NET framework and C# skills.

Keep Right’in Code!

Richard