Xamarin rocks. One reason is that it reduces the learning curve needed to get you productive building native mobile apps for work or fun. But, it doesn't flatten the curve entirely. In fact, there are numerous gotchas big and small waiting for you in this weird and wonderful new world!
I really love developing in Xamarin. Some of the following points may lead you to believe otherwise. But, my goal here is to give you the straight dope before you dive in and get bit by nasty surprises. That way, you'll be better informed from the start. These are ten things (in no particular order) I wish I'd known when I began my Xamarin journey. I've also thrown in tips and links to give you a head start on setting up and using your new environment.
1. The Mac Connection
Does Xamarin really allow you to do iOS development on a PC? Do you need a Mac to do Xamarin development? For both of these questions I can provide you with a definitive answer: kinda. If you are developing for both Android and iOS, what you'll actually do is develop in Visual Studio on your PC and test with an Android emulator. (More on Android emulators later.) You can develop your entire application this way.
However, to deploy to iOS, you'll need to have access to a Mac. The iOS compiler and the iOS emulator both reside on the Mac. The good news, though, is that Xamarin has made the process of working with a Mac from your PC very easy. You first run an app called the Xamarin Build Server on the Mac. Your PC finds the Mac on the network and syncs with it. Then, you set your iOS project as the solution default and run. The code is compiled on the Mac and then run in the iOS emulator on the Mac.
Tip: If you can have both machines on your desk at once, that works well. It works even better if you use a tool like Synergy, which allows you to use a single keyboard and mouse to work with them both. If the Mac is physically elsewhere, a cross-platform, remote-desktop solution like Splashtop is your best bet. Then, your Mac is simply another window on your PC desktop.
2. Going Sync-Free
Perhaps you're one of the many developers who's shied away from asynchronous programming before now. Asynchronous, multi-threaded development is full of strange problems and non-intuitive solutions. But, it's becoming tougher and tougher to avoid. Creating more responsive user interfaces, applications that leverage REST or SOAP services, and speeder apps that take better advantage of today's multi-core CPUs. All of these task demand asynchronous programming.
And so does mobile development. Whether you're targeting iOS, Android, or Windows Phone, your code will be using asynchronous techniques. It's not optional.
But, the good news is that Microsoft has been hard at work for years now to make asynchronous programming accessible and fairly straightforward. Look up the async and await keywords in MSDN and you'll find that it's not nearly as tough as you feared. Just keep one thing in mind: Despite its name, await doesn't actually wait.
3. You Don't Get 100% Re-Use
Xamarin uses C# and .NET to give you a common, familiar platform for creating apps that run on several platforms. However, don't think that means you write once and run anywhere. Mobile user interfaces are created in very different ways on iOS and Android. And, that code must be written and maintained separately for each platform. You still code in C#, but the controls, properties, and techniques used are completely different.
To limit the duplicated work as much as possible, it's very important that you adopt an architecture like MVC or MVVM that separates user interface concerns from business and data access logic. That way everything but the UI is reusable.
Note: Xamarin has released a UI designer for creating native iOS APIs entirely within Visual Studio on your PC. This is a giant leap forward becauuse without it you'd have to use the XCode UI designer on the Mac that is far from intuitive! For more on this and related features, see http://xamarin.com/visual-studio#designers.
4. Xamarin Forms to the Rescue?
Remember when I said that code must be written and maintained separately for each platform? I lied. But, just a bit. In the past, Xamarin apps have been developed that way and still today many successful projects are still done that way. But, Xamarin has introduced a technology that begins to give you the ability to write to one set of UI controls/properties.
Notice I said "begins" because Xamarin Forms is still a new technology and it shows. Its collection of controls and properties is downright anorexic. (Really? No checkbox? Really?) And, unfortunately, if the Xamarin Forms control doesn't support what you want to do with it, there's only one answer: Create your own custom renderer. What's that? It's a control that you create and give whatever properties and methods you want. But then, you must write the platform-specific code that displays your control for each platform you support.
So, don't swallow the hype. Even though Xamarin Forms provides a structure that begins to support simple data-entry applications, it does not make it possible for you to avoid writing separate platform-specific code.
But, keep your eye out for updates to Xamarin Forms. They are working hard to expand this technology into something much more powerful. And already, there are third-party Xamarin Forms controls available.
5. Cross-Platform for Devices-Specific Features? Uhm, No.…
In addition to the platform-specific user interface code you'll need to write, you should also be aware that there isn't a complete cross-platform way to access features like GPS, notifications, photo capture, and so forth. What is available is Xamarin.Mobile. This library is a free download and it provides a way of accessing some common features using its cross-platform API. But, don't get your hopes up. As with Xamarin Forms, the features provided are mighty slim right now. Specifically, you can…
- Get the user's current longitude and latitude. No other location services, geo-fencing, or GPS features are available.
- Retrieve basic address-book information about contacts.
- Taking a photo or getting a photo from the gallery is supported, but platform-specific code may still be required, depending on what you want to do.
What you don't get: Most GPS features, notifications, accelerometer, compass, and other sensors and music/playlists. For these, you'll need to go native.
6. Use PCL to Share Code with ASP.NET and Other .NET Applications
A Portable Class Library (PCL) is a special kind of class library that is compiled in a way that allows it to be deployed to Android and iOS as well as to all other .NET application types. So, if you are creating a mobile app that complements a pre-existing ASP.NET site, you can re-use class library code in ASP.NET by placing the classes in a PCL instead. Then, add a reference to the PCL from the APS.NET site and add a reference to it from your Xamarin mobile apps. This assures a single point of maintenance while still providing native execution speed everywhere it's used.
7. You Can Create Mac Apps, Too!
Xamarin's primary focus is on supporting your development of mobile applications. But, suppose you want to create a Mac app, perhaps one that supports your mobile app in some way. You can do that with Xamarin.Mac. Although you'll need to use the XCode UI builder to create the interface, all your code can be done in C#.
8. Xamarin Components vs. NuGet
Xamarin provides a very useful component library that you can browse by category or search at http://components.xamarin.com/. When browsing, be aware of the icons along the right of each list item; they indicate what platforms are supported.
You can install these components directly into your application from Visual Studio. When you do, they are put into a Components folder.
However, many of these same components are available as Nuget packages, which you can also download directly to your project from within Visual Studio.
Usually, either approach will work, so just be consistent. However, there may be times when, for one reason or another, one approach will work and the other will not.
9. XAML Ain't XAML
If you have created user interfaces in WPF with XAML, you may be very excited to learn that Xamarin Forms supports XAML for defining your mobile UI. But, don't get too excited yet. Although Xamarin Forms does implement a dialect of XAML, it isn't going to look anything like you see in WPF. XAML is ultimately just a way to instantiate and set properties on a .NET class library. In WPF, you build your UI from the rich WPF control library. With Xamarin Forms, you are working with the Xamarin control library, which is limited, as I said earlier. In addition, many of the XAML features you're used to are also missing. However, a recent release did add styling and behaviors to the mix, which are definitely a welcome update!
10. Native Android Emulator? Forgetaboutit!
You will probably find yourself using the Android emulator for your day-to-day development and testing if you prefer to work on a PC. However, if you try to use the default Android emulator that comes with the Android SDK (installed as part of the Xamarin install process), you find that it is incredibly slow to load and incredibly slow when it runs. Not just a little slow—borderline unusable slow.
Fortunately, there's a better way. A couple of ways, in fact. If you are using Visual Studio 2015, there's a Hyper-V-based Android emulator included. This is a quick, easy solution. If you aren't using Visual Studio 2015, or if you want a wider selection of emulated phones/tables, check out Genymotion. This is a free, fast Android emulator that simulates location, with coordinates you specify and taking photos using through your PC's webcam. It also allows you to install profiles that emulate dozens of different kinds of Android devices.