ListView Adventures – Auto-sizing Uneven Rows

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.


The XAML for this view looks like this:-

<ListView ItemsSource="{Binding}" HasUnevenRows="True" BackgroundColor="LightGray" SeparatorVisibility="None">
    <Frame Margin="20,10" HasShadow="True" CornerRadius="10">
     <Label Text="{Binding}"/>

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.

[assembly:ExportRenderer(typeof(AutoViewCell), typeof(AutoViewCellRenderer))]
namespace InTheHand.Forms.Platform.iOS
 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.


Xamarin Release 7 Moved my Cheese/Apple

I have a Xamarin project which outputs Windows, iOS and Android apps. Since the latest Xamarin update I just couldn’t get it to build my IPA file. It told me to check the project configuration – I haven’t changed the configuration and it all looks fine…

When the project was created several Solution configurations were created – AppStore, AdHoc along with the usual Release/Debug. This was always a pain as you’d have to switch from Release to AppStore to build the iOS version for release. It turns out what has changed in this release is that Release now builds a store-ready IPA file and the AppStore configuration is now broken (and therefore redundant). By switching to Release I was able to build and submit a signed IPA to the store. The only other change is that IPA files are now output into timestamped subfolders on the build machine. You can use the “Show IPA file on Build Server” to display the actual location in Finder.

Charming Storage Update

I’ve just released an update to Charming Storage on NuGet. After a lot of use in Windows Phone 8.1 projects I’ve reworked the TryGetItemAsync StorageFolder extension method to improve the performance. On average it is now takes 1/4 of the time to retrieve file items. Interestingly in Windows 10 this API becomes part of the Universal contract so it will be available on all platforms going forward.

The other change in this release is the addition of a Xamarin iOS library. This includes a LocalSettings implementation for iOS apps. This means that rather than messing about with NSUserDefaults on iOS you can write the same code across Windows and iOS apps. We’ve got a few other “Universal” APIs for iOS and Android on the way…

iRAPP Remote Desktop

Firstly, just to clarify, I don’t rap – this is a post about a useful Remote Desktop server for OSX. Wait, I hear you cry, you’re a Windows developer! Well that is true but I also use Xamarin to produce apps for iOS and Android and to build and deploy iOS apps you have to have a Mac in your workflow. Xamarin have done a great job to minimise this – you can do your development in Visual Studio on your PC but you have to connect to a Mac running their Build Server and you need to use the Mac to deploy apps to the iTunes store.

Because it was only for occasional interaction I don’t want the Mac Mini (which is a very nice looking piece of hardware BTW) setup with a Keyboard/Mouse/Monitor taking up space so it’s running as a headless device. I originally used TeamViewer to occasionally connect to the device but randomly last month the PC client started crashing on load and even an uninstall/reinstall wouldn’t get it working again so I looked for an alternative. I came across iRAPP by CodeRebel. I’d not heard of it before but it seemed perfect – it’s a Remote Desktop provider supporting Microsoft’s RDP protocol which means you can connect using the standard Windows Remote Desktop app. The app is available for Windows, Windows Phone, Android, Mac and iOS and since I use other Windows machines I have it installed on every device I use. By installing iRAPP on my Mac it just works in my Windows environment with no hassles. I found it very reliable over the trial period and have just purchased a license – $79 for a year and even that process is straight-forward and just works. Purchase the license online and click Update License from the iRAPP control panel and boom it’s up and running again!

There is also an iRAPP client for Windows which adds an extra dimension – it allows you to “blend” your desktop – switching to it adds the OSX menubar and dock to your desktop and will open apps in windows transparently on your desktop so you can feel like you are running OSX applications side by side with your Windows applications. Fun stuff but I didn’t really need this.

If you’re interested take a look here – There’s no ulterior motive here – I’m not receiving a commission or anything, I was just really impressed by the product and it’s proved reliable and useful.

Get battery level on Windows and iOS

In Windows Phone 8.1 a new API was added to both retrieve the current battery level as a percent of fully charged and also handle an event fired when the value changed. Sadly this API is not common across this and “big” Windows.

In a couple of projects I’ve needed to retrieve the battery level periodically so that the app can perform different actions depending on the device state. This encouraged me to “port” the API to Xamarin iOS which does provide the same capability but in a platform-specific way through UIDevice. When it came to Windows 8.1 there was an interesting problem. There is a native API you can call to query the battery level, however you can’t call it from within an app you submit to the public Windows store because the API is not on the Whitelist ( For my initial use this was okay because the app was to be privately distributed. Sadly I don’t have a solution for a Store app. You may have seen various Store apps for battery which get around the problem by asking you to install a desktop “service” which retrieves the value  and passes it to the store app. Why the API was not added to Windows 8.1 at the same time as Phone 8.1 is odd with the big push on “universal apps”, at the bare minimum the native API should have been whitelisted. It returns no identifiable information and is read-only. There are plenty of more malicious things that could be done via supported APIs…

Given the caveat mentioned above I decided to release my code in case it is of use to others. The iOS version is fully functional and can be use for public apps. An Android implementation will follow in due course…