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.
Recently I open-sourced a number of Compact Framework projects and when I was working on re-writing an application which used them as a Windows Runtime app I started to think about how much of the code might be useful for app projects. Obviously the API surface for Windows Runtime is totally different to the .NET Compact Framework. In some cases functionality which I wrote is built into the runtime, in other cases I’d made use of P/Invoke to call native APIs which is not an option. However one thing I noticed was that the Windows.Devices.Geolocation namespace which supersedes System.Device.Location was missing one key feature – a built in method to determine the distance between two points. Since I had code for this which was using the same method as the .NET framework I thought this was a prime candidate for migration.
The Windows Runtime is a rather more complex API and whereas .NET had a single GeoCoordinate type the runtime has BasicGeoposition (containing raw latitude, longitude etc) and a number of other types – Geocoodinate, Geocircle, Geopoint etc I decided to first implement an extension method which would work with two BasicGeopositions and then as a helper added an extension method for Geocoordinate which used the logic from the first.
The methods now live in a new NuGet package currently supporting Windows 8.1 and Windows Phone 8.1 – Charming Geolocation and the code will be available in the Charming project. Just add:-
and you can use the GetDistanceTo methods.
Part of the project using this code required an iOS implementation too for which I’ve used Xamarin. Anyone who has used this will know that while the location functionality is similar to what we are familiar with on Windows the API is significantly different. Because I wanted to fix that just the once too I wrote a wrapper API to expose the Windows API wrapping all the CoreLocation stuff. I’ll be adding this library to the NuGet package shortly and am also in the process of moving all the Charming code from CodePlex to GitHub too.
I’ve been working on a Windows Phone 8.1 project which has several background tasks. One of these uses the device’s sensors – using a DeviceUseTrigger. This is different to how a regular periodic task works because the task implementation creates a deferral and keeps running handling the event generated by the sensor device until it is explicitly cancelled. The task is created normally with a class implementing IBackgroundTask and runs under the context of BackgroundTaskHost.exe. Because I wanted to share some data with the other tasks as a when they run I was interested if these other IBackgroundTask implementations were also hosted in the same process. If so this means that any static instances would be shared between them. Since I couldn’t find the answer I did some testing with some additional debugging and discovered that no, they each run in a separate process.
This lead me to explore how to share data between them. There are no built in IPC classes in the Windows Runtime like MessageQueues or similar so really the only options are the LocalSettings for individual setting values and files placed in the LocalFolder for any other data. The added complication here is that you have to handle the situation where both processes may try to read/write the file at the same time. Luckily you can use a named Mutex to enforce exclusive access to the file and have the other process wait on the Mutex.
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…
Last Year Michel blogged about a binary incompatibility introduced in the May 2014 update of Compact 7 which broke existing Silverlight for Windows Embedded code including pre-compiled system apps.
The XAML In The Hand library was also affected. It turns out that one of the breaking changes was the addition of the GetTemplateChild method to the IXRControl interface. Previously this was present in the Compact 2013 codebase but not Compact 7.By adding a method to an existing COM interface (breaking the rules of COM again) means that the vtable offsets of all the methods in interfaces which inherit from this one are all shifted by one. Our next update will incorporate a fix for this (as well as exposing the GetTemplateChild functionality to the managed API) and will support Compact 7 from the May 2014 update onwards. The current released version of Compact 7 is the November 2014 update.
In order to extend the app onto Windows devices I’ve re-written the Calendar Import app as a Universal app with separate UI and features for Windows 8.1 and Windows Phone 8.1. Both apps add the new feature of browsing for files to import from directly within the app itself. This is on top of the existing filetype support which means you can import an item directly from your Email attachments, Web Browser, NFC, Bluetooth etc
Switching to a Windows Phone 8.1 project also means there are other new features we can support in upcoming releases. Users with a Windows Phone 8.0 device will continue to receive the 1.8 version until their device is updated to 8.1.