Join Mark Smith for an in-depth discussion in this video What is Xamarin.Forms?, part of Introduction to Xamarin.Forms.
- In traditional Xamarin development, we share our business logic in the form of a portable class library, or a shared project, or perhaps a combination of the two. We then add references to these libraries with our common code to each of our supported, platform specific projects. That allows us to share all the things to find in these libraries with our Android, Windows Phone, and iOS projects. The code we share in this approach typically includes things such as view models, business logic, web service access code, and data structures. Things we can cleanly define in C# using .net APIs that are common to all three platforms.
This is often about 75% to 90% of our code base, depending on how complicated the application is. That still leaves anywhere from 10 to 25% of our code base that ends up being platform specific, and defined in a platform specific project that targets iOS, Android, and Windows Phone. And this is where you take advantage of something that is platform specific. Maybe you'd like to use the NFC, APIs, and the Android, or the touch ID API in iOS, for example. This platform specific block also includes the definition of the UI.
This is typically the UI defined using native platform controls, and any UI specific features that you want to take advantage of, such as maps, or perhaps specific gestures. This traditional Xamarin development approach works great and it lets you share the majority of your code. And, most Xamarin applications today are built using this exact approach because it's mature, it's flexible, and it's been around since the beginning. However, one of the common questions heard at conferences and from our developer community was, "How can I craft the UI in the shared code?" And that's where Xamarin.Forms comes in.
Xamarin.Forms provides a library of common controls, which are implemented across all three platforms. And, it allows you to define the UI in your shared code. And, at run time, these shared controls create native views for each platforms. So, you still get the native look and feel, but you only have to write the UI once, and have it shared on iOS, Android, and Windows Phone. So, looking back on our layers, we'll still have some platform specific code, there are likely features that we'll want to leverage, which are not cross-platform, but the UI definition will not be part of this unique code base.
Instead, that's going to be shared, just like the business logic in the data layer. Now, it's important to understand that Xamarin.Forms is just a UI layer. It doesn't change how your app is deployed, or how it gets executed at run time. You're still going to have separate, native applications for each platform that you want to support, just like the traditional approach. So, what are our runtime requirements for Xamarin.Forms going to be? Well, on Android, you're going to need to install the latest Android SDK to compile against. And, you'll need to keep this up to date.
As Xamarin.Forms gets versioned, it requires that we update to the latest Android SDK. You can then run the created application on any device with Ice Cream Sandwich or higher. On iOS, Xamarin.Forms requires a runtime target of iOS 6.0 or later. It supports all variations of the devices, so you can run your apps on iPods, iPhones, and iPads. And, just like the traditional Xamarin approach, it's going to require a Mac to build and deploy the application package. For Windows Phone, you can build an app which targets any version of Windows Phone 8.0 or later.
Keep in mind that all of these are separate projects. So, the UWP app will be a separate binary from the Windows Phone 8 version. Xamarin.Forms supports the tablet and desktop style as well, so you can run your app on Windows 10, or on a Surface Pro in tablet mode. Xamarin.Forms provides support to build fully interactive user interfaces by including support for a standard set of controls. Things that you're used to, such as buttons, edit fields, labels, pickers, sliders, and even scrolling lists. It also has a flexible layout system, which lets you position elements on the screen in an adaptive fashion, so your UI resizes based on the device that it's running on.
Where the platform supports it, Xamarin.Forms includes support for basic maps. It also has several navigation patterns, including master/detail, stack navigation, tab navigation, and page style navigation. If you're coming from the Microsoft platform, you'll be happy to know that Xamarin.Forms supports the use of XAML to define your UI in a markup format. And as part of that XAML system, there's a full data binding infrastructure, which allows for separation patterns, such as MVVM, to be used to connect your data to the UI. Finally, Xamarin.Forms supports styles and triggers, just like the Microsoft XAML platform, to standardize the look and feel of the app, and provide runtime changes based on events or bindings.
So, then the question becomes, should I use Xamarin.Forms or the traditional Xamarin approach? It might be an odd question to ask given that you're going through a class on Xamarin.Forms, but you should be aware that Xamarin.Forms isn't always the best approach to use for some apps. In some cases you'll find that using the traditional approach will actually be easier, depending on the type of application you're trying to build. Both approaches have their benefits and drawbacks, but there are some common questions you can ask yourself to help guide your decision. First, is the application you're trying to build oriented around data entry? Another way to say this is: Is the application mostly composed of data forms? This sort of enterprise-type application is well suited to Xamarin.Forms, and is in fact the exact scenario that Forms was designed to solve.
And so, you should use Xamarin.Forms for that. Another common case is when you're trying to quickly prototype an app to workout the logic or showoff to investors. And this is another perfect case for Xamarin.Forms. You can try out concepts quickly and without spending a lot of time designing the UI. Speaking of the UI, one important question to ask yourself is: How important is pixel perfect design to your application? If it's not important, and you're okay with subtle changes in the design between platforms, then Xamarin.Forms might be suitable for this app. Many things, such as spacing between elements, and some of the colors of the controls, are actually left up to the platform, and they're not easily changed in Xamarin.Forms.
So, if you're trying to reproduce a pixel perfect design, then Xamarin.Forms is not a good fit because it's almost impossible to completely control that in every situation. Finally, if your app will utilize specific controls unique to the platform, or have a significant investment in platform specific APIs, then Xamarin.Forms is probably not a good fit for this app. And, you'd be better off using the traditional Xamarin approach, where just the business logic is shared.
This course was created by Xamarin University. We are honored to host this training in our library.