Programming

The future of Xamarin Forms

Oliver Brown

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.

My second through fifth contributions to Xamarin Forms

Oliver Brown

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.

ListView improvements in Xamarin Forms

Oliver Brown

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…

This is an imported post and may not be formatted correctly. View the original here.

Tic-tac-toe Collection open beta

Oliver Brown

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.

This is an imported post and may not be formatted correctly. View the original here.

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

Oliver Brown

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}" />

Visualizing Gravity

Oliver Brown

Unity has a pretty cool feature called “gizmos”, that are things rendered only in the scene view of the Unity editor. Many built in game object types render a gizmo of some sort, but you can freely add your own. This can be very useful for debugging. This is a visualization of the gravity (more precisely it’s the low resolution grid of gravity mentioned in the previous post). The direction of the line is the direction of the gravity, and the length is the strength.

This is an imported post and may not be formatted correctly. View the original here.

The Gravity of the Situation

Oliver Brown

Interacting with this video is done so under the Terms of Service of YouTube
View this video directly on YouTube
The most important feature in Gravitas is clearly the gravity, so getting it right is crucial. One important principal to be aware of when making games though is that “right” doesn’t necessarily mean “technically perfect” or “scientifically accurate”. “Feeling right” and being fun to play with is often more important. Despite that, the gravity in Gravitas is essentially correct. By correct, I mean a numerical approximation of Newton’s law of universal gravitation. The formula for calculating the gravitational force between two masses is: 0f36df929ac9d711a8ba8c5658c3bfee where:

  • F is the force between the masses;
  • G is the gravitational constant (6.674×10−11 N · (m/kg)2);
  • _m_1 is the first mass;
  • _m_2 is the second mass;
  • r is the distance between the centers of the masses.

For simplicity and performance reasons, there are a few things to be aware of though. Firstly, I decided not to worry about real world units since the planets, ships and torpedoes are not realistically scaled to each other (either by size, mass or distance from each other). This means I can decide that my torpedoes have a mass of 1, thereby eliminating a multiplication for the most common case. This also means I can choose the value of G to be whatever looks or feels right. This is still quite a significant calculation that has to be performed every frame for every torpedo/planet pair. As it turns out though, the maximum number of torpedo/planet pairs is quite low. Based on the limits of the previous version of Gravitas, there were at most 9 ships, firing at most 3 torpedoes, with at most 11 planets. This means 9 × 3 × 11 = 297 times to calculate the strength of the gravity each frame. In practice I don’t think I ever so that many torpedoes (every ship using a triple-shot special power at once). But then I wanted to add dust. By dust, I mean a trail from the torpedoes, that is also affected by gravity. At a minimum this should generate one particle per frame and be at least a couple of seconds long at normal torpedo speed. This means each torpedo could easily have a hundred dust particles all needing the same gravity calculation. All of a sudden there could be 300,000 gravitation calculations per frame. On my laptop it ran fine. On my phone, not so much. There are a number of possible ways of solving this issue, but the one I settled on is based on the principle that accuracy of simulation of the dust particles (as opposed to the torpedoes) is not so important. That is, if the dust particles don’t behave perfectly, it doesn’t really matter. One thing to notice about the gravity is that the only dynamic data it depends on is the position of the dust. The mass of the dust is fixed, and the position and mass of the planets are fixed (at least per round). My solution was to pre-calculate the strength of gravity on a dust particle for all the positions in a low-resolution grid. This means I can “calculate” the gravity by doing a relatively cheap lookup.

This is an imported post and may not be formatted correctly. View the original here.

[SOLVED] The BindableProperty "Triggers" is readonly

Oliver Brown

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>

This is an imported post and may not be formatted correctly. View the original here.

Gravitas approaching playability

Oliver Brown

Interacting with this video is done so under the Terms of Service of YouTube
View this video directly on YouTube
Gravitas is rapidly approaching something playable, now that ships can be destroyed and new levels are generated. “Something playable” is still quite far away from being an actual game. In terms of features required for even an alpha release, it still needs: scoring, match state, player lobby, AI, and better level generation. Some other features I would rather have but aren’t strictly required include: special powers (especially warping, to get players out of impossible situations), better UI feedback for touch controls (which was not necessary for the original) and some match options. But overall, progress is good.

This is an imported post and may not be formatted correctly. View the original here.