In last week’s post I described why it is time for native app developers to double back and take a look at C# / .NET based code for their native app platform needs in iOS, Android, and Windows 10.
There are three topics that require an even deeper look, however: app performance, other language considerations and samples of the catalog that we used in our solutions. These topics are covered in more detail below.
App Performance
But what about overall app performance when using alternate .NET runtimes on mobile platforms?
Surely Xamarin / C# / .NET runtime performance across all these platforms has to be slow. All of this Xamarin stuff is ‘yet another layer of indirection’ and that means ‘slow’, right?
For so many mobile apps pure UI speed is a key to the business. You need that speed.
My experience has primarily been with Xamarin.iOS and other pure native languages (Objective-C and Swift) on the Apple iOS platform.
Xamarin.iOS is a shim library that wraps access to the CocoaTouch / UIKit API surface.
In a third party performance metrics performed by Harry Cheung (https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9#.5094nldju) it appears as if Xamarin.iOS performance for similar tasks is roughly at the same levels as the performance of the Swift runtime on iOS.
To truly address mobile app performance, we probably need yet another blog post that focuses on what key things your app does. Is it a game? Is it a line of business app? All the way down to questions like: What can be thrown to the background? What calls can you optimize against UIKit within your app? Are you willing to sacrifice a few milliseconds of background time to use System.Xml.Linq to parse that XML instead of using the pure SAX NSXMLParser?
The great thing is that you need to ask these exact same core performance questions if you are using Obj-C / Swift / UIKit or C# / Xamarin.iOS.
In my experience I have found that Xamarin / C# / .NET really is no greater a barrier to your app performance than the true API, and supporting runtimes, offered up by Apple and Google for most data presentation apps. It has been my experience (especially on iOS) that the Xamarin supported API wrapper is actually quite thin and doesn’t get in the way of your app performance for the vast majority of applications out there.
What about other languages? VB.NET or F#?
My emphasis has been the use of the C# language across multiple platforms. VB.NET and F# code can be used in the form of a portable library built using Visual Studio 2015 and running on .NET Core and Mono runtimes on mobile platforms. Unfortunately, Xamarin doesn’t support anything other than C# for UI application projects that use MonoDroid and Xamarin.iOS.
Sample Catalog
In our projects, we made heavy use of widely available portable assemblies off of NuGet or GitHub. Below is a sample of the catalog that we used in our solution:
Microsoft.Net.Http
NuGet – https://www.nuget.org/packages/Microsoft.Net.Http/
This is a Microsoft supported library that provides the HttpClient object hierarchy available on WinRT nearly intact as a portable library that works across iOS, Android, and all Windows variants.
In all honesty, this is a great starter package to get fully cross-platform HTTP access. For more advanced HTTP functionality, you may need to write your own HTTP access library against the native API on each platform. Then you can use dependency injection (maybe via TinyIoC) in your portable code that needs network access. In my experience, Microsoft.Net.Http provided 99% of everything we needed for network access.
Newtonsoft JSON.NET
NuGet – https://www.nuget.org/packages/Newtonsoft.Json/
JSON.NET has been a staple of C# development for a while. On this project we were able to triple purpose a set of POCOs (Plain Old CLR Objects) for JSON serialization, JSON deserialization, and as entities for a business object layer.
JSON.NET coupled with async / await and Microsoft.Net.HTTP to load JSON from web servers via HTTP / HTTPS allowed us to create a fully async app (with no major UI blocking) in way less time than it may have taken on one platform, much less the final single code base, cross-platform result on Android, iOS, and Windows 10.
Bouncy Castle
NuGet – https://www.nuget.org/packages/Portable.BouncyCastle/
Bouncy Castle filled in cryptographic gaps from the .NET runtime and allowed us to standardize the code used for encryption / decryption of OpenID user tokens used for a login process.
Bouncy Castle when coupled with our own web access and logic layers allowed us to create a single set of code to handle OpenID / JWT based user logins across Android, iOS, and Windows 10.
TinyIoC
NuGet and GitHub – https://github.com/grumpydev/TinyIoC
TinyIoC, coupled with the standard language features in C#, allowed us to create business logic with an easy to use inversion of control / dependency injection pattern.
TinyIoC gave us full cross-platform support for IoC across a fully shared business logic layer across iOS, Android, and Windows 10.
There were times where we needed to inject some platform specific logic. Having TinyIoC allowed us to inject those per-platform dependencies without taking on any massive per-platform dependencies into our core shared business logic.
Microsoft ASP.NET SignalR Client
NuGet – https://www.nuget.org/packages/Microsoft.AspNet.SignalR.Client.Portable/
Our server side already had a series of streaming services exposed via SignalR. With one code base that used the portable SignalR client we were able to add single code base, cross platform, data streaming to our Android, iOS, and Windows 10 applications.
Super Development 
Leave a Comment