Dan Hermes: Xamarin Book Tour

I’m on tour with my best-selling Apress book, Xamarin Mobile Application Development! I’ll be speaking about cross-platform mobile apps and how to build them for iOS, Android, and Windows Phone, on both phones and tablets. Drawing on UI and navigation designs from the most popular and progressive apps, I walk through how to engage and delight the user every step of the way. I’ll show how to use C# to build iOS, Android, and Windows Phone apps using the Xamarin Platform, the premiere cross-platform toolset for native app creation. Here is the current schedule:


January 12th Burlington, MA – Microsoft Azure Day

March 20th   Las Vegas, NV – IBM Interconnect 2017

August MSDN Magazine – How Xamarin.Forms Took a Drone App Higher

October 22nd  Orlando, FL – Microsoft Ignite 2017

December 8th Microsoft edX course- DevOps for Mobile Apps


January 11th      Jacksonville, Florida – North Florida Xamarin User Group

January 12th     Tampa, Florida – Mobile App Dev Tampa (MADTampa)

January 13th     Orlando, Florida – Orlando .NET User Group (ONETUG)

January 14th     Fort Lauderdale, Florida – South Florida Xamarin Users Group

February 24th    Las Vegas, NV – IBM Interconnect 2016

March 8th       Washington D.C. –  DC Mobile .NET Developers

March 17th      Cambridge, MA – Boston Mobile C# Developer’s Group

June 29th        Cambridge, MA – Boston New Tech: Mobile App Showcase

August 9th    Cambridge, MA –  Boston Technology Workshops

August 20th    Cambridge, MA –  Xamarin Dev Days

Come out and hear about C# mobile app development at an event near you!
Are you a mobile group and want me to present? Let me know.

XamarinGroupOrlandoLine2 XamarinGroupOrlandoAudienceSm XamarinGroupMe and Mark Radacz WashingtonDC SoFlorida ONETUGOrlando2 ONETUGOrlando NoFlorida MADTampa BostonMobileDevsSm DanJesse_DevDays2016b DevDaysBoston2016room Dan_DevDays2016

The Compleat History of Data Access Patterns


One of the great things about Xamarin development is that we get to use many of the concepts we learned in pre-mobile development. Software architecture is a good example. Most of the software patterns that we used in web development are still applicable.

Let’s look at the data access patterns outlined by the master of enterprise software architecture, Martin Fowler. We can still use the pre-OO procedural approaches to coding like his Transaction Script, Table Module, and Table Data Gateway. Then we can code using strictly object-oriented patterns such as Domain Models, Data Mappers, and the ever-popular Repository. Many of these are the equivalent of or have evolved into the patterns we use today such as POCO, Controller, ViewController, and ViewModel.

If you want to explore the Xamarin Data Access Layer(DAL) in the context of traditional enterprise design patterns then read on. If you just want to know how to create a DAL using the Repository pattern in Xamarin, then stay tuned for my forthcoming blog entry on the Repository.

Let’s begin at the beginning with the old-skool patterns.

Procedural Patterns

The point of object-oriented design was to wean us off of the procedural approach. Before we created domain models, data objects, object-oriented business logic and the like, we created a list of procedures to call, which is now called the Transaction Script pattern.

Transaction Script

We make calls to these procedures that return the data we need. Using the Transaction Script pattern (though most of us don’t call it that when we’re using it) and some pseudocode, our app looks something like this:

class void MyEntireApp 
    public GetSomethingAndDoSomethingWithIt() 
    public GetSomethingElseAndDoSomethingElseWithIt() 

Data access and business logic were wrapped up together in this construct. Until…someone became annoyed with how long this list of procedures was (and sadly we used let it hit the floor sometimes). They would call this a long method code smell and say that the Transaction Script had become an anti-pattern. Another approach was employed to break up these procedures according to the tables in the database.

Table Modules

Blocks of table-specific business and data access logic are now called Table Modules. This one is for the Item table.

class void ItemTableModule() 
    public GetPersonAndDoSomethingWithIt(int ID)
    public GetPersonAndDoSomethingElseWithIt(int ID)

Mind you, we haven’t yet introduced a domain model, so the business logic is probably operating on database-specific entities, such as Record Sets or variables from rows specified using numeric IDs. What we have here is a coupled business and data access layer grouped by table, violating Separation of Concerns (SOC).

The next step is to break out the data access logic into separate table-specific data access components which Fowler calls Table Data Gateways.

Table Data Gateways

A Table Data Gateway handles all of the data access for a particular table: usually CRUD-style (create, read, update, delete), using row ids.

class void ItemTableGateway 
    public Get(int Id)
    public Put(string Name)
    public Update(int Id, string Name)
    public Delete(int Id)

The Table Data Gateway houses basic data transactions as well as more advanced queries and inserts, but the results are generally record sets.  The record sets are generally passed back to the Table Module which can then handle the business logic. Using a Table Module with a Table Data Gateway gives us separation of business and data access logic, all without much object-oriented programming.

If all of the tables in the database are handled using Table Modules and Table Data Gateways, a facade class can be laid on top of all of them to provide easy-access to all data calls in one place. This pattern is a monolithic Table Data Gateway which I’m going to call a Database Gateway (my term, not Folwer’s). A Database Gateway has all table CRUD calls for all tables in the same class( and hints at important things to come when we get to the Repository pattern in OOP).

Database Gateway

Here’s a Database Gateway for both Item and Person tables.

class void DatabaseGateway
    public GetItem(int Id)
    public PutItem(string Name)
    public UpdateItem(int Id, string Name)
    public DeleteItem(int Id)
    public GetPerson(int Id)
    public PutPerson(string Name)
    public UpdateItem(int Id, string Name)
    public DeletePerson(int Id)

Not very pretty but, for a small number of tables, quite concise and organized. You’ll see soon why a Database Gateway is important in Xamarin development.

Those are some oldie-but-goodie non-OO patterns  useful in simple apps or in simple components of OO apps.  Now, fast-forward to the present.

Domain Model Patterns

Enter domain models! Create classes that represent specific entities within the workflow and have a one-to-one relationship between a business entity and an object instance (like a physical car and a Car object). Here is where we stopped sticking all of our logic in procedures (pre-OOP-speak for method), and started constructing classes to represent our domain logic. In simple apps that means an Item class or a Group class, which pretty much correspond to our table names.  In more complex apps this means lots of classes which correspond to different entities and processes that arise as a result of defining user stories or system architecture.

Let us begin with the simplest of the object-oriented patterns.

Domain Model

Now called a ‘model containing business logic’, Folwer’s Domain Model is an OOPified Table Module pattern. This class reflects our domain logic with names like Item, Person, Building, Conversion, Forecast, Event, and Reimbursement. Each object instance generally corresponds to a single physical thing. For example, each instance of an Item class represents a single physical item. A Domain Model class for an item entity might look like this.

class void Item() 
    public int Id {get;set;}
    public string Name { get; set;}
    public BuyItem(Item item)
    public ReturnItem(Item item)

Today, most apps separate the Domain Model into its constituent data fields and data access calls. POCOs (Plain Old CLR (or C#) Object) contain primarily strongly-typed data fields and sometimes property attributes and a method or two. Typically, ViewControllers or Controllers house the business logic and handle data using data models.  This is an important point, but meanders away from our data access pattern topic. This article doesn’t cover the much-discussed MVC and MVVC patterns.

Back to the Domain Model and data access. All of our logic surrounding the processing of an Item is now  tucked into the Item class.  Unfortunately, that also includes the data access logic. So, once again, now we have business logic and data access logic that is tightly coupled. We require the same type of decoupling solution that Table Data Gateway offered us, but in the world of OOP. Enter the Data Mapper.

Data Mapper

A domain object-oriented data access class is called a Data Mapper, which is an implementation of CRUD for a specific table or entity.

class void ItemMapper() 
    public Item Get(Id id)
    public void Put(Item item)
    public void Update(Item item)
    public void Delete(Item item)

This Data Mapper, called ItemMapper, is the data access component for the Item Domain Model. Now the Item class discussed earlier can contain only business logic and make data calls to ItemMapper. We have appeased the great god SOC (Separation of Concerns).

Data Mappers typically handle only single objects, not collections. If you want to return and handle collections you’ll need a to use a Repository pattern.


The most common choice for a data access pattern by Xamarin developers in their apps, a Repository for a Domain Model is basically a Data Mapper for a collection, such as ItemRepository for Items.

class void ItemRepository
    public List[Item] GetAllItems();
    public void PutAllItems(List[Item] items);

Using Domain Models, Data Mappers, and Repositories in this way will result in a pile of class pairs like Item and ItemMapper (or ItemRepository), Person and PersonMapper, Building and BuildingMapper, and Conversion and ConversionMapper.

So many Mappers (or so many Repositories)!

Some developers might be pleased with the elegance and OOPness of this architecture.  Others might think that it spreads the code out too much. Multiple Data Mappers and Repositories can smell of code duplication, so sometimes we want all of our Mappers available in one place. Creating a facade or an additional layer of abstraction over the mappers offers a single location where all data access can take place, which is divided behind the scenes to the appropriate data mapper. Filtering and code reuse all take place in methods to optimize the data access layer.

A simple Database Repository for the Item and Person classes might look like this.

Add this:

    public List[Item] GetAllItems()
    public void PutAllItems(List[Item] items)

to this:
class void Repository
    public Item GetItem(Id id)
    public void PutItem(Item item)
    public void UpdateItem(Item item)
    public void DeleteItem(Item item)
    public Person GetPerson(Id id)
    public void PutPerson(Personitem)
    public void UpdatePerson(Personitem)
    public void DeletePerson(Personitem)

The Repository is the OO version of the Database Mapper that we discussed earlier. It provides an app-wide location for all data access calls, but this time the calls employ the object-oriented Domain Model instead of procedures that execute some SQL and return record sets.  Repository methods call the appropriate Data Mappers, then filter and process the data that is returned.

class void Repository
    public Item GetItem(Id id)
    public void PutItem(Item item)
    public void UpdateItem(Item item)
    public void DeleteItem(Item item)
    public Person GetPerson(Id id)
    public void PutPerson(Personitem)
    public void UpdatePerson(Personitem)
    public void DeletePerson(Personitem)
    public List[Item] GetAllItems()
    public void PutAllItems(List[Item] items)

So that’s a Repository. Awesome. Study it closely. You’ll need this one.

Note: The definition of the repository pattern has evolved since its inception.  It was originally intended as an abstraction to decouple the data layer  implementation (for example, SQLite) from the rest of the app with the added benefit of providing in-memory data-object collections. Over the years, many C# apps needed the decoupling but not the in-memory data objects, so those collections have evolved to become data objects returned by methods in many cases, not persisted in repository properties. This is true in most mobile apps as well.

That’s the compleat data access story. Here’s the recap.


Pre-OOP we built coded everything in Transaction Scripts, code that made calls to procedures for everything. Then we divided code into Table Modules, organized by the data in our tables which contained both business logic and data access. Record ids were passed into these procedures and they returned record sets. Awareness of the importance of decoupling led to data layer code called Table Data Gateways which handled CRUD transactions for each table. Table Data Gateways were sometimes aggregated into facades, which I call Database Gateways, which handled all data access in the application.

OOP gave us the ability to do all of this using data models instead of record sets, which means a more powerful and more app-specific toolset for data access. Domain Models, like Table Modules, let us build entity-specific objects except that the actual data fields used.  Domain Models are data models combined with business logic. Loosely couple the data access from that business logic by making a Data Mapper, implementing of CRUD for a specific table for a single table or entity: Get, Put, Update, and Delete.  Even a few Data Mappers can create a confusing data access interface. Simplify with a Repository, which is a facade over top of all your Data Mappers, providing a single entry point for all data access without compromising SOC.

Most mobile app development uses a Repository of some kind.

Data Access Using Xamarin

What does any of this have to do with Xamarin development?

Here’s what: The SQLite.NET ORM has already created Data Mappers for us. Let me say that again. SQLite.NET is a big library of table-specific Data Mappers. SQLite.NET will return Item objects from the your Item table, Person objects from your Person table, etc., etc., assuming that you’ve mapped the fields correctly in your data models.

Creating a data access class (or classes) which uses a bunch of calls to SQLite.NET is often an implementation of the Repository pattern. Now we can code our mobile DAL in the context of design patterns that are familiar.

In a later post I’ll talk about how to use the Repository pattern to implement SQLite.NET in a Xamarin app.

How to Mobilize Web and Desktop Business Apps


If you’re a business with a suite of mobile apps, you have an advantage in the mobile game. You already have a product direction. You also have a technology foundation. The trick is determining appropriate directions for mobile apps which leverage these assets. What to mobilize?

1. Identify Candidates
Look first at your existing app suite, whether it’s desktop or web. Pinpoint areas that provide simple, easy-to-display feedback to the user. Look for important or frequently used:

  • Dashboards
  • Reports
  • Functionality

If you’re not certain about functionality, then focus on important junctures in your users’ workflow.  Seek ways to facilitate key decisions. Identify candidates for migration from your existing application suite.

2. Sell and Market
Some of the best apps are artful blends of key functionality, useful marketing collateral, and the sale of relevant products. Marketing collateral can include videos, images, and articles. Sales can include e-commerce, so the user can shop for themselves, or tactful, appropriate offers. Sales and marketing in an app can be useful and valuable to a user if it is carefully considered. Don’t just put in pitches and collateral that you think are slick.  Ask yourself: I’m a user and I’ve taken my valuable time to download this app. Does it give me what I need? Will I be amazed and delighted by it? Useful tools such as customized needs assessments, calculators, or interactive graphs can engage a user while stoking the sales process.

2. Consumption Not Production
Mobile device screens are smaller than their PC counterparts and the mobile experience is generally about speed, not depth. Many PC apps are 50% about viewing information and 50% about entering and interacting with it. PCs are production tools, built for helping their users produce information. Mobile devices are tiny media centers, built for easy consumption of information. Take what your apps are already doing and simplify it so that the user experience is closer to 80% viewing info and only 20% interaction, and make that 20% extremely easy on your user.  (and most mobile production seems to be of a social nature) Give them quick access to tons of your apps’ great content with as little effort on their part as possible.  Mobile users with their apps are mostly consuming (and communicating) not producing.

3. Leverage Existing Tech
Reuse of your databases and other back-end tech like stored procedures and APIs may help save your company a lot of time and money. Don’t assume that everything will have to be written from scratch. If you’re working from an existing system, it’s more likely that you’ll simply need an “adapter” from the old back-end to your new mobile one.

4. Innovate
Opportunities abound for innovation in mobile so don’t be afraid to go off script. Mobile apps are not always just tinier versions of web apps.  Innovation in mobile often has to do with taking advantage of unique phone capabilities, like GPS, camera, voice, integration with other systems and objects, real-time notifications and updates, or simply the fact that the user takes the device wherever they go.

You and your team will probably come up with dozens of ideas for great mobile apps.  Run them by your staff, and even by a few trusted users. Then pick the top three. Ask yourself which one of those would make your users ecstatic and commit to it.  Flesh it out. Build a prototype. Show it to your users and see what they say.

That’s how to mobilize.

Xamarin Dev Days 2016 Recap


Xamarin Dev Days happened in Boston!  Here are some pics from the event on Twitter.

I spoke about Xamarin.Forms 2.0 Effects, which are a lightweight approach to custom controls. Also, if you just need a real native control, you can now embed native controls right into your Xamarin.Forms pages by adding them as children of a layout just like regular Forms controls.  Recycling cells in your ListViews for performance and memory usage improvements using ListViewCachingStrategy.RecycleElement. XAML is now compilable using the XAML compiler (XAMLC) for faster loading, smaller app size, and errors shown at build time rather than at run time (too late).  Themes extend styles with new ways to apply design to your entire app.

Jesse Liberty kicked the event off with an intro to Xamarin, covering the API for iOS and Android.  Gavin Bauman spoke about connecting your Xamarin app to the Azure cloud. Pierce Boggan led a hands-on lab. The event was organized by Pierce Boggan and Jayme Singleton (a killer last name in the software development industry).

Look for Xamarin Dev Days in your area.

Podcast Interviews with Dan Hermes: Microsoft, Xamarin.Forms, His Music and His Tiki Drinks

This past month I’ve been interviewed for two podcasts on a range of topics such as Xamarin, my book, the book tour, and a little bit about me personally.

  1. Yet Another Podcast #150

Technologist-of-note Jesse Liberty asks me insightful questions about these topics and more:

  • What might the Microsoft acquisition of Xamarin mean for developers?
  • What is the nature of Xamarin.Forms?
  • What were the questions that drove me to write my Xamarin book?
  • How should an experienced C# developer get started with Xamarin?

2. Away From the Keyboard

Cecil Phillip and Richie Rump ask me about my life outside of software. We talk about my music group and the CDs I’ve recorded, the relationship between music composition and coding, details about my Blue-fronted Amazon parrot named Chicken, and how to make tiki drinks – such as the perfect Zombie.


Xamarin.Forms 101: Pages and Layouts and Views (Oh My)

Pages, layouts, and views make up the core of the Xamarin.Forms UI. Pages are the primary container, and each screen is populated by a single Page class. A page may contain variations of the Layout class, which may then hold other layouts, used for placing and sizing their contents. The purpose of pages and layouts is to contain and present views, which are controls inherited from class View.



The Page class is the primary container of each main screen in the app. Derived from Xamarin.Forms.VisualElement, Page is a base class for the creation of other top-level UI classes. Here are the primary pages: ContentPage, MasterDetailPage , NavigationPage, TabbedPage, CarouselPage. 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.


Views are placed and sized by their container class, Layout. Layouts come in a variety of flavors with different features for formatting their views. These containers allow views to be formatted precisely, loosely, absolute to the coordinate system, or relative to one another. Layouts are the soft tissue of the page, the cartilage that holds together the solid, visible aspects of the page(views). Here are the main layouts: StackLayout, AbsoluteLayout, RelativeLayout, Grid, ScrollView, Frame, ContentView.

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 the next chapter. Xamarin.Forms layouts are derived from the View class, so everything contained by a page is actually some form of a view.


Views are controls, the visible and interactive elements on a page. These range from the basic views like buttons, labels, and text boxes to the more advanced views like lists and navigation. Views contain properties that determine their content, font, color, and alignment. Horizontal and vertical alignment is set by properties HorizontalOptions and VerticalOptions. Like layouts, views can be padded with space, sized to expand to fill available space, or shrunk to fit their content. Later in this chapter, we’ll code some views, then visit them again in Chapter 4 and throughout the book. These are the primary views grouped by function:

  • Basic – fundamental views: Label, Image, Button, BoxView
  • List – make a scrollable, selectable list: ListView
  • Text Entry – user entry of text strings using a keyboard: Entry, Editor
  • Selection – user choice of a wide range of fields: Picker, DatePicker, TimePicker, Stepper, Slider, Switch
  • User Feedback – notify the user of app processing status: ActivityIndicator, ProgressBar

Be careful not to confuse the Xamarin.Forms View class with a view meaning screen or presentation layer. Also, iOS refers to screens as views.

I devote an entire chapter dedicated to Pages, another to Layouts, and another to Views in my book, Xamarin Mobile Application Development. Whether you read my book or check out the Xamarin online docs and Xamarin MVP blogs, educating yourself is how to make Pages and Layouts and Views less scary and working hard for you in your own apps.

Get started with the free C# and XAML book examples on GitHub.

Dig into the Xamarin.Forms toolkit and own it.

Xamarin Navigation Design Patterns

Navigation gives a user what they need to get around an app quickly, moving from screen-to-screen with confidence and ease. This may include menus, tappable icons, buttons, tabs, and list items, as well as many types of gesture-sensitive screens to display data, information, and options to the user.

Navigation patterns are industry-standard templates for tying an app’s screens together in an elegant and usable way. The two most common visual design patterns in mobile navigation are hierarchical and modal. Out of these base navigation patterns come an entire family of derivative patterns which combine, enhance, and decorate these patterns to create the full range of mobile UI patterns available. Here is an exhaustive list of the most common mobile UI navigation patterns used in Xamarin development:

  • Hierarchical – a stack-based navigation pattern where users can move deeper into a screen hierarchy, then back out again one screen at a time using the up or back buttons
  • Modal – a screen which interrupts hierarchical navigation, often a pop-up screen with an alert or menu which the user can complete or cancel
  • Drilldown List – a list of tappable items selected to display item detail
  • Navigation Drawer – a navigation menu which slides over from the left side at the tap of an icon, typically three horizontal lines in the upper-left part of the screen known as the “hamburger”
  • Tabs – a bar containing several folder-like tabs at the top or bottom of the screen each with tappable icons or text invoking new pages
  • Springboard – also referred to as a dashboard, this is a grid of tappable icons invoking new pages
  • Carousel – horizontally-slidable screen-sized panels, sometimes containing large images

Let’s explore two of the most common navigation patterns, hierarchical and modal.


Hierarchical is a stack-based pattern where users can move deeper into a screen hierarchy, then back out again one screen at-a-time using the Back or Up button. This typically involves a toolbar at the top of the screen which displays an up button in the upper-left corner of the screen when a page is selected or “drilled down into” by any means. As the user drills deeper into the menu structure, a stack is maintained with each page pushed onto it. Two buttons are used in tandem to navigate backwards, popping pages off of the stack: the up and the back button.  The back button is the curved arrow icon on the bottom of the screen, although iOS doesn’t have one. The up button is the “less than” icon in the upper-left corner. Deep navigational stacks can be traversed in this manner with page selection requiring the use of additional UI navigation patterns such as the navigation drawer, drilldown list, or popup menu.


A Modal is a single, interruptive popup or screen which comes in two flavors. The most common type floats overtop the main page and is usually an alert, dialog, or menu which the user can respond to or cancel.  Navigation reverts back to the originating page when the modal is dismissed. A modal informs the user of some important event, such as a saved record, or gives them the opportunity to provide input or direction, such as a menu or whether to commit or cancel a transaction. The second, less common, type of modal replaces the main page entirely, interrupting the hierarchical navigation stack.

The two most common modal menus in the mobile UI are the Navigation Drawer and the Action Menu. The Navigation Drawer typically slides in from the left and is triggered by the tapping of an icon in the upper-left corner of the screen (usually “the hamburger”) and displays a list of pages to navigate to.  The Action Menu typically slides in or pops up on the right side of the screen, and is invoked by tapping an icon in the upper-right corner of the screen (usually three vertical dots) and contains mostly operations (ex. Favorite This), though less frequently some navigation pages as well.  To follow this established UI pattern, remember the rule: Nav on the left, action on the right.

Hierarchical and modal UI navigation patterns are typically used as complementary techniques with hierarchical providing the skeleton of the navigational structure and modals giving the user choices for what they want to do and where they wish to go within the app as well as informational updates along the way.

Xamarin.Forms provides most of the primary navigation patterns out of the box:

  • Hierarchical navigation using NavigationPage
  • Modal using NavigationPage, alerts, and ActionSheets
  • Drill-down lists using NavigationPage, ListView, and TableView
  • Navigation drawer using MasterDetailPage
  • Tabs using TabbedPage
  • Springboard using images with gesture recognizers
  • Carousel using CarouselPage

I hope that’s enough to get you thinking about navigation in your own apps. In my book, I explore hierarchical, modal, and the rest of the navigation patterns on each platform. The navigation chapter in the book is really one its crown jewels, providing you with patterns to build just about any app you can imagine! If you want to check out the navigation patterns in code, head over to GitHub and look at chapter 6. You can use that code to lay the groundwork for just about any business app!

In last week’s post I covered the Drilldown List pattern. In upcoming posts, I’ll talk about more of the the key navigation patterns in detail.


Navigation Patterns: Drill-down Lists

A drill-down list is a list of tappable items selected to navigate to a new page.


There are many ways to build them using Xamarin.Forms, and the following recipe covers the most common type: by item. Other common types include lists by page and grouped lists.

A drill-down list by item has rows that can be selected to display more information about each item: the traditional master-detail pattern. This recipe uses a ListView to bind to a data model to provide a dynamic list of tappable items. A grouped drill-down list built using TableView is useful for creating categorized static menu items but ListView is one of the most versatile tools for creating drill-down lists. Short lists can, of course, be constructed by hand by using any of the layouts filled with buttons or labels paired with gesture recognizers to handle taps. Longer lists lend themselves to data binding using ListView.

Many lists contain a bunch of items that a user wants to drill down into to reach details about each item. Use ListView to display a list of items data-bound to a data model, and then show a detail page by using
PushAsync , all wrapped in NavigationPage so the user can get back to the list. You can create your ListView using the standard Xamarin.Forms approaches, such as in my post Making a Scrollable List Using ListView. This implementation uses a list item class called DrilldownListViewByItem.

Instantiate the DrilldownListViewByItem page in the Application class’s constructor wrapped in NavigationPage.

public class App : Application
    public App()
        MainPage = new NavigationPage(new DrilldownListViewByItem ());

This creates the a list with a navigation bar on iOS and Android. Windows Phone doesn’t display the navigation bar.

Create a detail page called detailPage whose constructor takes ListItem as a parameter. ListItem must contain either a list item ID for a detailed lookup query or all the fields needed to display on the detail page. This detail page displays a title and description.

class DetailPage: ContentPage
    public detailPage(ListItem listID) { // display detail }

Back on the list page (DrilldownListViewByItem) when an item row is tapped, pass ListItem into the detail page, which displays the detail of that particular item.

listView.ItemTapped += (sender, args) => {
    var item = args.Item as ListItem;
    if (item == null) return;
    Navigation.PushAsync (new detailPage(item) );
    listView.SelectedItem = null;

Tapping a list item row triggers the ItemTapped event, and the PushAsync call instantiates a detailPage and passes in ListItem to display.


You can see the complete book example on GitHub here.

The Drill-down List by Page pattern lets you select a ContentPage then instantiate it when it is tapped. Add a page type property to the list model and navigate to the page using the Activator.CreateInstance method.

Page page = (Page)Activator.CreateInstance(item.PageType);

Check out the book code here for the Drill-down List by Page recipe.

Making a Scrollable List Using ListView

Choosing quickly from a long list of items is one of the key offerings of the mobile UI. The limited real estate on mobile phone screens makes data grids a challenge and leads to extensive and creative use of lists. Grouping of items, scrolling, gesture-sensitivity, and images make lists one of the most versatile and reuseable data-bound tools available. Lists are to mobile development what the data grid is to web development.

Binding ListView to a data model is made easy in Xamarin.Forms through the use of ListView’s built-in adapter called ItemTemplate. Prepare your data model class and assign it to the ListView.ItemsSource property. Then bind each property of your model to the list using the ItemTemplate.SetBinding method.

Create a data model, or custom class, containing the list items. Call it ListItem.

    public class ListItem {
        public string Title { get; set; }
        public string Description { get; set; }

Populate it and point the ListView’s ItemsSource property to it.

    listView.ItemsSource = new ListItem [] {
        new ListItem {Title = "First", Description="1st item"},
        new ListItem {Title = "Second", Description="2nd item"},
        new ListItem {Title = "Third", Description="3rd item"}

Format list rows using ItemTemplate. Create a DataTemplate class and pass in the cell type to display. The standard cell type is TextCell, which will display a title for each row plus some detail text which you’ll add in a minute. Specify the property to display as the main row text by assigning it to the TextProperty of the list, in this case Title.

    listView.ItemTemplate = new DataTemplate (typeof(TextCell));
    listView.ItemTemplate.SetBinding(TextCell.TextProperty, "Title");

This will display the same list but from custom class ListItem instead of a List of Strings. No additional adapter needed!


Add a descriptive line of text to each row by binding the DetailProperty of the TextCell.

    listView.ItemTemplate.SetBinding(TextCell.DetailProperty, "Description");

This binds the Description property of the ListItem class to the DetailProperty of the TextCell.


TextCell’s font color can be set using its TextColor property and the detail font color can be set using the DetailColor property.

    var template = new DataTemplate (typeof(TextCell));
    template.SetValue(TextCell.TextColorProperty, Color.Red);
    template.SetValue (TextCell.DetailColorProperty, Color.Blue);
    listView.ItemTemplate = template;

When handling the item selection, remember to use the data model.

    listView.ItemTapped += async (sender, e)
        ListItem item = (ListItem)e.Item;
        await DisplayAlert("Tapped", item.Title.ToString() + " was selected.", "OK");
        ((ListView)sender).SelectedItem = null;

That’s how to build a basic ListView bound to your data model!

See the complete example on GitHub here.

Tap Into Clickable Images with GestureRecognizer

Tappable images and icons are common in mobile applications for actions and navigation. Like many Xamarin.Forms views, the Image doesn’t have a click or tap event and must be wired up using the GestureRecognizer class. A gesture recognizer is a class that can be added to many views to respond to user interaction. It currently supports just the tap gesture. The terms click and tap are used interchangeably in mobile UI development.

First we need to start with an image on our ContentPage. The Image view holds an image for display on your page from a local or online file:

    Image image = new Image
        Source = “monkey.png”,
        Aspect = Aspect.AspectFit,
        HorizontalOptions = LayoutOptions.End,
        VerticalOptions = LayoutOptions.Fill

This is part of a larger example which shows the monkey image at the bottom right.


Now for the gesture recognizer.

Declare the gesture recognizer and a handler to create and manage the Tapped event, then the gesture recognizer is added to the target view, an image in this case. Change the image’s Opacity to .5 in the handler, which will fade the image slightly when tapped.

    var tapGestureRecognizer = new TapGestureRecognizer();
    tapGestureRecognizer.Tapped += (s, e) => {
        image.Opacity = .5;

Give that a try  so you can see that the gesture recognizer works.

An alternative implementation of GestureRecognizer uses the Command property.

    image.GestureRecognizers.Add (new TapGestureRecognizer {
       Command = new Command (()=> { /*handle tap*/ }),

User feedback is a crucial concept in mobile UI development. Any time a user does something in the UI there should be some subtle acknowledgment by the app. A tap, for instance, should respond to the user with visible feedback. Usually an image will gray out or have a white background for a sec when touched. Let’s do that professionally using the image’s Opacity property but adding async/await to create a slight delay in our fade without affecting the app’s performance.

Replace the Tapped handler with this one that will cause the image to fade slightly for a fraction of a second. Remember to add using System.Threading.Tasks; to the top of your file for async/await.

  tapGestureRecognizer.Tapped +=  async (sender, e) =>
            image.Opacity = .5;
            await Task.Delay(200);
            image.Opacity = 1;

Tapping on the image will now fade the image slightly, then back to normal, providing a responsive user experience.

In your own projects you’ll use gesture recognizers (and async/await) to actually do something when an image is tapped. If you want to see async/await in action in this example, bump up the Delay to 2000, then try and do something else in your app (like tap another button, for example) and and you’ll see that the app is still responsive. You could do many things in this Tapped handler without interrupting the flow of the app. Often when a button or image is pressed, the result should be backgrounded using async/await for an optimal user experience.

Check out this free GitHub example here. Check out my book that all this is based on here.