XAML vs. C#

Xamarin.Forms provides a cross-platform toolkit of pages, layouts, and controls and is a great place to start to begin building an app quickly. There are two ways to create user interfaces in Xamarin.Forms, either in C# using the rich Xamarin.Forms API or using Extensible Markup Language (XAML), a declarative markup language created by Microsoft used to define user interfaces. My previous book, Xamarin Mobile Application Development, covered the C# approach, but this book is all about XAML. You can create exactly the same kind of UI in both C# and XAML, so the choice is largely subjective and personal, although there are architectural considerations. XAML forces separation of the View code, while the C# approach does not. Jason Smith, the principal software engineer on the Xamarin.Forms team at Microsoft, explained it this way, “We build Xamarin.Forms code first. That means that all features are first created to work using C#, then we implement them for XAML.”

Xamarin.Forms elements are built using Page, Layout, and View classes. This API provides a broad range of built-in cross-platform mobile UI patterns. Beginning with the highest-level Page objects, it provides familiar menu pages such as NavigationPage for hierarchical drilldown menus, TabbedPage for tab menus, a MasterDetailPage for making navigation drawers, a CarouselPage for scrolling image pages, and a ContentPage, a base class for creating custom pages. Layouts span the standard formats we use on various platforms including StackLayout, AbsoluteLayout, RelativeLayout, Grid, ScrollView, and ContentView, the base layout class. Used within those layouts are dozens of familiar controls, or views, such as ListView, Button, DatePicker, and TableView. Many of these views have built-in data binding options.

Xamarin.Forms comprises platform-independent classes that are bound to their native platform-specific counterparts. This means we can develop basic, native UIs for all three platforms with almost no knowledge of iOS and Android UIs. Rejoice but beware! Purists warn that trying to build apps for these platforms without an understanding of the native APIs is a reckless undertaking. Let’s heed the spirit of their concerns. We must take a keen interest in Android and iOS platforms, their evolution , features, idiosyncrasies, and releases. We can also wallow in the convenience and genius of the amazing cross-platform abstraction that is Xamarin.Forms!

Xamarin.Forms Solution Architecture

One of the greatest benefits of Xamarin.Forms is that it gives us the ability to develop native mobile apps for several platforms simultaneously. Figure 1-2 shows the solution architecture for a cross-platform Xamarin.Forms app developed for iOS, Android, and any of the other supported platforms. In the spirit of good architecture and reusability, a Xamarin.Forms cross-platform solution often uses shared C# application code containing the business logic and data access layer, shown as the bottom level of the diagram. This is frequently referred to as the Core Library. The cross-platform Xamarin.Forms UI layer is also C# and is depicted as the middle layer in the figure. The thin, broken layer at the top is a tiny amount of platform-specific C# UI code in platform-specific projects required to initialize and run the app in each native OS.

Figure 1-2 is simplified to communicate the fundamentals of Xamarin.Forms. The reality is that hybridization between Xamarin.Forms and platform-specific code is possible, useful, and encouraged. It can happen at a number of levels. First, within the Xamarin.Forms customization options, which include custom renderers, effects, and native views. Customization gives us platform-specific classes for rendering platform-specific features on a Xamarin.Forms page. Hybridization can also happen within platform-specific Android activities and iOS view controllers that run alongside Xamarin.Forms pages or within platform-specific classes that are called as needed to handle native functionality such as location, camera, graphics, or animation. This sophisticated approach (which is now commonplace) leads to a more complex architecture, shown in Figure 1-3, and must be handled carefully. Note the addition of the platform-specific UI layer.

When are Xamarin.Forms appropriate to use and when do we consider other Xamarin options? I’ll address this key question a bit later in the chapter, but first let’s define Xamarin’s platform-specific UI options.

Platform-Specific UI Solution Architecture

Figure 1-4 shows how a platform-specific solution designed to be cross-platform shares C# application code containing the business logic and data access layer, just like a Xamarin.Forms solution. The UI layer is another story: it’s all platform-specific. UI C# code in these projects uses classes that are bound directly to the native API: iOS, Android, or Windows sans binding.

If you compare this diagram to the Xamarin.Forms diagram in Figure 1-2, you’ll see that there’s a lot more coding to be done here: a UI for every platform as opposed to one for all. Why would anyone bother to do it this way? There are quite a few good reasons why some or even all of the code might be done better this way. So how do we know when to use Forms?

Using Custom Renderers, Effects, and Native Views

You’ll eventually need more from Xamarin.Forms than it gives you out of the box. When complex tasks or designs are required by Xamarin.Forms, virtually anything is possible using Xamarin.Forms customization. Custom renderers provide access to the lower-level, platform-specific, screen-rendering classes called renderers, which use platform-specific controls to create all Xamarin.Forms screens. Any Xamarin.Forms screen can be broken into platform-specific screens and classes using this approach. This means we can write a Xamarin.Forms page or app and customize it by platform whenever necessary. More about this in Chapter 8.

Custom renderers are powerful and thorough in their implementation as platform-specific enablers of Xamarin.Forms UI elements. Custom renderers are, however, heavy artillery. If you want something more tactical, like merely customizing a property on a Xamarin.Forms control, consider an “effect.” In addition to exposing properties, effects also have the capacity to pass parameters to those properties and define events on Xamarin.Forms controls. You pass parameters to the effect using attached properties or the Common Language Runtime (CLR).

Sometimes you just want a real native control. You’ll settle for nothing less than absolute power. Thankfully there’s now a way to get this in Xamarin.Forms via native view declaration. They’re easiest to use in XAML, secondarily in C#.

All of this means that you can write a Xamarin.Forms page or app and customize it by platform, which is raw power in your hands as you work with a cross-platform toolset.

Use customization mindfully or risk a fragmented UI code base that probably should have been written entirely as a platform-specific UI. Used judiciously, customization can turn your basic, lackluster product into a versatile, unique, popular app. Let’s do a quick refresher of the mobile user interface.

Page

In addition to serving as containers for layouts and views, pages provide a rich menu of prefabricated screens with useful functionality that includes navigation and gesture responsiveness. More on these in Chapter 7.

Layout

The layout’s Content and/or Children properties contain other layouts and views. Horizontal and vertical alignment is set by the properties HorizontalOptions and VerticalOptions. Rows, columns, and cells within a layout can be padded with space, sized to expand to fill available space, or shrunk to fit their content. More on layouts in chapter 3.

View

Xamarin.Forms Project

Each platform has a wrapper class that takes the shared App class and renders it as its native implementation. The default code sets the MainPage property in its constructor to this case a ContentPage object called MainPage. Soon we will replace MainPage with our own ContentPage class and place controls on it using XAML.

The OnStart, OnSleep, and OnResume method overrides created for us are used to manage our app when it is moved to and from the background.

Xamarin.Android

In the OnCreate method , Xamarin.Forms is initialized and LoadApplication sets App as the current Application.

Xamarin.iOS

Xamarin.Forms is initialized in the Init() method and LoadApplication sets App as the current page.

All of our platform-specific initializers, the Android MainActivity and the iOS AppDelegate, get the starting page from the Xamarin.Forms App class, which, by default, returns a stubbed demo page.

Core Library

The Core Library is a project in a Xamarin.Forms solution for the business and/or data access layer of an app which should be largely platform independent. Although not explicitly created as part of the Xamarin.Forms solution templates, a Core Library project is standard practice. Create one yourself and add it to your solution. This can contain data models, shared files or resources, data access, business logic, or references to PCLs. This is the place for platform-independent middle-tier or back-end non-UI code. It is referenced by any or all of the other projects in the solution. Use it to optimize code reuse and to decouple the UI projects from the data access layer and business logic. Note Core Library is an advanced solution architecture. If you’re just starting out with Xamarin.Forms, consider putting your data access, business logic, and shared code in the Xamarin.Forms project, and hold off on using a Core Library for now.

Now we need to build out the pages of our app. Time to code!

Setting the App’s Main Page

Now we have the custom page class ready and can load up our ContentPageExample XAML file with controls.

Label View

Multiline text happens implicitly when enough text is used that it wraps, or explicitly with line breaks.

The TextAlignment enumeration assigned to these alignment properties has three values: Start, Center, and End.

Next, the labels must be assigned to a layout for placement on the page. In this example we use the text alignment defaults and don’t explicitly declare text alignment.

Placing Views Using StackLayout

We place all the child views onto the StackLayout parent view and set the requested height with HeightRequest. HeightRequest has been set larger than the visible page so later we can make it scroll.

Compile and run the code. Figure 1-7 shows our labels on the StackLayout for iOS and Android, respectively.

If you’re using iOS and want your Xamarin.Forms projects to look more like examples in this book that have a black background and white text, or you’re using another platform and want more of an iOS look, setting background color and font color can help you.

Background Color and Font Color

Page background color and view font color can be changed using the ContentPage's BackgroundColor property and the TextColor property found on text-based Views.

We use fonts in many controls, so let’s do a quick overview of those.

Using Fonts

Using Platform-Specific Fonts

Button View

Xamarin.Forms buttons are rectangular and clickable.

The Text property contains the text visible on the button. HorizontalOptions and VerticalOptions (discussed in the next section) determine the control’s alignment and size. This NamedSize font setting makes the font Large.

Figure 1-8 shows the new button.

When you click the button, the button text changes, as in Figure 1-9.

Setting View Alignment and Size: HorizontalOptions and VerticalOptions

Considerations in view layout are the space provided to the view by the layout and surrounding elements, the padding space around the view, and the size of the view itself. These types of formatting are accomplished using LayoutOptions and AndExpand.

Entry View for Text Input

User input goes into the Text property as a String.

Note the use of the Placeholder property, an inline label for the name of the field and a common technique in the mobile UI often preferable to space-consuming labels placed above or beside the entry control. The Keyboard property is a member of InputView and provides a range of options for the onscreen keyboard that appears for input, including Text, Numeric, Telephone, URL, and Email. Remember to add the entry to your StackLayout (see Listing 1-6 later in the chapter). Figure 1-10 shows the new entry control for username.

BoxView

The Color property can be set to any Color member value. The default dimensions are 40×40 pixels, which can be changed using the WidthRequest and HeightRequest properties.

Add the BoxView to your StackLayout (see Listing 1-6 later in the chapter) and see the result here in Figure 1-11.

Eventually your designer will give you those promised icons and you can replace your BoxViews with real images.

Image View

Figure 1-12 shows the monkey image at the bottom right.

Let’s look at how an image is handled.

ScrollView

That’s it for the views on this page. The final touch will be padding around the entire page, so views won’t be mashed up against the sides of the screen.

Padding Around the Entire Page

This last Padding expression is what we use in this project and in most projects in this book, padding around the edges of the page with a bit more room at the top on iOS for the status bar.

Figure 1-13 shows a final build and run on both platforms.

CODE COMPLETE: Adding Xamarin.Forms Views