Xamarin Evolve 2013

Evolve is the first conference organized by Xamarin, the provider of the cross-platform tool that we use for developing the Android CAPI client.  It consisted of two days of training and two days of conference talks.  The training was given by Xamarin staff.  Xamarin has 70 staff, including many who work on documentation.  The training was very well prepared with documentation and sample apps.  Most talks throughout the conference focused on cross-platform app development - iOS, Android, and to a lesser extend Windows 8.

It was a constant theme throughout the various talks that apps should be well-designed so that they can share code effectively and be testable.  This means using MVVM and file linking.

MVVM - Scott Hanselman summarized that startup code and View should be platform-specific, ViewModels, Models and platform-abstractions should be shared and fully tested.  Many people recommended MvvmCross.

Xamarin Studio supports Portable Class Libraries (PCL), but Xamarin for Visual Studio doesn’t yet.  But it seemed to be a consensus that file linking is preferable to using PCL’s because:

• PCL is the lowest common denominator of the shared platforms
• There’s isn’t a PCL profile for Xamarin (there will be sometime, and there are hacks available now)
• You can use compiler directives when sharing with file linking (although these should be minimal, for example some using directives)
• File linking is easy with the Project Linker plugin for Visual Studio
• It’s good practise to keep the same project structure across all shared projects, and to make any platform-specific code obvious

Testing was covered in many talks since a good architecture allows for proper testing which makes quality apps.  One talk specifically about testing was from Greg Shackles in which he talked about the testing pyramid.

NUnit (Lite) runs on all platforms.  There should be a test project for each platform (again using code linking).  It’s important to run on all platforms using tools such as Touch.Unit for iOS and Android.Unit or NUnitLite.MonoDroid for Android.  Note that mocking doesn’t work on iOS because of the Apple architecture, so you need to write “manual mocks” (Greg wrote a Muntz - T4 template to generate mocks).

One of the big announcements at the keynote was that Xamarin have acquired LessPainful.  This is the tool that we’ve been using for automated UI testing.  With the massive amount of extra resources from Xamarin this should improve dramatically.  The other big announcements at the keynote were support for .Net 5.0, support for F#, and an iOS GUI designer.  With these major projects out of the way, the next big focus will be on the Test Cloud.

Karl from LessPainful (now Xamarin) gave a presentation about Calabash.  He told that Calabash is about automation, not necessarily Gherkin.  Calabash for Android is based on Robotium and it communicates with JSON over HTTP so it would be easy to make another client instead of Ruby/Gherkin.  They’ve already made a prototype C# client, but it won’t be released for at least a few months because of all the stuff that goes with it (documentation).  He said that having managers (or functional analysts) writing Gherkin tests doesn’t work, but the tests should be readable by everyone.

Features, steps, page interfaces can be cross-platform.  Page implementations will be platform-specific.

There were also a few talks about garbage collection by some of the Xamarin developers that wrote the garbage collector.  The main things to remember about garbage collection are:

• There are two garbage collectors - the native one and the Mono one
• Set references to null or use weak references to allow the garbage collector to clean up
• Avoid cross-heap references (for example extend BaseAdapter instead of using an ArrayAdapter)
• Call Dispose to explicitly allow garbage collection (this collects the managed code - the native code runs in its own lifecycle)
• Always remove event handlers when we’re done with them (for example if added in OnResume then remove in OnPause)
• Some native objects are stored as a pointer and a backing object.  So, for example, when analyzing memory allocation you will see a bitmap reference but not the backing bitmap.  The operating system may perform it’s own optimizations with the backing data.

The garbage collector has two generations: nursery and major.  There is also the Large Object Space (LOS).  The garbage collector runs every time an object is allocated (and at no other time).  The nursery is small and limited.  The major is only limited by the physical constraints of the device.  When a small (<8kb) object is allocated it is put in the nursery.  If there’s no space then nursery is collected and objects are moved to major.  When a large object is allocated it goes straight to major.  It is cheap to allocate small, short-lived objects.  You should avoid allocating large, short-lived objects.

Evolve was a very well-organized and informative conference.  It was good to see the best practises that make for good quality cross-platform apps.