Creating PNG image files in Windows Phone

Windows Phone image processing and format support has always been lacking a bit, especially when compared with all the GDI+ capabilities one has available in the full .NET Framework.

For instance, you can read JPEG and PNG files, but you can only save to JPEG, as there is no support to save to PNG directly on the platform.

Saving to PNG has been quite easy since the beginning of Windows Phone 7 by using 3rd party libraries, and on this chapter, .NET Image Tools is the most used one!

But personally, using Image Tools always presented two major problems:

  • it requires SharpZipLib (a GPL licensed library) to handle Zlib compression
  • it’s quite slow and uses a lot of memory

The first problem is a definitive “no-no” for usage in closed code commercial apps, as GPL is “viral license

The second problem is more related to the way Image Tools was developed, not considering usage in mobile devices that have lower specifications as to processor capacity or memory.

The Cimbalino Windows Phone Toolkit way

Cimbalino Windows Phone Toolkit version 3.2.0 presents a new WriteableBitmapExtensions containing a SavePng() method to create PNG files from WriteableBitmap instances!

Internally it uses DotNetZip (Ms-Pl license) to handle the required ZLib compression and it’s quite optimized for speed and low memory consumption.

To illustrate the speed improvement, Ertay Shashko was kind enough to test it with his Tile Me app, and here are the results of his personal usage:


I guess the numbers speak for themselves! :)

Handle 1080p in Windows Phone like a Pro!

The change log for Windows Phone 8 update 3 (also known as GDR3) has been known for a few weeks and one of the new features is the added

support for bigger, higher-resolution screens

This is obviously only for new devices, with 5” or 6” screens using 1080p resolution, like the amazing Nokia Lumia 1520!

Here’s the complete list of Windows Phone supported resolutions, divided by aspect ratio:

  • 15:9
    • WVGA (480x800, 1.0x scale factor) - this is the only resolution available in WP7
    • WXGA (768x1280, 1.6x scale factor)
  • 16:9
    • 720p (720x1280, 1.5x scale factor)
    • 1080p (1080x1920, 2.25x scale factor) - only supported in the new large screen devices with WP8 update 3

As a Windows Phone developer/designer, you don’t need to know this!

All you need to do is design the interface in XAML for the 480x800 resolution, and it will automatically scale up using a fixed scale factor! How cool is that? :)

Now if you really want to know what is the device scale factor (maybe to create different app resolution-aware layouts), you can read the Application.Current.Host.Content.ScaleFactor (note: this property will return the scale factor * 100).

But there’s a catch: for the new 1080p devices, the scale factor is returned as 1.5x, just as the 720p devices, instead of the correct 2.25x…

To get the real scale factor, you can use the following code snippet:

public int ScaleFactor
        object physicalScreenResolutionObject;

        if (DeviceExtendedProperties.TryGetValue("PhysicalScreenResolution", out physicalScreenResolutionObject))
            var physicalScreenResolution = (Size)physicalScreenResolutionObject;

            return (int)(physicalScreenResolution.Width / 4.8);

        return Application.Current.Host.Content.ScaleFactor;

In WP8 update 3 you can use DeviceExtendedProperties.TryGetValue("PhysicalScreenResolution", out physicalScreenResolutionObject) to retrieve the screen Size resolution in pixels, take the Width of it and divide it by 4.8 to know the correct scale factor.

If the call to DeviceExtendedProperties.TryGetValue fails it just means you don’t have a WP8 GDR3 device, and as such the device is not a 1080p device and you can just fallback to use the Application.Current.Host.Content.ScaleFactor approach!

The Cimbalino Windows Phone Toolkit way

Previous versions of Cimbalino Windows Phone Toolkit already had the IScreenInfoService to help handling this, and since version 3.2.0, you can also count on the added 1080p support! :)

Cimbalino Windows Phone Toolkit Updated to v3.2.0

Version 3.2.0 of Cimbalino Windows Phone Toolkit is now available!

This release is mostly a bug/performance fix; here’s the change log:

  • Added the WriteableBitmapExtensions, which provides a high-performance & low memory impact SavePng() method!
  • Improved the IScreenInfoService and ResolutionAwareUriConverter to contemplate 1080p screens
  • The usual improvements and bug fixes

Windows Phone Week

Windows Phone Week

Directly from the official site:

Windows Phone Week is a series of events created for the developer community by Windows Phone Developer MVPs.

The events are in nine countries, encouraging developers from around the world to explore app and gaming development.

Each event has a unique agenda, format and registration process so please check the details at the location nearest you.

Although at this stage only 9 countries are participating, there are plans to expand to other territories, so stay tuned! ;)

Windows Phone URI association deep links and the ampersand

A few weeks ago I stumbled on an issue while using ampersand (&) in a URI association deep link with query string parameters!

Let’s start by assuming I have a Windows Phone app capable of handling deep links with “my-app:” moniker. Now take a look at the following sample link:


We can easily see a query string with two parameters, and after decoding their values, we get param1 = "a&b" and param2 = "c".

If we use the Launcher.LaunchUriAsync(uri) method to open the link, this is what will arrive in the internal UriMapper:


By retrieving and decoding the encodedLaunchUri from the previous link, the result will be "my-app://do/stuff/?param1=a%26b&param2=c", matching the original uri, as we would expect!

If we now use a web page with that link on it instead, open the page inside Internet Explorer on the phone and tap on the link, this is what will get to the app UriMapper:


If we do as before and retrieve and decode the encodedLaunchUri, we will get "my-app://do/stuff/?param1=a&b&param2=c", which in this case, doesn’t match the original deep link!

This behavior is due to Internet Explorer in Windows Phone, as it seems to decode all links before trying to navigate to them, and when it can’t perform the navigation (e.g. when the link isn’t a http:// or https:// link) it just sends it to the platform to handle it, but by that time the link has already been wrongly re-encoded!

So far I haven’t been able to find any way of bypassing this issue, apart of simply not using the & in my apps deep links… and my advice to you is to proceed just like this!

Cimbalino Windows Phone Toolkit: AutoFocusBehavior

Most desktop applications use the Tab key to jump focus from one control to the next one, and this is expected behavior and common knowledge to most users.

On Android, the on-screen keyboard normally shows a “Next” key to - yes, you’ve guessed it! - go to the next field, and that is something really useful when filling long forms!

In truth, some native Windows Phone apps actually do this on some fields, where tapping the Enter key will have the same result, but unfortunately this is not the default behavior.

You could simulate this behavior using the TextBox.KeyUp or TextBox.KeyDown events, and then calling Control.Focus() on the next control you want to get focus, but I guess we can all agree that this is quite some work and if you change the fields order, you’d have to change the code accordingly.

The Cimbalino Windows Phone Toolkit way

Well, as of Cimbalino Windows Phone Toolkit version 3.1.0, all you need to do is add the AutoFocusBehavior to your Page and… relax! :)

Yes, that’s really all it takes, as the behavior contains the everything needed to manage TextBox/PasswordBox control focus changes on Enter key, with some added bonus:

  • TabIndex property value from controls will be taken into account and the order will be respected
  • Any control with IsEnabled = false, Visibility = Collapsed, or TabStop = false will be skipped
  • Any TextBox control with AcceptsEnter = true will just use the default expected behavior (tapping Enter will just add a new line)
  • The AutoFocusBehavior.CycleNavigation property controls whether focus will jump from last control to first one or just focus the full page
  • The AutoFocusBehavior.SelectAllOnFocus property controls whether the entire contents of a control will be selected on focus

There is also an AfterAutoFocus event and AfterAutoFocusCommand so you can easily add some extra behavior of yours to the current one! :)

Cimbalino Windows Phone Toolkit Updated to v3.1.0

Version 3.1.0 of Cimbalino Windows Phone Toolkit is now available!

Here’s the change-log for this release:

  • New MarketplaceInformationService (more info)
  • New MediaLibraryService
  • New FMRadioService
  • New LockScreenService
  • New AutoFocusBehavior (more info)
  • Various improvements and bug fixes

You can count on some articles around the new stuff for the next few days! :)

FMRadio vs. BackgroundAudioPlayer… fight!!

“The cat is out of the bag”…

…as Microsoft has confirmed that FM Radio is making a return in the next update to Windows Phone 8 (commonly known as GDR2)!

Obviously, updating your phone to GDR2 may not suffice, as the phone itself must have FM Radio tuning capability from factory!

Back when Windows Phone 7.x was king we could use the FMRadio class to control the device FM Radio, but given that no support for it was added to Windows Phone 8, accessing it in a WP8 device would just throw an exception… but that was before GDR2!

Mark Monster, Silverlight MVP, has written a really good article on how to safely use the FMRadio class across all versions of Windows Phone.

So what’s the problem?

Here’s the whole problem and how you can check it, step by step:

  • Preconditions
    • Use a real phone with Windows Phone updated to GDR2
    • Plug in your headphones to the phone (the phone uses them as an FM Radio antenna)
  • Steps to reproduce
    • Open Music+Videos hub
    • Tap the “radio” item to start the FM Radio tuner
    • Tune in a radio station and check that you can hear audio on the headphones
    • Open any app that uses the BackgroundAudioPlayer and start playback
  • Actual Results
    • You hear the FM Radio audio and the audio from the app… at the same time!!
  • Expected Results
    • FM Radio should stop and you should now be hearing the audio from the app

Basically, there seems to be some sort of issue where the FM Radio does not stop once the BackgroundAudioPlayer starts!

You can however easily bypass this issue: just ensure you stop the FM Radio playback before starting the BackgroundAudioPlayer or any other playback for that matter!

To make things easier, you can use the following code snippet:

using Microsoft.Devices.Radio;

public class FMRadioSafe
    private static bool? _isAvailable;

    public static bool IsAvailable
            if (!_isAvailable.HasValue)
                    _isAvailable = FMRadio.Instance != null;
                    _isAvailable = false;

            return _isAvailable.Value;

    public static void Stop()
        if (IsAvailable)
            FMRadio.Instance.PowerMode = RadioPowerMode.Off;

Just copy and past this to your app and call FMRadioSafe.Stop() before any audio output instruction and you’re done! :)

Update 20/08/2013: You can now use the FMRadioService from Cimbalino Windows Phone Toolkit version 3.0.0!