GeoFence and #WinRT API

For some reason I find myself doing some Windows Phone 8.1 development in Silverlight.. I know its a dead end and all the rest but I am working on a small app and Silverlight API was more mature at least for Windows Phone 8.1. One of the things I was adding was GeoFencing. GeoFencing was introduced to Windows Phone 8.1 WinRT API and some of it was exposed to Silverlight API (whoever made the decision on what APIs were available in WinRT and what in Silverlight needs to be shot.. at least made to feel real pain.

The way you set it up is you create GeoFence instances and add them.. System managed associated with your app. The app can access it from foreground or background.. nice right ? The constructor for GeoFence states that it requires IGeoshape along with an identifier at the very least.. IGeoshape is an enum which has possible values of Point, Circle, BoundingBox and Path. The constructor for GeoFence explicitly states now and again that the IGeoshape has to be a valid GeoCircle.. I know documentation can be wrong.. I mean why would you go through the hassle of create an Interface and passing it again if you enforce explicit type ?

I was wrong.. I tried it both the Silverlight and through WinRT API.. nope documentation is correct.. the API though designed well has shite implementation 😐 So what next ?

Well DIY. Here is my implementation.. Create a Rect instance with NorthWest X1, Y1 and SouthEast and X2 Y2 and monitor the change in geo position. Check if the new point is within Rect or not.. easy peasy.. well it works too.. Here is my implementation.


public class GeoMonitoringService
    Geolocator _locator = null;
    Dictionary<GeoSite, Rect> _locationRectangles = null;

    DataService _dataService = null;

    public event RoutedPropertyChangedEventHandler<GeomonitorStateChangedEventArgs> GeomonitorStateChanged;
    public bool lastState = false;

    public void Initialise(DataService dataService)
        _locator = new Geolocator();
        _locator.DesiredAccuracy = PositionAccuracy.High;
        _locator.MovementThreshold = 1;
        _locator.ReportInterval = Convert.ToUInt32(TimeSpan.FromSeconds(5).TotalMilliseconds);

        this._locationRectangles = new Dictionary<GeoSite, Rect>();

        this._dataService = dataService;

        if (this._dataService?.SiteDictionary?.Count > 0)
            foreach (var site in this._dataService.SiteDictionary.Values)
                Rect r = new Rect(new Point(site.Latitude1, site.Longitude1), new Point(site.Latitude2, site.Longitude2));
                this._locationRectangles.Add(site, r);

        _locator.PositionChanged += GPSPositionChanged;

    private void GPSPositionChanged(Geolocator sender, PositionChangedEventArgs args)
        var geoPoint = args.Position.Coordinate.Point;
        Point p = new Point(geoPoint.Position.Latitude, geoPoint.Position.Longitude);

        KeyValuePair<GeoSite, Rect>? matchKVP = null;
        foreach (var entry in this._locationRectangles)
            if (entry.Value.Contains(p))
                matchKVP = entry;

        if (matchKVP.HasValue)
            if (!lastState)
                lastState = true;
                this.GeomonitorStateChanged?.Invoke(this, new RoutedPropertyChangedEventArgs<GeomonitorStateChangedEventArgs>(null, new GeomonitorStateChangedEventArgs(true, matchKVP.Value.Key)));
            if (lastState)
                lastState = false;
                this.GeomonitorStateChanged?.Invoke(this, new RoutedPropertyChangedEventArgs<GeomonitorStateChangedEventArgs>(null, new GeomonitorStateChangedEventArgs(false, null)));

Coding4Fun v2.0.9 released #wpdev #windev #winrt

Coding4Fun toolkit v2.0.9 for Windows Platform dev has been released and packages are available for download from Nuget.

This update builds additional support for Windows Runtime on Windows Phone 8.1 and Windows 8.1. Controls added to this release include

  • MetroFlow control (Windows 8.1 and WP 8.1)
  • Prompts (Toast, User, Message, Input, PasswordInput) for WP 8.1
  • BrushToBrushConverter now allows use of parameter to set output Opacity.

AppBarPrompt requires additional work the port wasn’t successful first time around. For issues there’s codeplex.

Happy coding

WinRT and application view wide Pointer event monitoring #wpdev #windev

It seems like every year I go through same technical difficulties. Last year I blogged about WinRT and pointer manipulation #win8dev #winrtdev

One of the underlying classes detects manipulation by user by means of Touch class. This class never made it to WinRT XAML and I have been messing around for a few days now… until something finally sunk in..

CoreWindow exposes following events

PointerEntered Occurs when a pointer moves into the bounding box of the Windows Store app.
PointerExited Occurs when the pointer moves outside the bounding box of the Windows Store app.
PointerMoved Occurs when a pointer moves within the bounding box of the Windows Store app.
PointerPressed Occurs when a mouse button is clicked, or a touch or pen contact is detected, within the bounding rectangle of the Windows Store app.
PointerReleased Occurs when a mouse button is released, or a touch or pen contact is lifted, within the bounding rectangle of the Windows Store app.

These events work exactly like Touch.TouchFrameReported and get bubbled up no matter which UIElement is tapped.

Time to continue porting

Support for Windows Phone 8.1 WinRT for Coding4Fun

Earlier this year, I took the responsibility of ensuring that  Coding4Fun toolkit supported Windows Runtime apps on Windows Phone 8.1. I spent a good part of March / April porting major chunks of code without porting XAML.

Occasionally I was reminded of the pending work by both Clint Rutkas and others, namely Glenn Versweyveld. After another round this week, I decided to take advantage of the quiet time I am having to push this through.

I have created a fork of coding4fun repo on codeplex and so far this is what i have done

  • Coding4Fun.Toolkit updated to support universal apps (Win8.1 and WP8.1)
  • Coding4Fun.Toolkit.Audio updated to support universal apps (Win8.1 and WP8.1)
  • Coding4Fun.Toolkit.Storage updated to support universal apps.
  • Created Coding4Fun.Toolkit.Controls project to explicitly support WP8.1
  • Added Tile, ImageTile, SuperImage, ColorHexagonPicker, BubbleChat & BubbleChatTextBox controls

Once parity with existing Win8.1 lib has been achieved, the next version of toolkit will be released on Nuget.

Images and Scaling with Windows Runtime #WinRT #WPDev #Windev

With the advent of Windows Phone 8.1, developers have the option of using WinRT native XAML stack as opposed to the Silverlight XAML the only option with early Windows Phone iterations.

One of the differences between WinRT XAML and Silverlight XAML is scaling and like with fonts, & images, scaling can have a significant effect on the look and feel of an app.

The default behavior with Windows Phone 8 was the inherent Silverlight behavior of scaling the image to fit. This meant that unless a high-resolution image was used, the image would end up looking blurred. Windows Runtime takes a different approach.

Windows 8x supports multitudes of screen sizes, resolutions and DPI. Windows Phone now supports 4 resolutions. The way Windows Runtime deals with this is by allowing developer to specify multiple images to match certain scale factors.

Windows Store Apps Windows Phone Store Apps
1.0 (100% no scaling) 1.0 (100% no scaling)
1.4 (140% scaling) 1.4 (140% scaling)
1.8 (180% scaling) 2.4 (240% scaling)

The runtime would determine the scaling factor to use depending upon the screen size, resolution, DPI and the form factor of device in question. The developer is required to supply images for scaling 1; the other scale factors are optional. If they are supplied, they will be used if necessary.

There are two ways of supplying images to support multi-scaling support.

  • Specify image scale within the file name e.g. Image.scale-100.png or Image.scale-140.png
  • Create direct for each image scale and place images inside without specifying scaling like in 1. E.g. scale-100/Image.png or scale-140/Image.png

The attached project includes examples of both ways.

To use this and enable auto-scaling support, you specify the image as specified below

<Image Source="Assets/Iris.png" />
<Image Source="Assets/Iris2.png" />

Occasionally it is necessary to set the images from code. In those instances, one should query the windows runtime to determine the current scaling factor and return appropriate image resource.

var uri = new System.Uri("ms-appx:///Assets/Iris.png");
var file = await StorageFile.GetFileFromApplicationUriAsync(uri);

This will correctly detect the scaling factor and get appropriate file.

Alternatively, for Windows 8x, we can use DisplayProperties.ResolutionScale to determine current scaling and for Windows Phone, we can use DisplayInformation.RawPixelsPerViewPixel.

Uri uri = null;
    var rawpixelperview = Windows.Graphics.Display.DisplayInformation.GetForCurrentView().RawPixelsPerViewPixel; 

    var Width = Convert.ToInt32(Window.Current.Bounds.Width * rawpixelperview); 
    var Height = Convert.ToInt32(Window.Current.Bounds.Height * rawpixelperview); 

    if(Width == 480 && Height == 800)
        uri2 = new System.Uri("ms-appx:///Assets/scale-100/Iris2.png");
    else if((Width == 720 && Height == 1280 ) || (Width == 768 && Height == 1280))
        uri2 = new System.Uri("ms-appx:///Assets/scale-140/Iris2.png");
        uri2 = new System.Uri("ms-appx:///Assets/scale-240/Iris2.png");
    switch (DisplayProperties.ResolutionScale)
        case ResolutionScale.Scale100Percent:
            uri2 = new System.Uri("ms-appx:///Assets/scale-100/Iris2.png");

        case ResolutionScale.Scale140Percent:
            uri2 = new System.Uri("ms-appx:///Assets/scale-140/Iris2.png");

        case ResolutionScale.Scale180Percent:
            uri2 = new System.Uri("ms-appx:///Assets/scale-180/Iris2.png");

var file = await StorageFile.GetFileFromApplicationUriAsync(uri);

It worth noting that images set in xaml and those done codebehind behave differently at least as far as size on screen is concerned. The only way to achieve correct size as visible in xaml is to set size to that of scale 1.0 image.

Supporting Accessibility

Windows Store apps support high contrast mode. The two available options are

  • Black background and white foreground
  • White background and black foreground.

To additionally support these two accessible image formats, you need to provide scale factor 1 images named / placed appropriately. I have excluded the high contrast images from sample as windows phone was using that by default.






Downloadable sample code can be downloaded here

WinRT License API, Silverlight 8.1 apps and sideload detection #wpdev

Since early 2011, I have been using the method described here.
Recently I have been upgrading all my apps to target Windows Phone 8.1 API. Most of previous API is still accessible in WP 8.1 SL8.1 apps. However a great deal more is available under WinRT API.

With my Alarm Clock app, I have started using WinRT API to pin and update Tiles. I have used WinRT API for background tasks as I can run them more frequently and I can detect Timezone change. I have added IAP to the app.
The app however is available in 2 flavours Free (with ads and restrictions) and Paid. So far I have only been updating the paid app. Of course I use sideload detection for Paid app however while considering update of Free version, I decided to use CurrenApp to execute License check and potentially offer to convert Free users in-place as opposed to getting them to buy another app!!

In good old SL API, I would have used

var license = new Microsoft.Phone.Marketplace.LicenseInformation();
IsTrial = license.IsTrial();

With WinRT that becomes

IsTrial = CurrentApp.LicenseInformation.IsTrial;

While developing and deploying if you observe the behaviour, the IsTrial never returns false. You cannot test Trial scenario without explicit pre-processor directives!
Of course CurrentAppSimulator is only available for WinRT app and not SL8.1 apps. The same behaviour would be exposed by the sideloaded apps. Not downloaded from store equates to full version. Like in good old days, WMAppPRHeader.xml is still attached after certification. So lets modify the code

   XDocument doc = XDocument.Load("WMAppPRHeader.xml");
   IsTrial = CurrentApp.LicenseInformation.IsTrial;
   IsTrial = true;

You treat all apps without WMAppPRHeader.xml as trial. Job done!
Note that IAP are not affected. If you had TestIAP, it is not active by default.


Happy coding!

DLL / Reference hell with #WP8 #SL81 and #WinRT component

Over the last month, I have gone back to “AlarmClock” app (my 3rd Windows Phone app from back in 2011). I have updated it to render time updates on live tile. In fact I am quite proud the mechanism I use. I additionally provided 50 downloadable font packs that users can choose from (purchasable in a set of 10).

Original solution
The update mechanism was initially based on Silverlight Background Task. The tile update mechanism of course updates tile based on local time. However a user reported that when travelling between timezones, the tiles kept showing previous timezone times until the next background task run started pushing new ones based on new local time.

I deliberated on this and came to the conclusion that somewhere something was fishy.. its possible that Tile updates are actually scheduled on UTC as opposed to local time or maybe I just don’t understand it. Either way, I had to fix this issue

Solution 2: Fix for Timezone change
The new windows phone 8.1 introduced a bunch of new WinRT API that included API for Background task including those that run on Timezone change. So I dumped SL based Background Task and went full stream with WinRT component. Added 2 WinRT classs on for Timer and another for Timezone and this worked great.

Another user wanted the clock and tile updates to support multiple Timezones – wanted to pin Hong Kong and Seattle. My app so far only supported local device timezone.

Soluion 3 – Multiple Timezone support

.NET 4.5 comes with TimeZoneInfo class.This provides a nice method GetSystemTimeZones which lists all timezones and make it possible to convert between those. However Windows Phone .NET Runtime does not come with this and there is not suitable WinRT API either. Yay!!
Oren Novotny created a good Win32 wrapper which works on both WP8, WP81, SL81 and WinRT
I fired up Nuget Package Manager and searched for timezone..found Timezone conversion between WinRT and PCL.. Added a reference to the App and reworked it to support user selectable timezone etc. This required me to select target between x86 and ARM – any CPU no longer an option.

Next step?? Add Timezone helper reference to WinRT component. Bang bang bang.. nugget sorted it all out.. that was easy.. modified the background processor to update all tiles with correct timezone times!! nice 🙂 What could possibly go wrong ?

Hit F6, (Old school.. modified VS 2013 to build o F6 like before).. all good. Hit F5… wait for it !!!!

Runtime exception – File not found System.Runtime.InteropService.. quick search showed reference conflict..

Step 1) Set WinRT component to x86 instead of Any CPU.. maybe that will do the trick!!!

Nope far from it… Result System.BadImageFormatException thown when trying to run the app.

Step 2) Download code and make a part of existing WinRT component..

Nope still the same error(s)

While deliberating, realised that I called code from Background Task directly from my app.. 3rd trial

Step 3)

Remove calls to code in Background Task from App
Nuget Reference to App
Code within WinRT component for internal use
App – x86 / ARM target
WinRT component – Any CPU tagt

Bingo.. It all work as advertised!!

Took me day to figure try out various options