Xamarin Forms in Visual Studio 2017

I recently had a chance to revisit the latest state of cross-platform mobile development in Visual Studio. I haven’t been able to spend as much time as I’d have liked to have done in this area. The prospect of being able to architect a single application that can run under three different UI platforms (iOS, Android and UWP) is very compelling.

I have in the past built out applications, based on the Model-View-ViewModel separated presentation pattern, that were able to push about 75% of the code burden into shared models and view models that could drive separate WPF, Silverlight and (to a more limited extent) ASP.NET MVC UI implementations. Unfortunately, at that time Silverlight was already being regarded as a dead man walking, even for internal line-of-business apps. User interfaces are by far the least stable aspects of any application architecture, and UI technologies seem to evolve rapidly, so an architecture that can keep the UI layer as thin as possible is valuable for keeping ongoing maintenance costs in check.

Xamarin Primer

Xamarin was formed by the original creators of Mono (a cross-platform .NET CLR), and was acquired last year by Microsoft, which then quickly offered the Xamarin bits as a part of Visual Studio. Their are two versions of Xamarin “Native” (for iOS and Android), which allow for native apps on those respective platforms to be developed in C#. There is also Xamarin Forms, which is essentially a subset of UI components that can be used to build an application that can be deployed to both iOS and Android, in addition to Windows UWP “Store” apps (also on the Mac, but I’m not planning to try that). The apps are still native to each respective platform – this is not a “common-look-and-feel” proposition like you would have had back in the Java Swing/AWT days.

The Initial Xamarin Experience in Visual Studio 2017

Coming from a WPF background, I’m very familiar with XAML and MVVM, so I expected that Xamarin Forms app development would be fairly straightforward. For me there are some early annoyances and rough edges:

• The ARM version of the Android emulator is painfully slow to start, deploy and run applications.
• The x86 version of the Android emulator is faster (supposedly 10x faster - that’s not what I observed), but requires Hyper-V to be disabled and the machine rebooted, which is unfortunate because I have several other active projects that use Docker, and that requires Hyper-V to be enabled. If I’m going to be doing a lot of Xamarin work, I’m going to be rebooting a lot. I guess developers that are working on an app that uses a Docker-deployed back-end to a Xamarin Forms front end are going to need two development machines.
• The iOS emulator won’t run at all unless you own a Mac and can connect to it on your local network. This is obviously not a big deal if you’re profiting from your application or have an employer or client that can foot the bill for an expensive spare device, but I’m not going to pay the Apple premium to experiment with Xamarin apps, so I concentrate mobile testing on Android.
• After starting the Android emulator manually up-front, the empty sample project worked just fine, which was encouraging. Unfortunately, for some reason, after I closed the emulator and Visual Studio and came back to the project later on, it wouldn’t deploy to the warmed-up emulator: “… an error occurred. see full exception on logs for more details. Object reference not set to an instance of an object”. After uninstalling and reinstalling the Mobile development components in the Visual Studio installer, this went away and I was able to consistently run the app. No idea what happened there.
• I hate to see warnings in the build output, and the empty Xamarin Forms project, out-of-the-box, shows several, which is sloppy QA. The first was complaining about a System.ObjectModel reference in the Android native project (it didn’t seem to matter when I removed the reference, so that’s probably an oversight of the project template). There were also several other warnings about the version of the Android SDK: “The $(TargetFrameworkVersion) for Xamarin.Forms.Platform.Android.dll (v7.1) is greater than the $(TargetFrameworkVersion) for your project (v6.0). You need to increase the $(TargetFrameworkVersion) for your project”. This is weird, because you’d think that the template would match the SDK references to the default version of Android targeted (6.0). Since I hate to see warnings in build output (did I mention that I hate to see warnings in build output?), I thought I’d take a stab at fixing those. I used the Android SDK Manager to install the 7.1 bits and then set the target Android framework to 7. Built OK, no warnings. Happy. Unfortunately it failed to deploy to the emulator, because aapt.exe crashed hard with no error messages. In hindsight, since the emulator is Android 6.0, I guess it should have been obvious to me that this wouldn’t work, but the tooling didn’t really help a novice out. I took a quick look around online for a 7.x version of the emulator for Visual Studio but wasn’t able to find one. I guess I’ll have to hold my nose and live with the warnings.
• If you specify a DataType for a DataTemplate (so that you can eliminate Resharper warnings on bound properties) they don’t seem to render anything. No errors or warnings in the logs – your page simply stays blank. You have to leave your DataTemplate types open and ignore the squigglies. I hate squigglies.

I’m now looking at converting the PCL that represents the core Xamarin app logic into a .NET Standard library instead. This allows for a larger target surface area of the .NET API and simplifies the project files, but requires some manual work to convert (again I don’t see any tooling support for this yet in Visual Studio). Stay tuned for how that goes…