This series begins with an overview here

This series is based on my Pluralsight Course: Building Your First Mobile Application with Xamarin.Forms and Visual Studio 2017

Layout

Xamarin.Forms has a number of “Layout” controls that can contain other controls (views) and help you with positioning those views on the page.  There are a number of different layouts available to you, including:

• ContentView
• ScrollView
• Frame
• TemplatedView
• StackLayout
• AbsoluteLayout
• RelativeLayout
• GridLayout

For the first number of blog posts in this series, we’ll be using the StackLayout (one view on top of another or one view next to another) and the GridLayout (similar to an HTML table)

Views

Not every view available in iOS or Android is available in Xamarin.Forms, but the ones that are available are rendered as native controls, indistinguishable from those created in Objective C, Swift or Java.

In short, you write to the Xamarin.Forms view and it is rendered to the native platform.

Among the views available to you are

• Activity Indicator
• BoxView
• Button
• Date / Time Picker
• Editor (multiple line entry)
• Entry (single line entry)
• Image
• Label
• ListView
• Open GL View
• Pickers (including a data bound picker)
• Progress Bar
• Search Bar
• Slider
• Stepper
• Switch (toggle)
• TableView
• WebView (embedded web pages)

DataBinding

Each of these views can be bound to your data, or to each other.  For example, a label can be bound to a slider to show the value of the slider.  We’ll come back to that in a future posting.

Jumping Into the Deep End

Rather than working my way through small demonstrations of these various views and layouts, I’m going to create a medium size demonstration program, and then dissect it in this and the next few blog posts.  This will show Xamarin.Forms in action, more or less the way you would actually use it.

The First, Bigish Demo

To get us rolling, I’m going to let Visual Studio Mac do a lot of the work of setting up the infrastructure of the demonstration program.  To do so, I’ll create a new project, and use the template Forms App.  This actually creates a skeleton Master/Detail project that we can build upon.

Let’s name this project BookStore, and build both an iOS and an Android version.  Visual Studio will let you use Git for version control, and we’ll do that. When you click create, notice that VS Mac has created a Views, Models and ViewModels folder for you, along with a folder named Helpers and one named Services.

A lot of advanced techniques are used in this application, right out of the box.  Rather than go through them all at once, we’ll examine them as we go.  In fact, paging through the source code and the XAML would be totally overwhelming at this point.  Yup, I know you’re going to do it anyway, but don’t say I didn’t warn you.

Git Repo

If you navigate to the folder that contains your project (and if you have your computer set to show “invisible” folders) you will see that you have a .git folder that contains your local repository information.   You may now want to point your git tool at that repository and possibly create a public or private repo on one of the popular public repositories.  Mine will be published on GitHub at https://github.com/JesseLiberty/BookStore

Quick Tour

Without reference to the code, let’s just run the application.  You’ll see that the main page (named ItemsPage) provides a list of items and that clicking on a single item brings you to details about that item (on the ItemDetailPage).

There is a good bit more, but that will get us going.

Examining ItemsPage.xaml (first peek)

To get us started, let’s take a look at a bit of ItemsPage.xaml.   This is where we’re going to put the name of our book and the name of our author.  Unfortunately, even that isn’t trivial, so let’s start by quickly examining the XAML.

At the top of the page we see a ContentPage element, with a number of name spaces defined (xmlns).  We also see a class defined, and this is the class that will be in the associated code-behind file (ItemsPage.xaml.cs)

This first attribute already has data binding; the title is bound to the public property Title.  For today, let’s just track that single binding.

In the code behind file we see this line of code:

 BindingContext = viewModel = new ItemsViewModel();

That indicates that we’re instantiating a class ItemViewModel and assigning that new object to the BindingContext of the current page.  That means (as illustrated in the second blog post in this series) that we should look in the ViewModels folder for a file named ItemsViewModel.  Opening the ViewModles folder we find that file and inside, sure enough, the Title property is initialized,

       public ItemsViewModel() {
          Title = "Browse";
 

But where is this property declared?  Notice that ItemsViewModel inherits from BaseViewModel.  Let’s look there.

BaseViewModel does have the Title property, but it doesn’t use automatic getters and setters.

       string title = string.Empty;
       public string Title {
          get { return title; }
          set { SetProperty( ref title,value ); }
       }

The getter is straight forward, but the setter uses SetProperty passing in a reference to the backing variable and the value of the title.

SetProperty is defined in the Helpers folder, and is absurdly complex. It is part of the ObservableObject class which implements INotifyPropertyChanged.  You do not have to worry about how this works for now (or for some time to come).  There are simpler ways to do this, but for now, take it on faith that what this is doing is publishing the fact that a new value has been assigned to the Title property and thus the UI is notified.

Since the new value is assigned in the ViewModel’s constructor, the UI is notified that the Title property has changed and it fetches the value, which in this case is “Browse.”  If you run the program you’ll see that this page has a title of Browse.

Help! I’ve fallen and I can’t get up.

Now that I’ve convinced you that Xamarin.Forms is hopelessly complex and unmanageable, let me back up and say that this out of the box solution is very powerful and has a great deal of complexity to it, but it will save us a lot of time by doing a lot of the work for us.

As we add to and modify it, you’ll find that things get simpler as we go, and that there really isn’t anything terribly frightening hiding in there.

In the next blog post we’ll return to the ItemsPage.xaml file and look at the layout (a StackLayout) and one of my favorite controls: the ListView.