Time flies! The second day of training at Xamarin Evolve is over already and I just came back from the awesome opening party in the Darwin Lounge.
The main conference starts tomorrow. I’m honored to be on stage with some industry giants at the Evolve Mobile Leaders Summit track in a panel discussion about The Unique Challenges of Mobile DevOps. But that’s tomorrow!
About today: before the training, the day started at 6:15am (!) with a 5k test run with for the first Mini-Hack tomorrow morning. I spot an orange Xpirit T-shirt 🙂
The training part was another intense day from 9am-6pm, but it was a good day. I’d say the content of today was a bit better and deeper than what we learned yesterday, at least for me personally. We covered three major topics:
Securing local data
This part was all about dealing with data locally on the device, especially sensitive data in terms of privacy and security. We had a look at what the Xamarin.Auth component has to offer for local storage of sensitive data. This component (you can find it on GitHub and on Nuget) uses the platform specific facilities for storing data in a secure container, i.e. the KeyChain on iOS and a secure KeyStore inside the app’s sandbox on Android.
Be sure to get the latest 1.3.0 version of the Xamarin.Auth component though, as this is a bait-and-switch PCL library that also offers support for the Windows platform, whereas the older 1.2.x version doesn’t.
There’s one caveat with the Xamarin.Auth component though… The KeyStore file on Android is locked with a hard coded password. The Android app in one of my previous projects was actually flagged in a security audit because they extracted the Xamarin.Auth DLL, decompiled it and found the hard coded key. Pretty iffy, because this means that the KeyStore data in every app that uses this library can be easily opened and read by extracting the file from the sandbox and using the key that’s publicly available on GitHub!
I made a pull request about 2 years ago that fixes this problem, at least in a way that you can provide your own key. But somehow Xamarin didn’t get around to merge it yet, so the vulnerability was still there, also in the 1.3.x version. The funny thing was that as we were doing the training, one of the Xamarin developers was actively working on this component. We pulled him into the training, explained the problem and he immediately went to work to see if he could merge my fix. How awesome!
The other part of this chapter was about the awesome PCL.Crypto component. This component is also a bait-and-switch PCL library, which means that the PCL portion contains nothing more than the API definitions for your shared code to compile against (the bait), but uses the actual device specific implementation at runtime (the switch). This means that PCL.Crypto can use the platform specific crypto API’s developed by Google, Apple and Microsoft themselves instead of relying on its own security implementation. Much the same as the Xamarin.Auth component solves its local storage issues. For developers familiar with the WinRT crypt API’s for example, there is a special WinRTCrypto API that you can program against, but PCL.Crypto will map this to the underlying native API’s. Pretty clever. For example: a method for encrypting some data could look like this:
public static byte[] Encrypt (byte[] plainText, byte[] keyMaterial)
{
var provider = WinRTCrypto.SymmetricKeyAlgorithmProvider
.OpenAlgorithm(SymmetricAlgorithm.AesCbcPkcs7);
var key = provider.CreateSymmetricKey(keyMaterial);
var IV = WinRTCrypto.CryptographicBuffer.GenerateRandom(16);
var cipher = WinRTCrypto.CryptographicEngine.Encrypt(key, plainText, IV);
var cipherText = new byte[IV.Length + cipher.Length];
IV.CopyTo(cipherText, 0);
cipher.CopyTo(cipherText, IV.Length);
return cipherText;
}
PCL.Crypto can be used quite easily in combination with Xamarin.Auth to encrypt or hash data before storing it. At least as long as your app is using the not-so-secure version of Xamarin.Auth – with the hard coded key – using something like PCL.Crypto to secure the values that go into the secure storage is a real necessity! But it’s good practice to do it anyway.
OAuth
Next we went into OAuth for authorizing access to an API from a mobile app. OAuth in itself is a pretty broad topic and enough to fill tens of blogposts. One of the important points here is that for mobile apps, basically there are only two OAuth flows that are really usable:
The Implicit flow or the Authorization Code flow. The other flows aren’t really suitable for mobile apps (or browser apps involving JavaScript code), since this means that there will be client secrets hidden inside the app, and they involve dealing with a user’s password in the app itself instead of handing that off to an Identity Provider. The Client Credentials flow is typically used for service-to-service communication, usually on behalf of the user.
Xamarin.Auth provides some nice API’s to easily initiate a login sequence, using a web view that follows all the redirects that are part of the OAuth flow, to obtain an access token (or authorization code).
Memory Management Issues
The most interesting part of today was about diagnosing and dealing with Memory Management Issues. I actually learned a lot about how both the Xamarin.iOS and Xamarin.Android frameworks work in terms of memory allocation. It’s important to understand that in both cases, you are always dealing with native objects, managed peers and a binding layer in between, provided by Xamarin. At least, for those objects that are actual native platform classes.
Under the hood, there are some intricacies to be aware of. For example: in order for iOS’s reference counting mechanism to work, you have to be very careful to release references to native objects, for example by making sure to always unsubscribe from event handlers. For Android, it’s important to realise that you’re working with two Garbage Collectors: the Mono one and the one in the Android Java VM. There are a lot of details, but there is some nice guidance up on the Xamarin Developer site about this [iOS] [Android].
You can prevent a lot of memory issues by following a couple of important guidelines. Also the Xamarin Profiler is a great tool for diagnosing possible memory leaks.
Darwin Lounge
As for the (other) fun part of Evolve: the Darwin Lounge was opened this evening, accompanied by a huge buffet and a nice range of tasting stands for artisanal chocolate, local beers and hipster coffee 🙂 This tweet sums up how I felt this evening:
It’s no secret that I’m an avid foodie, so suffice to say that I was in seventh heaven when it comes to the food that was served here. This means that you have to sit through my Instagram food porn pictures now:
So… Xamarin sure knows how to throw a party 🙂 Of course, the Darwin Lounge at Evolve is mainly about cool geek stuff and tech inspiration. There’s lots of that going on as well. Lots of IoT stuff, drones flying around, etcetera. Check out the Twitter timeline for #XamarinEvolve for a great impression of the fun things out there.
Be sure to tune into the Evolve keynote tomorrow at 9am EST. Rumours are that it’ll be spectacular! 😉
The mobile chef 
[…] Training Day 2 […]