I’ve updated InTheHand on NuGet and added the accompanying library containing UI functionality (InTheHand.UI). The main shared piece of functionality here is the MessageDialog (ala Windows.UI.Popups) and this works across all the Windows platforms (Including Windows Phone Silverlight) and iOS and Android. The appearance of the dialog is as the native experience with one exception…
We noticed on Windows 10 that the appearance of MessageDialog changed for our 8.1 app, rather than being a band across the width of the screen it was now a true floating window in its own right but this had one negative aspect – the title text appeared twice on the dialog. Users reported this as confusing and there is currently no workaround directly. In UWP apps there is now a ContentDialog control which is used for popping up content with up to two action buttons (you may recall this from Windows Phone 8.1) and so our implementation wraps this API on Windows 10 Desktop while exposing a single MessageDialog API. To avoid breaking the API we currently fall back to the system MessageDialog if you use three Commands. You can see a taste of the various flavours below:-
The other functionality within InTheHand.UI is currently specific to Windows flavours and I’ll be discussing it in a future post.
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…
I’ve made a couple of steps forward with the Charming project:
1. I’ve added a new library for Windows Phone 8.0 and 8.1 Silverlight to provide a “Universal Apps” style ResourceLoader for Silverlight (.resx) resources. It currently supports the default AppResources string table only but this is enough in most cases to reduce your #ifdefs a little where you are sharing code between a Silverlight phone app and a Windows Store app. It could also be useful to help move an existing Silverlight app to the new runtime model in stages.
2. I’ve changed the license on the project to the MIT license which is even less restrictive than the previous Microsoft license. While this is currently showing on the project site it won’t be reflected in NuGet until each of the packages is updated.
3. I’m still looking into the Windows 10 SDKs to see which bits are still relevant going forwards. Despite the core Universal App Platform there are still different APIs on Phones and PCs where it might still be necessary to bridge the gap.
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 (http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx). 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…