Developing with Microsoft technologies
27 Nov 2014

When coding a Xamarin Forms UI, Xamarin Sketches can increase your productivity to previously unattainable levels. Being able to see the UI in a phone simulator update while you edit the UI code, with a less than one second lag, is so much more productive than building, deploying, running and stopping your entire app over and over again.

Wouldn’t it be nice if you could keep on using Forms UI Sketches effectively throughout the entire lifetime of your app, not just at the start? It turns out that you can.

In this post I will show how you can use Forms UI Sketches while circumventing some of the current Xamarin Sketches limitations (Sketches does not yet support creating classes, e.g. for design data), so you can code Xamarin Forms data binding in Xamarin Sketches without using those error-prone strings for property names. You will get compile time checking on property names in Sketches and you can use the same Class.Property names and notation in your Sketches and in your app code.

The Result

To get started, grab this sketch source from GitHub (change the file extension from .sketchcs.cs to .sketchcs – I only added the .cs to make GitHub format the source as C#). The code contains inline comments explaining how to use the various features.

This is what coding data binding in this way looks like in a Sketch:

With the supplied regular expressions (you can find them in the Sketch comments), you can use Xamarin Studio’s built-in RegEx Toolkit (accessible through the Tools menu) to automatically convert data binding code back and forth between Sketch and App syntax:

Because you can now automatically convert Forms UI code to and from a Sketch, you can more easily keep using sketches throughout the lifetime of your app. Sketching Xamarin Forms UI is a great way to boost productivity, and it’s nice if you can benefit from that also after you sketch the initial prototype.

In a Xamarin Forms App the pasted code looks like this (shown running in the Xamarin Android player):

As the above screenshots show, the Sketch demonstrates how you can bind to nested complex objects: each Person object has a property that is a Name object, which itself has first and last name properties. The Sketch also demonstrates how you can use nested Tuples to have objects with an unlimited number of bindable properties in your Sketch design data.

How is this different from the Xamarin Tutorials?

If you are new to Xamarin Forms and/or Xamarin Sketches, you may wonder at this point what I am doing different here. To explain this, let me show how data binding is done in the Xamarin Forms introduction:

nameLabel.SetBinding(Label.TextProperty, “Name”);

This is not ideal, because you will not get a compile time error or even a runtime error if you make a typo in the string or if you change the name of the Name property later and forget to update a string somewhere. You also get no IntelliSense when typing the string, so lots of opportunity for errors there.

Because Xamarin Sketches does not (yet) support creating classes (see under “Known Issues” in the Sketches Introduction), you need to use Tuple<>() for bindable design data. And because Tuples have properties named Item1 through Item8, the above code must be changed in a sketch to something like:

nameLabel.SetBinding (Label.TextProperty, “Item2”);

Which is a shame, because this effectively prevents you from using sketches after you create the initial prototype UI. Having to change every line of data binding code, every time that you copy forms UI code to or from a Sketch, would defeat the purpose of using a sketch in the first place: the big productivity gain that you get from a UI that updates near real-time while you code.

However, using a simple BindName() helper and a trick with enums, you can now code the above line in a Xamarin Sketch, like this:

nameLabel.SetBinding(Label.TextProperty, BindName(Person.Name));

This code will give you compile time checking on the property name in a Xamarin Sketch.

Using the supplied regular expressions, all SetBinding() statements in a block of code can be converted back and forth between the above Sketch syntax and below app syntax, with a single click:

nameLabel.SetBinding(Label.TextProperty, (Person boundPerson) => boundPerson.Name);

This app syntax will also give you code completion with IntelliSense; no strings attached really is nice.

The enum trick

We still use Tuples to store design data in a Sketch, however the trick to get dot-notation in a Sketch is that we add the class names and property names as enums and values. So if we have this data class in the app:

public class Person
{
    public string Name { … }
    public string Description { … }
}

We add this in the Sketch:

enum Person
{
    Name = 1,
    Description
};

The = 1 ensures that Name will map to the Item1 Tuple property.

Overcoming the 8 field limit on Tuples

Tuples can only have up to 8 items, so sketching a form with a viewmodel that has more than 8 bindable properties while keeping the code identical between the project and the sketch poses a problem.

However, the BindName() helper has a solution for that: you can make the 7th item in a Tuple a nested tuple to add another 6 fields (for some reason using the 8th item for this does not compile in a sketch).

BindName() handles nested Tuples transparently, so for the shared project/sketch code it looks as if no limit exists on the number of bindable properties. The nesting process can be repeated at will, so you can prototype with any number of bound properties in your viewmodel.

How to share Forms UI code across sketch and app

In the example source, I marked two regions of code that are shared across the sketch and the app. One region is the list cell layout, the other is the page layout. Here is how those regions fit into a forms App:

As you can see, almost all UI code is shared across sketches and app views.

To keep the sketches under source control together with the views where they are used, you can add the Sketch for a Page view to your Forms project, using the same location and file name as the view. You can then edit the common code in Xamarin Studio, copying and pasting using the RegEx Toolkit:

Note that support for editing Sketches in Visual Studio and Windows is not here yet – but it is expected ‘soon’ J.

How to do this yourself

That’s simple, really. Just grab the sketch source from Github (change the file extension from .sketchcs.cs to .sketchcs – I only added the .cs to make GitHub format the source as C#). In the source you will find:

  • The source of the BindName() helper
  • Inline comments with Regular expressions to convert between Sketch and App binding code syntax
  • Inline comments on how to nest bound objects and how to use nested tuples to have unlimited number of bindable properties
  • Working code demonstrating the previous point
  • An example how to structure your code in common App/Sketch code blocks
  • Code for the example pictured in this blog post

Note that Android Player support in Sketches is still unstable; for now I recommend that you use the iOS Sketches as much as possible.

Once support for creating classes has been added to Xamarin Sketches, there is no need for the Tuple + enum + BindName + regular expression workaround; you can then simply create design data classes in the Sketch and bind to those, using the same syntax in both projects and sketches, e.g.:

SetBinding(…, (Person boundPerson) => boundPerson.Name)

Happy App-ing!

About the Author
Vincent Hoogendoorn is a hands-on .NET architect and a Xamarin cross-platform mobile veteran, working as lead mobile @ Workstreampeople. His areas of interest are Augmented Reality, Cross-Platform Mobile Development, Windows Azure, Solution Architecture and Software Factories.

Leave a Reply


*

captcha *