Xamarin as a system will let you build apps specifically for a given platform. If you want to build just an iOS application, you can do that. But its real strength and the focus of this series is on how to make cross platform apps with a single code base. With maybe 5-15% more work & planning you can have 400% more customer potential by having your app run on Android, iOS (including everything from Mac desktops, iPhones, AppleTV and even a little AppleWatch), WindowsUWP (so desktops and Surface tablets alike), and even Windows phone if those 9 users interest you. As of the Connect() 2016 conference announcement, Samsung is also jumping onboard with support for the Tizen operating system used on appliances, wearables and other embedded devices as part of the IoT (Internet of Things) movement.
Xamarin.forms uses XAML markup language for creating the UI (views/pages/controls) and C# for the ‘code behind’; the properties, data, logic and executable code that actually ‘runs’. This separation of UI and code-behind is exactly the same as Microsoft has used for years for their WPF system. Xamarin.forms applications just like WPF applications are primarily architected around the MVVM design pattern. Model View ViewModel is a design pattern that separates data from UI while providing a system for binding that data to the UI in a loosely coupled way so the UI updates automatically when the data changes, and the data is updated when the user makes a change in the UI. The MVVM pattern has proven itself for years in WPF and is well worth the learning curve if you haven’t used it before. If you have experience with WPF/MVVM then you’re going to feel right at home in Xamarin.forms.
A solution consists of multiple projects. 90%+ of your code will be common to all platforms and contained in the Portable Class Library (PCL). This is your UI, logic and models (objects). Then there is a project for each platform. Each of these platform projects will have a file that launches the actual app: That’s just a few lines. Then you might have a bit of code here and there for very specific needs on a given platform. For example, maybe you want to render an octagonal tile for a game you’re making and that level of graphic work is done differently on iOS than Android.
At first there is a little bit of a re-think for experienced desktop program developers when transitioning to having most of their code in a PCL. Since you’re now working in a device-platform-agnostic space you have to consider that your program may launch when you have internet, then loose connection as the device travels. Your program might be running on a landscape 1920×1200 PC monitor or it could be running on an 800×500 low-res smartphone in portrait orientation. You might be running on Wi-Fi, or you might be running on a metered cellular connection where every kb has a dollar figure associated with it. Your app will be launched/backgrounded/resumed/backgrounded/killed at the whim of the user. Even something as simple as file paths and application permissions change between platforms: The path separator for Windows is ‘\’ and on Macintosh its ‘/’.
If there’s any advice I can impart on the subject it’s this: Think generic, plan from the 30,000-ft. view, separation of responsibilities/concerns, code in layers. Let’s say you know you’re going to have some data that you store, fetch, and update. Don’t get bogged down in the details of *how*. You know that C# is an Object-Oriented Programming language. In other words, C# deals with objects, not data. If you’re going to take photos plan to take photos but don’t worry about how to directly access the camera on an Android tablet right off the bat. Just realize you’re going to take a photo at the PCL level (the common, platform-agnostic level) and at some point, that will become a device specific block of code in each platform project that your PCL really doesn’t have to know or care about.
Using a database as a more specific example: At a PCL level your program just needs to know it’s going to save in a database. On iOS, it might be a SQLite database while on Windows it might be a Microsoft SQL database; but the logic of your program shouldn’t be aware or depended on knowing which. The logic tells the Data Access Layer to save. The DAL then calls the specific database implementation to do its job. Maybe that implementation comes from a NuGet package. Maybe it comes from a class you write just for WinPhone. This type of layered approach when combined with good separation of responsibility means if you change choices in databases or you move to a different device you only have to change code in one file without risk of breaking a dozen different classes.
We’ll get into actual code doing this later in the series. For now, it’s just important to grasp the concept and let your brain wrap itself around that for a while. Building software in a layered approach is new to many. Planning for a variety of platforms and screen real estates and hardware capabilities is new to most.
Terminology – The same only different
Windows Forms worked in “Forms”. WPF worked in “Windows”. Xamarin works in “Pages”. A screen of content by any other name is still a screen of content. WPF has a “TextBox” and “StackPanel“. Xamarin has an “Entry” and “StackLayout“. Don’t let yourself get too caught up on the terms. It’s all basically the same thingies you’ve used before, with a new name or slight twist. Some of the twists are actually improvements upon WPF. For example, WPF horizontal text alignment was left, center and right. Xamarin is Start, Center, End. This makes more sense when we consider that not all languages are left-to-right reading. For English ‘Start’ will be left alignment. But for Yiddish, ‘Start’ will be right alignment. With no extra work on the part of the developer.
What sets Xamarin apart is the eco-system under the XAML/C#. Xamarin took the mono port of .NET and hitched it up to their Xamarin.forms XAML implementation on all the popular platforms: Android, iOS, UWP, Windows, Mac. So, when you make an “Entry” in your shared code the mono runtime on iOS will make an iOS native textbox, and on android it will make an Android native textbox; regardless of what those platforms might call them. It maps from a common set of controls to the native controls on each platform – so you don’t have to learn all three. Thus, your program will always be native running code on any device.
You do not build a program “In Xamarin”. You build your program in C# and XAML, using Xamarin.Forms.