I’ve updated my previous post “The many flavors of HttpClient” with current information on everything you need to know about HttpClient on Xamarin.
I’ve updated my previous post “The many flavors of HttpClient” with current information on everything you need to know about HttpClient on Xamarin.
I co-authored a blog post with my co-worker Robin Wiegand on bringing Xamarin and Cordova together. Enjoy!
When using Xamarin, you can use the standard .NET
HttpClient. By default, HttpClient is Mono’s complete reimplementation of the entire HTTP stack. It is sufficient for many use cases but there are other alternatives out there that can be defined by selecting an alternative
HttpClientHandler. For my Evolve talk, I put together an overview of the different HttpClientHandlers you can use:
CFNetworkHandler (iOS 6+) and the new
NSUrlSessionHandler (iOS 7+, starting with Xamarin.iOS 9.8) are the handlers that utilize Apple’s native APIs instead of the Mono implementation. You can define which handler the
HttpClient default constructor will use either in the IDE or by providing an argument to
For Android, there is now
AndroidClientHandler (starting with Xamarin.Android 6.1). There is no IDE option for defining the default handler yet but you can define it using the
@(AndroidEnvironment) build action on a text file in your Android project to define an environment variable
XA_HTTP_CLIENT_HANDLER_TYPE to the value
Alternatively, you can use ModernHttpClient by handing a
NativeMessageHandler to the HttpClient constructor which will also use native implementations for making HTTP calls.
The default Mono implementation does not support the newest (and most secure) TLS standard 1.2 while the native handlers do. To use TLS 1.2 with the Mono implementation, Xamarin.iOS 9.8 introduced the option to swap the TLS implementation with P/Invoke calls into the Apple’s TLS implementation. This can be selected either in the IDE or by adding the
--tls-provider=appletls option to
For Android, there is no such option but it is expected that
BoringSSL support will be added soon.
Here’s the summary slide I showed in my talk:
Xamarin have actually gone through the trouble of reimplementing the TLS code to support TLS 1.1 and 1.2. However, it is expected that it will be abandoned because of security considerations in favor of the native platform implementations, just as Microsoft has done for Windows.
Here’s an update on the current state of
AndroidClientHandleryour Android project’s properties page, just as you already could for iOS.
BoringSSLinto their codebase. For Android, this option is also selectable in your project’s properties page.
BoringSSLalso brings TLS 1.2 to the Unix/Linux implementations of Mono.
ServicePointManager. Thomas Bandt wrote an excellent blog post on how to get certificate pinning working with ModernHttpClient and even
And here’s the updated matrix:
On April 1, 2016, I was awarded the Microsoft MVP status for “Visual Studio and Development Technologies”. It is an incredible honor for me and I am still a little in shock. Already, I’m seeing new information pour in and new connections being made and I am really excited about the road ahead.
The shocking part for me was that I had concentrated my community work almost entirely on Xamarin technology. In October 2015, a change in the MVP program categories meant Xamarin was now one of the award category technologies (hey, even Java is on that list!).
I was nominated by Microsoft Technical Evangelist Daniel Meixner at the end of 2015 (thank you very much!), then there was a review, and apparently, my contributions were sufficient for the award committee.
I don’t plan on decreasing my efforts in 2016. I contributed to the MvvmCross 4.0 release at the beginning of the year, I’ve already done two public presentations, and I’ve found the time to blog. With Xamarin Evolve around the corner (where I’ll also be speaking) I’m anxious to find out which direction Xamarin and now Microsoft are going to take the cross-platform adventure we’re on. The announcements at Build made me very happy, personally, and I’m looking forward to sharing the knowledge with more people.
If you want to hear one of my presentations, keep an eye on my public speaking list where I’ll also be posting links to any videos or slides in case you missed the talk.
Above all, many thanks to my employer Zühlke who is supporting my community activity with time and money!
The Xamarin platform allows developing iOS and Android applications entirely in C#. Sometimes, however, some legacy code may be too large or complex to make porting it to C# for your mobile app worthwhile. Most examples found online show you how to use existing Objective-C libraries in Xamarin.iOS and existing Java libraries in Xamarin.Android. However, it is entirely possible to call C code from a Xamarin app. Microsoft’s recent support for C/C++ on iOS and Android in Visual Studio can make this a simple task.
You will need the sources for the code you want to call to compile it for iOS and Android. The code cannot access any libraries which you only have binaries for that have been compiled for other platforms.
To get started, create a new C++ cross-platform project using Visual Studio 2015.
You will need to have the corresponding Visual Studio package installed to have this option available.
This will create three projects: one for Android, one for iOS, and a shared project.
It is important to understand the shared project concept for this. The code in the shared project does not result in a DLL or library being generated. A shared project can hold any type of file. Projects referencing the shared project can access code from any file in the shared project. The code will then be compiled in the context of the referencing project. If code is not referenced, it is not compiled. For this reason, it is necessary to have calls into all code needed contained in the platform-specific projects. This means that the platform-specific C/C++ projects need to contain code, too. This code can be identical in the Android and iOS projects and reside in the same files. Unlike in .NET projects, file linking is not needed for C++ projects; source code files do not have to reside inside a project’s folder or subfolder.
In the example, I’ve created a simple function
clib_add_internal() that add two integers and resides in the shared project.
This code is called from a function in the platform-specific projects.
For the example code, this doesn’t make any sense. For a real project, you will put any call that needs to be directly invoked from the .NET code (your interface) into the platform-specific projects while underlying code can reside in the shared project.
The calls from .NET will be using P/Invoke since C++/CLI is not available on iOS or Android. So the basic P/Invoke rules apply for your interface’s code: Either the code is plain C or, if you are using C++, the calls are either plain functions or static methods and contain only POC parameters and return values.
For the iOS project, the output format needs to be changed to a static library (.a file) since iOS does not allow dynamically loading code. For Android, a dynamic library (.so) should be built.
While the Android library can be compiled within Visual Studio, compiling the iOS library needs a connection to a build agent on the Mac. This is not the regular Xamarin.iOS installation on a Mac but a Microsoft tool that is installed on OS X using npm. Visual Studio will communicate with this tool through TCP/IP.
To call the native code, create a Xamarin project for iOS and Android each. Include the native libraries in the respective Xamarin projects.
On iOS, if you’re targeting multiple processor architectures (either supporting pre-iPhone 5s or supporting the simulator), you can build the iOS project for multiple platforms using the dropdown in the toolbar. Then, combine the libraries into one using
lipo according the Xamarin docs. On Android, you’ll need to modify the
.csproj according to the Xamarin documentation to specify the
.so files for each platform.
The calls into the native code are regular P/Invoke calls (although DLLs don’t play a role here). On Android, you specify the name of the shared library.
On iOS, use the special Mono name
__Internal to call into the static library.
And that’s it! You can find the example code at https://github.com/lothrop/XamarinNative. In the example, I put the C# marshaling code into another shared project that is referenced by the Xamarin.iOS and Xamarin.Android projects.
When using MvvmCross in a cross-platform mobile project you have the choice of four different approaches for creating the iOS user interface. Xamarin.Forms is one of those approaches that can be a good choice for many use cases (even if there is not graphical designer at this point). However, if your view has very specific visual requirements, it may be necessary to create a native view. There are three different ways you can do this:
MvvmCross supports all three native approaches.
This approach obviously produces the most code. It may be challenging for people new to the platform but it saves you the hassle of battling with the UI designers.
If you’re already on Xamarin 4 and prefer a visual editor, this is likely the best choice for you. Create a new XIB View Controller file using Xamarin Studio or Visual Studio. The ViewController code will also be created for you. All you need to do for MvvmCross is to change the base class from
MvxViewController. In the example, three UI elements were created using the designer and were given the (not so creative) names
UiButton. These elements are then referenced in the data binding code that is common to all three approaches.
The big advantage of storyboards, the ability to design your screenflow in the designer, does not fit well with MvvmCross’s cross-platform navigation approach. If you define a transition from view A to view B in the designer it will only apply to the iOS platform. It is typically a better idea to move this navigation logic down into the cross-platform code inside your ViewModels. That is why it’s best to use a one-ViewController-per-storyboard approach when using storyboards in MvvmCross.
In the editor, you need to set the storyboard ID to the name of your ViewController. As with the XIB approach, change the base class from
MvxViewController. Create a constructor taking an
IntPtr and passing that on to the base class’s constructor. The last step is to add the
[MvxFromStoryboard] attribute to the class.
The good thing is: You don’t have to make this decision at project start. MvvmCross supports implementing your view with the technology that is best for each view. You only need to ensure you don’t have multiple views for the same ViewModel and the same platform.
I’ve updated the example in the MvvmCross Starter Pack Nuget (starting with 4.0.0-beta8) to use a XIB file instead of the previous hand-coded approach with absolute coordinates (from the auto layout days). That should make it easier for people to get started.
If you’re using iOS auto layout (you should) and you’ve ever tried to add a scroll view in Interface Builder or the Xamarin iOS Designer you might have noticed that it is not an easy task. If you’re interested, here are some instructions. This is especially true if you only realize that you need a scroll view after designing your view (after you’ve realized that the keyboard covers up parts of the view).
Here’s code to inject a
UIScrollView at runtime to solve all your worries. Add this code to your base
UIViewController for all controllers that should be vertically scrollable.
In Interface Builder or Xamarin iOS Designer you’ll need to make sure you’ve not only defined constraints for the vertical position of your elements but also a constraint to define the distance from the bottom of the bottom element to the bottom of the your view controller’s view. That way, you’ll have defined the vertical size of the scroll view’s content view.
Communicating securely between a mobile app and a the corresponding backend is not a trivial task. Sure, nowadays we can write https and almost be certain our app is actually having encrypted communication with the right backend. However, just recently, I decided to do a communications check of apps on my iPhone using Fiddler as a proxy and was surprised to find that I could do a man-in-the-middle attack for an app I use regularly without the app noticing this. Apparently, the developers had opted to disable certificate validation (perhaps so the app would work with a developer backend that doesn’t have a pricey SSL server certificate installed) and forgot to turn it on again before publishing the app to the store.
However, there is an even better way to solve that problem that doesn’t involve buying an SSL server certificate. It’s called certificate pinning. Instead of relying on the operating system to check the validity of the presented server certificate by looking at its list of root certification authorities (which may contain entries the user is not aware of, see Superfish) developers can instruct their https calls to only accept a specific server certificate or, better yet, only certificates issued by a specific certification authority. This is not only much safer, it also avoids the costs of buying SSL server certificates.
So there we are, we have a method to ensure our app is talking to the right backend. The trickier part, though, is ensuring that whoever is making the call to our backend is actually who we think they are (i.e., our own app).
A simple approach to this problem would be to include an SSL client certificate in all requests to the backend, using a certificate whose private key is included as part of the app bundle. The problem with this is that it’s just not possible to hide the certificate well enough in our bundle to make it impossible to extract that certificate and its private key through reverse engineering. And since all clients would be using the same certificate, having that certificate compromised means we cannot tell if it’s acutally our app that is calling the backend.
The solution to this problem is to issue individual SSL client certificates to each device that is accessing the backend.
The vendors of Mobile Device Managament (MDM) software have great solutions that do exactly that. The problem is that these solutions can only be applied to devices that are in full control of the MDM solution. That’s great for internal apps on company devices but doesn’t help at all for apps you’re distributing to others.
Here is my proposal: App store operators should include a method to create an unique SSL client certificate upon installation of the app that is signed either using a certificate (public and private key) the app creator uploads into the app store or a certificate created by the app store vendor. This would make it very easy to check on the server side if a request is coming from an app that was actually distributed through the app store (and paid for, in the case of non-free apps) by using the signing certificate’s public key.
Such a feature could also be included in cloud backends like Azure Mobile Services where one could limit requests only to genuine apps and provide the corresponding functionality the client libraries accessing the backend.
All in all, this approach would greatly increase app communication security without much effort for the app developer. Now, how to convince the app store operators?
The main purpose of Reactive Extensions (Rx) is to enable processing event streams. I set out to use Reactive Extensions for receiving data on the serial port and learned some new things.
The event does not actually contain any information on the data received, it only indicates that there is data available. Reading the data is done inside the lambda expression. Reading serial data will return a list of bytes. This list may contain a complete message or just a part of a message or even multiple messages. To handle this, I want the observable to be an
IObservable<byte>, i.e., it will produce a raw stream of bytes without any indication of where a message begins or ends. This is done through the extension method
public static IObservable<TResult> SelectMany<TSource, TResult>(this IObservable<TSource> source, Func<TSource, IEnumerable<TResult>> selector) that is used to flatten the sequence returned by the lambda.
So I now have a stream of bytes. I want these bytes to be chunked into messages. For my particular protocol, messages are separated by a special byte. Separation can be done in two ways:
Here, a new observable is created using
Observable.Create(). This observable subscribes to the byte stream, collects the data in a local collection and fires
OnNext() whenever a message delimiter is encountered.
This version uses the
Scan() operator to achieve the same thing. The output is an
IObservable<IEnumerable<byte>> that fires an
IEnumerable<byte> for every new message.
This code worked well up until the point I started attaching multiple observers to the message stream, one to process the messages and one to just dump received messages to a debug console. What happened then was that the code in the first code sample was called multiple times: once for each subscriber. This meant that each chunk of serial data was only received by one subscriber, not all subscribers. There are two possible solutions to this: Either introduce a
Subject<IEnumerable<byte>> subscribing to
serialPortSource and have consumers subscribe to the subject or use the
Publish() operator that does the work for you.
Creating a new observable that produces deserialized messages from the observable producing lists of bytes is now trivial using a simple
What remains is the question of how to use the received data in a typical workflow of sending out a message and receiving a response in return. Here is an example:
This example uses the
Replay() operator. Replay will capture all events from the observable that are fired after the call to
Connect(). After calling
Connect() the call is sent to the device at the other end of the serial connection. The second
await filters the incoming messages for the desired message (even using a filter criterion that was not known before the request was sent), adds a timeout, uses
FirstAsync() to return an observable that only returns the first element followed by
OnCompleted(), and waits for that
Replay() is capturing all messages, the following
await call on the observable should consider all answers from the target, whether they are received before or after the second call to
The ALM Days 2015 took place on March 11 and 12 in Düsseldorf. For the first time, a mobile track was conducted. My talk had the title Mobile in the Enterprise and covered the challenges you meet when developing apps for enterprise use. The video (in German) is on Channel 9 and the slides (also in German) are on Azure.
Dariusz collected the track videos in his blog (including one in English by Xamarin’s Mike James).
The final track event was a panel discussion on cross-platform development strategies with Dariusz, Jörg, Daniel, and myself.
— Kerry W. Lothrop (@kwlothrop) March 11, 2015