Dan Hermes appointed Microsoft Regional Director (RD)

Microsoft has bestowed upon me one of their highest honors for a non-Microsoft employee, They have offered me the role of Microsoft Regional Director (RD). I’m humbled and honored and very much look forward to making a difference in this new capacity. I won’t stop doing any of the things I do already: speaking nationally, writing articles and books, making video courses, and building killer apps with my team of Xamarin developers. As a Regional Director I’ll get to do even more for the community.

This does not mean that I work for Microsoft. Becoming an RD means that I’ve been appointed one of about thirty technologists in the United States who meet Microsoft’s standard of technical and business knowledge and practice to commend as a leader of the regional technical and business community. Here’s more about Microsoft’s RD program.

I’m grateful for the commendation and can’t wait to serve in this greater capacity. If you have any questions or there’s any way I can help you, please don’t hesitate to connect

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.

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.

Xamarin Book Available!


Over a year in the making, it’s finally here: my book, Xamarin Mobile Application Development, is now available on Amazon!

Developers and businesses looking to expand into the mobile space or to hone their existing mobile apps need a reliable way to approach cross-platform mobile development. The Xamarin platform provides that way.

This book is a hands-on Xamarin.Forms primer and a cross-platform reference for building native Android, iOS, and Windows Phone apps using C# and .NET. This book explains how to use Xamarin.Forms, Xamarin.Android, and Xamarin.iOS to build business apps for your customers and consumer apps for Google Play and the iTunes App Store.

Learn how to leverage Xamarin.Forms to optimize cross-platform development using the most common UI pages, layouts, views, controls, and UI patterns. Combine these with platform-specific UI to craft a visually stunning and highly interactive mobile user experience.

Explore solution-building techniques from starter-to-enterprise to help you decouple your functional layers, manage your platform-specific code, and share your cross-platform classes for code reuse, testability, and maintainability.

This comprehensive recipe and reference book, featuring over 200 C# code examples with downloadable C# and XAML (preview the code on GitHub here), addresses one of the most important and vexing problems in the software industry today: How do we effectively design and develop cross-platform mobile applications?

What you’ll learn:

  • How to build world-class mobile apps for iOS, Android, and Windows Phone using C#
  • How to organize your Xamarin code into a professional-grade application architecture
  • The latest Xamarin techniques for cross-platform UI using Xamarin.Forms
  • When and how to use platform-specific UI
  • Data binding, local data access, enterprise cloud data solutions, and building a data access layer for mobile apps
  • Cross-platform architecture and design to maximize portability and code reuse

This is book is for C# and ASP.NET developers, architects, and technical managers as well as many Android and iOS developers.