The Confession
Okay, right off the bat, I’m going to admit I’m a Microsoft “bigot” or in less unfriendly terms, a Microsoft “super-enthusiast” with severe “Microsoft is actually better at everything” leanings. I’ve spent most of the last 30 years writing Microsoft-based solutions with Microsoft tools and technologies for clients who are Microsoft “shops.” Still, to this day, I never install any non-Microsoft products on my workstations, except the (still phenomenal) Adobe Fireworks. Yes, Fireworks.
The Challenge
For the last four years, as a weird twist of fate, I have been creating real apps for real clients using the Xamarin platform, and more often than not, Xamarin Forms (or is it Xamarin.Forms? …I can never figure out why we need a dot although it does look cooler that way.) One thing I have noticed is that almost every blog, every post, every slice of documentation that exists for Xamarin Forms seems to be written by someone who “skews native” and not by someone in the actual Microsoft development world. I know why this is, of course, but am not going to write it out loud.
The Observation
Over the last couple of years I also started to notice (mostly) Microsoft developers struggling with the same issues, the same hiccups, and doing the same things that “seemed right at the time” based on documentation, but realized one compile too late, those examples were just “examples” and not to be taken on an empty stomach.
The Reason
This series of posts is devoted to all the things I wish I knew, as a Microsoft developer, before I provisioned my first xPlatform solution: The 60+ tips, tricks, and lessons learned I’ve accumulated over the last couple of years using Xamarin Forms (in Visual Studio for Windows.)
Many of these things are things an Android or iOS developer (i.e.; college student) probably already knows, but not a Microsoft developer. Some of these things will seem ridiculous to even share, and some so obvious that perhaps some developers will pretend I am the only one who didn’t already know about it. Some of these things will be super-extra important, and some will be meaningless to almost everyone. For better or for worse, in no particular order, is the first batch of TTLL:
The Bits
Android projects hate hyphens in resource names.
Don’t use a hyphen in an image or resource name. If you name an image “nice-background.png” instead of “nice_background.png” and drop it into your drawable folder, and then try and compile or deploy, you will got all sorts of weird errors. None of these errors will actually say, “Don’t use a hyphen in the image name.”
There IS such a thing as a Visual Studio Emulator for Android “Manager”
In Visual Studio 2017, go to Tools > Visual Studio Emulator for Android and you will actually see a very long list of all the possible emulators you can use for Android. If you are having issues with your current Android emulator it’s often helpful just to totally uninstall the emulator profile and spin up a different one—all things easily accomplished with this tool.
Use a Portable Class Library (PCL) instead of a Shared Project when provisioning a solution.
There are a whole bunch of reasons I suggest this, but here are the primary two:
- Almost every single scrap of documentation for the important things you need to do in a Xamarin Forms app is written for PCL, and
- The conditional compilation logic used in Shared Projects is messy and annoying. It’s way too “Windows 8” to be honest.
Visual Studio 2017 Installer often messes up your Hyper-V Emulator Network connections.
Almost every time I do an update lately via the Visual Studio 2017 Installer, my Hyper-V-based Android Emulators lose network capabilities. This is true on every workstation in my environment, and I am not alone. If this happens to you, go to Hyper-V, select the emulator(s) in question, click Settings and make sure you have exactly two (2) Network Adapters installed, and that the FIRST one in the list is the Windows Phone Emulator Internal Switch. It needs to be first in the list, with a “real” adapter listed second.
Name your app packages right away, and name them correctly.
This matters not-a-bit for Windows, a-lotta bit for Android, and is critical for iOS. Just commit to yourself to start doing this starting right now, and use the “reverse domain name” style, such as “com.companyname.appname” even though this naming convention comes from the Java world. Why? Android and iOS want this, and Windows doesn’t care, so why not just keep them all happy? If you don’t do this you will eventually HAVE to do it to get some of the apps into the stores, and if you wait and do it when you’re ready to submit, you may have to totally redo archives and provisioning profiles.
Never try to update all the Xamarin.Android.Support packages that show in NuGet Package Manager.
This is the first thing developers typically try and do whenever they can’t get the Android project in their solution to compile or deploy to the emulator. Why? Because it makes sense. We’re not stupid, we’re just drawn that way. Let me make one exception: Update these if a real Xamarin Team 4th level premier support person tells you to…otherwise, NEVER. UPDATE. THEM. You will just mess everything else up, and the version of these assemblies is NOT the problem with your project. #TrustMe
Just because you are only calling code from your PCL doesn’t mean the platform-specific project doesn’t need the package.
This might seem like a “no-brainer” but it’s not. Remember, the Xamarin platform compiles to native code, and you are using the platform-specific flavor of assemblies. Just because it compiles, doesn’t mean it will work at runtime. If the assembly doesn’t already exist in the Xamarin Forms version of the .NET Framework, you WILL need to add the assembly in the platform-specific project as well. Some common examples are Newtonsoft.Json and Microsoft.Azure.Mobile.Client. Add these packages to every project if you are using them in your PCL. The NuGet Package Manager is smart enough to figure out what platform you are working with.
The Wrap Up
My guess is, if you’re a Microsoft developer starting out with Xamarin Forms, you’re already walking away with a semi-colon-open-paren, or at the very least, ready for the next batch of Tips. Tricks, and Lessons Learned. See you in Part 2. #XamarinRocks