The Xamarin Forms ListView control has a tough job – it has to provide a platform agnostic, rich data-bindable control and yet take advantage of the performance and look-and-feel of the native control on each platform. I recently discovered an odd gotcha for a specific usage. It’s possible to have rows with different heights. There are a number of reasons you might want this, the simplest would be the case where you have multiple item templates to represent different types of item. A slightly more interesting scenario is a chat application. In this case you want each row to use the right amount of space for the message but you can’t hard-code specific row sizes. You need a template which you can measure and get an accurate height for that specific item obeying all the margins and spacing you’ve setup. As it turns out this doesn’t work on iOS and it is documented if you know where to look.
The solution is to add some extra logic and this can of course be done by writing a custom renderer. Since there is a performance overhead in building the list item and measuring each one you only want to do this in the case that you can’t hard-code a row height. To look at the out of the box behaviour see the first screenshot below. You can see some attempt has been made to resize the rows but they don’t actually fit the content correctly.
As you can see I’ve define a new type derived from ViewCell. I’ve done this so that my renderer won’t be used for all ListView items but only those where we need this functionality. The AutoViewCellRenderer then does some extra work on iOS to set the item heights at runtime based on the data filled template. On Android and UWP it just uses the built in ViewCellRenderer which behaves as you’d expect.
public sealed class AutoViewCellRenderer : ViewCellRenderer
public override UITableViewCell GetCell(Cell item, UITableViewCell reusableCell, UITableView tv)
ViewCell vc = item as ViewCell;
if (vc != null)
var sr = vc.View.Measure(tv.Frame.Width, double.PositiveInfinity, MeasureFlags.IncludeMargins);
if (vc.Height != sr.Request.Height)
sr = vc.View.Measure(tv.Frame.Width, double.PositiveInfinity, MeasureFlags.IncludeMargins);
vc.Height = sr.Request.Height;
return base.GetCell(item, reusableCell, tv);
It took a few goes to get this working correctly. First I checked if the vc.Height was -1, but found that this could be updated but still need re-measuring. Then I set upon the above which checks if the height matches the content and only if not calls ForceUpdateSize and measures again. This introduced a noticeable performance hit if called unnecessarily and this method could be called a lot when scrolling long lists. The result is the nicer looking:-
This is part of InTheHand.Forms and will be rolled into the next NuGet release. Because the platform specific dll contains the renderer you need to call InTheHandForms.Init() to ensure it is registered.
I’ve used the Xamarin.Forms Button in a number of projects and while it has slowly improved (adding support for images etc) it’s still lacking in a few areas. Recently I needed to add support for wrapping and truncation options and these are mysteriously absent from the stock control.
For inspiration I looked at the Label control as this has a LineBreakMode property which allows you to use a variety of truncation or wrapping modes. This seemed perfect and rather than re-invent the wheel I set about adding the same property to the Button. Both iOS and Android support these options via LineBreakMode and Ellipsize properties respectively. Along the way I found it was necessary to improve the logic on iOS for sizing to fit content and the InTheHand.Forms.FormattedButton was born. I was also able to use this opportunity to fix a niggly issue with the iOS button where it fitted the label to the full width of the button so if you used a background the text was jammed against the left/right edges which looks ugly.
It’s intuitive to use from XAML:-
<cc:MyButton LineBreakMode="WordWrap" Text="This is a wrapping button with no other special properties set just a single long descriptive text value"/>
While I prepare to refresh my main machine with Windows 10 Creator’s Update and the latest Visual Studio and Xamarin updates I thought I’d throw together a summary of open-source progress since I last blogged:-
Since the announcement of CodePlex’s upcoming retirement I’ve been moving projects across to GitHub. 32feet and my Compact Framework archive are now moved, there is just some tweaking to be done on the Wiki content for the former. I’m planning a blog post on the process I’ve used.
I’ve reworked the existing documentation site which was hosting the Pontoon documentation and it now also contains InTheHand.Forms and 32feet documentation. The Compact Framework stuff may follow but it depends on getting the dependencies setup just right for the help file builder.
Pontoon has had a number of enhancements. I’ve been refactoring the code to better handle the number of different platforms which are supported. This has also allowed me to identify gaps and fill some of them. Android now has InTheHand.Devices.Radios support for Bluetooth and the ability to launch any StorageFile with Launcher.LaunchFileAsync. macOS now has full support for local and roaming settings as-per iOS.
Recent versions of Xamarin include the Forms Previewer which generates a live representation of your XAML as it will appear on iOS or Android. I noticed one slight problem when working on my MediaElement control…
The Android renderer instantiates a MediaController object. This is a standard Android class but the Forms Previewer would throw an exception any time my control was placed on a page. The exception popup is not very friendly either – it truncates text and has no method to copy the text to the clipboard.
I needed a way to determine if the code was running in the Forms Previewer and to just fake it and not create the native control. This will render a grey box for the MediaElement which frankly is fine with me to get the layout right. It turns out that in the absence of an IsDesignTime equivalent property there is a simple way to tell if your code is executing in a real app or not – and it’s the same as Silverlight (remember that?). Simply check if Application.Current is null inside the OnElementChanged method. If there is a current application you can render the control normally, if Current is null then don’t call the code to create the control.
if (Application.Current != null)
// create native control here..
The iOS renderer also uses a native control (AVPlayerViewController) but doesn’t present the same issue so this workaround wasn’t necessary there.
I’ve just completed and passed the exam and am now a Xamarin-certified Mobile developer. Having been working with Xamarin since the days of Mono for Android and MonoTouch I should have probably have got around to doing this earlier. Now it’s done I can relax and concentrate on the important task of making a chocolate cake tomorrow! But first it’s time for a celebratory drink!