Android, Programming, Technology, Xamarin

The future of Xamarin Forms

Microsoft have just announced the future of Xamarin and Xamarin forms – the .NET Multi-platform App UI (or MAUI for short).

As a name, it’s not great.

The highlights are as follows:

  • It’s an evolution of Xamarin Forms. It basically is Xamarin Forms, but finally accepting some breaking changes. To be honest, I’m hoping for a lot since there is a lot of weirdness in Xamarin Forms that has been holding it back.
  • Single project, multi-targeted. It took a long time to get to the point where this was possible. From shared projects, to PCL projects, through .NET Standard. This should make things a lot easier.
  • Still based on platform renderers using native controls. This is a mixed bag. Using native controls has long been a selling point of Xamarin (with or without Forms). With the rise of Flutter this has been shown to be less important. Many people have been asking for consistent platform agnostic renderers instead.
  • The end of “Xamarin” as a name. Some time in the .NET 6 timeline (end of 2021) Xamarin.iOS will become .NET for iOS and Xamarin.Android will be .NET for Android. I have mixed feeling about this since this was a fairly succinct way to describe by top skillset.

I also already have my own enhancement issue submitted.

Programming, Xamarin

My second through fifth contributions to Xamarin Forms

Xamarin Forms took part in Hacktoberfest, an effort to increase contributions to open source. Like my previous contributions, three quarters of my PRs were targeting macOS. The main reason is the changes were straightforward (which makes it more disappointing how long some of the issues have been around).

I would like to say I wasn’t doing it for the t-shirt, but that wouldn’t really be true. I wouldn’t do it just for stickers though.

Programming, Xamarin

ListView improvements in Xamarin Forms

Since becoming open source, it has become possible to find out potential upcoming features in Xamarin Forms by just poking around the active branches in the repository (macOS support was visible in the repo before any announcement).

One of them is lv2spike.

From just reading the commit messages, it seems this is a new CollectionView, based on UICollectionView for iOS and RecyclerView for Android.

This is something that has been needed for a while, but is a big enough undertaking that I understand why it has taken a while. After all the branch suggests this is still just a spike.

There are quite a lot of feature requests for the Xamarin Forms ListView that are just not possible (like this one for horizontal layout) mainly because the iOS implementation is based on UITableView. This will open lots of possibilities. My biggest concern is that despite the push forward with features, Xamarin Forms is accruing bugs even faster, and with the expanded platform support this could just get worse…

Android, Entertainment, Games, Programming, Xamarin

Tic-tac-toe Collection open beta

For various reasons I decided to write a Tic Tac Toe game in Xamarin Forms.

At the moment it supports variable board sizes, variable win line size (so it implicitly supports Gomoku) and a few custom rules like misère, a pie rule and disallowed overlines. It currently functions on Android, iOS and Windows, but is only released on Android for now.

Apart from experimenting with various features of Xamarin Forms (as well as managing Nuget packages), my goal is to try and add all the options. Features I’m planning:

  • Ultimate Tic-tac-toe
  • Quantum Tic-tac-toe
  • 3D (and 4D) Tic-tac-toe
  • Online multiplayer
  • Order and chaos
  • Wild Tic-tac-toe

Download Tic-tac-toe Collection from the Google Play Store.

Programming, Xamarin

[SOLVED] Unable to cast object of type ‘Xamarin. Forms. Xaml. ElementNode’ to type ‘Xamarin. Forms. Xaml. ValueNode’.

When writing XAML for Xamarin Forms, you may across the error:

Unable to cast object of type 'Xamarin.Forms.Xaml.ElementNode' to type 'Xamarin.Forms.Xaml.ValueNode'

This is nearly always caused by assigning a value to an event in XAML, instead of specifying a method name.

A common example is:

<Switch Toggled="{Binding IsToggled}" />

Toggled is the name of an event. The property that was probably intended is called IsToggled.

<Switch IsToggled="{Binding IsToggled}" />

Android, Programming, Xamarin

[SOLVED] The BindableProperty “Triggers” is readonly

TLDR: When setting the Triggers property in XAML, use the actual type of the parent tag, not a supertype.

After recently updating Xamarin Forms from 2.3.2.127 to 2.3.3.175, I started getting an InvalidOperationException: The BindableProperty "Triggers is readonly" inside InitializeComponent.

Unlike many problems, this was quite easy to track down. InitializeComponent errors are generally XAML, and in the page in question there was a single Trigger. In this case the solution was simple. The Trigger was on a custom Button type, but I was setting it specifically using Button.Triggers. Changing it to be the actual type fixed it.

So, I changed it from

<local:MyButton>
  <Button.Triggers>
    <DataTrigger ... />
  </Button.Triggers>
</local:MyButton>

to

<local:MyButton>
  <local:MyButton.Triggers>
    <DataTrigger ... />
  </local:MyButton.Triggers>
</local:MyButton>

I believe the original should be valid (and previously was) but the change is simple enough to not be a big problem.