0 comments
Various 
Hi there from Orlando, FL! Yesterday was the first day of the Xamarin Evolve 16 pre-conference training. And man, we’re already having a blast here. Evolve 16 is even bigger than the previous one, and on the pre-conf training alone, there are more people than there were at the original, legendary Evolve 2013; in total! Impressive.
My mobile peer at Xpirit, Geert and I arrived on Saturday, together with a bunch of fellow Dutchies including some of my former colleagues from Info Support. It’s nice to catch up and hang out.
In the training, we’re doing the Intermediate track, which offers some more advanced topics. I have to say that most of the topics are already familiar, but for us this is also a great opportunity to get to know the Xamarin University material. We’re working towards certifying ourselves for delivering the official Xamarin University training curriculum at Xpirit to be the first Dutch Xamarin Training Partner! How awesome is that? Stay tuned for more news!
The main topics we covered were:
Asynchronous programming with async/await
For this module we dove into the mechanics behind the Task Parallel Library in .NET and the async/await keywords. This stuff is so important to get right as it’s crucial for quality apps to make sure that you’re not wasting the main UI thread by doing expensive work like heavy CPU-bound work or (network) I/O. The course went into some of the mechanics of async/await – with the compiler generated state machine that ends up in the generated IL.
The problem with async/await is that the syntactic sugar makes it almost too easy to make work inside your app asynchronous. The point is that making things asynchronous isn’t always necessary and using async/await the wrong way may actually hurt the app in the sense of complexity and possibly performance more than it helps. Understanding the state machine that the compiler generates, the effects of ConfigureAwait(false), working with the Dispatcher, etcetera is crucial if you want your apps to be responsive.
Patterns for reuse
A topic that’s dear to my heart. Marcel and I actually did a pretty popular talk about it at Evolve 2013. IMO, this stuff all still holds true, however we have progressed a bit when it comes to the maturity of the Xamarin platform. With the advent of Xamarin.Forms, more and more code sharing techniques are possible and go right up to the top UI level. On the other hand, Xamarin.Forms already takes away a lot of the hard work of bridging platforms. Very nice, but – my pet peeve – beware of the abstractions!
It all comes down to keeping things as simple as possible. In the training, we talked through using the Factory and Service Locator patterns, but our common conclusion was that they involve a fair amount of Yak Shaving.
In the end, Dependency Injection is a relatively clean way of dealing with dependencies that have per platform implementations. In my experience, using a light weight DI container like SimpleIoC is sufficient for most apps. Let’s be honest, in an average app, you don’t really need much sophisticated lifetime management or other things. You just want to be able to swap in per platform implementations of some components to use them from shared code. But before you start building your own components, head over to Xamarin’s plugin repo on GitHub because a lot of plugins are already available. And they generally use DI to set up.
Testing
We talked about the techniques that are at our disposal for validating the quality of your app. Of course using unit tests should be a no-brainer to developers, and there are actually some nice scenarios for testing the behaviour of your ViewModels and other logic in your app. These unit tests, being independent and mostly having their dependencies stubbed (another advantage of using DI is that it makes stubbing a bit easier), can give you the quickest feedback during your development cycle.
But an important part of your app will be the UI and that actually runs on the device. This has always been hard to test and we had a look at what Xamarin Test Cloud has to offer and the UITest API’s that you use to drive those tests. In a recent talk, I used this test pyramid diagram to show the stack I like to use for testing mobile apps:
Note that I still think that there will always be a certain amount of manual testing involved for the more complex cases. And specifically those cases where you want to check the behaviour of your app under different circumstances, such as actually being on the move through tunnels or other low connection situations, or being out in the field to make actual pictures with the camera. Manual field tests by the team and beta test platforms like HockeyApp, Apple TestFlight and Google Play Beta are excellent tools for this.
After the training it was time for some relaxation at LaFayette’s. Excellent food and great Southern style live music, and all the familiar faces from the Xamarin community there. Great to see everyone again! Really looking forward to the next few days!
To infinity, and beyond!
On Sunday, we had some spare time, so we spent the day at the NASA Kennedy Space Center. Wow what an amazing trip! It was incredible to see the huge rockets, it’s impossible to fathom how big they are until you see them. The same goes for the Space Shuttle. The Atlantis Space Shuttle is on display and you can see it up close. Super cool!
The biggest surprise came when we went on the bus tour to the actual launch site. Again, it’s impossible to fathom the scale of the site and the equipment there that’s used for space travel. At the end we got a great show about the Apollo missions. The actual control center used for the Apollo mission is there on display. And then there’s the overwhelming and HUGE replica of the Apollo rocket.
And the coolest thing was: our Uber driver who took us back to the hotel was an engineer on the Space Shuttles for 30 years! So he could give us some fun behind-the-scenes insights. Did you know for example that there was an actual Coca Cola machine installed in one of the shuttles? That was to test the effects of carbonation in space. But since Coca Cola is a commercial company, NASA was not allowed to talk about that
Oh and don’t you just love these vintage posters?
