Upgrading from the IsolatedStorageSettings to ApplicationData.LocalSettings

When Windows Phone 7 came out, the SDK provided a really easy class to maintain the app settings: the IsolatedStorageSettings.

Basically, the class is an IDictionary<string, object> with a Save() method that will take the instance and serialize it to a file called “__ApplicationSettings” in the root of the app’s isolated storage.

Now if you upgraded your app from Windows Phone Silverlight 8.0 to the Windows Runtime model, you’ll probably want to migrate the settings from the old format to the new one, right?

Problem is that though the class exists in Windows Phone Silverlight apps, it does not in the new Windows Runtime apps, being replaced with ApplicationData.LocalSettings and ApplicationData.RoamingSettings instead.

So the only solution will be doing it ourselves, by reading and deserializing the “old” settings file!

Here’s a sample of the content of an “__ApplicationSettings” file from one of my tests:

PhoneApp1.Address, PhoneApp1, Version=, Culture=neutral, PublicKeyToken=null
<ArrayOfKeyValueOfstringanyType xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays"><KeyValueOfstringanyType><Key>Name</Key><Value xmlns:d3p1="http://www.w3.org/2001/XMLSchema" i:type="d3p1:string">John Doe</Value></KeyValueOfstringanyType><KeyValueOfstringanyType><Key>Age</Key><Value xmlns:d3p1="http://www.w3.org/2001/XMLSchema" i:type="d3p1:int">20</Value></KeyValueOfstringanyType><KeyValueOfstringanyType><Key>Country</Key><Value xmlns:d3p1="http://schemas.datacontract.org/2004/07/PhoneApp1" i:type="d3p1:Address"><d3p1:Code>UK</d3p1:Code><d3p1:Name>United Kingdom</d3p1:Name></Value></KeyValueOfstringanyType></ArrayOfKeyValueOfstringanyType>

By looking at the contents of some samples of settings file like the one above, here’s what we can learn:

  • the file has always two lines (second line in the above sample is auto-wrapped to fit the post!)
  • the first line has the known types full names that should be loaded and passed on to the DataContractSerializer constructor, each properly separated by a null char
  • if only basic types are used, the first line will be empty
  • the second line is the serialized xml data

So I wrote the following code snippet to read and deserialize the values from “__ApplicationSetting” to an IEnumerable<KeyValuePair<string, object>>:

public async Task<IEnumerable<KeyValuePair<string, object>>> GetValuesAsync()
        using (var fileStream = await ApplicationData.Current.LocalFolder.OpenStreamForReadAsync("__ApplicationSettings"))
            using (var streamReader = new StreamReader(fileStream))
                var line = streamReader.ReadLine() ?? string.Empty;

                var knownTypes = line.Split('')
                    .Where(x => !string.IsNullOrEmpty(x))

                fileStream.Position = line.Length + Environment.NewLine.Length;

                var serializer = new DataContractSerializer(typeof(Dictionary<string, object>), knownTypes);

                return (Dictionary<string, object>)serializer.ReadObject(fileStream);
        return new Dictionary<string, object>();

So all you now have to do is call the GetValuesAsync() method above and load those values to one of the new Settings repositories!

The Cimbalino Toolkit way

Starting in Cimbalino Toolkit 1.2.0, you’ll be able to use the new IApplicationSettingsService to access Local, Roaming, and Legacy app settings.

In case that wasn’t clear from the names, the Legacy settings will allow you to get the values on the “__ApplicationSettings” file (do note that only the Values property is implemented, so it’s read-only).

Here are the platform rules for the ISettingsService:

  • Local
    • Supported in all platforms
  • Roaming
    • Supported in all platforms except Windows Phone Silverlight 8.0
  • Legacy
    • Only supported in Windows Phone

One last suggestion: after migrating the legacy settings remember to delete the “__ApplicationSettings” file as it won’t be needed again! ;)

Cimbalino Toolkit 1.0.0

In case you missed it, there is a new and improved Cimbalino Toolkit now available, supporting the following platforms:

  • Windows Phone Silverlight 8.0 and 8.1 apps (WP8)
  • Windows Phone 8.1 apps (WPA81)
  • Windows Store 8.1 apps (Win81)

The long story

About 3 years ago, the first version of Cimbalino Windows Phone Toolkit was released as a NuGet package with full source code hosted in GitHub to help every on the development of Windows Phone apps!

Back then, Windows Phone 7.0 was the only version available, and that meant that some technical decisions had to be made that influenced the toolkit architecture!

The main one was that WP7 apps Marketplace ingestion would automatically detect every component used in a particular app, and add the required Capabilities for them; so if the toolkit was a single assembly, you’d get your app with the full Capabilities list in the requirements, even if your app didn’t actually use them…

There was also some limitations on the available API’s for Background Agents and once again, the Marketplace ingestion of an app would basically fail if it detected one of those forbidden API’s.

So the toolkit ended up divided like so:

Cimbalino Windows Phone Toolkit

In light blue are the components that may be used with Background Agents. The rest of the components are divided by Capabilities or 3rd party components requirements.

Then came Windows 8.0 and Windows Phone 8.0, and Microsoft removed the Marketplace Capabilities auto-detection feature (the developer has to declare them manually in the app manifest), so we can now have drop that specific component division requirement! :)

This small change allowed to reduce the create a new Cimbalino Toolkit with just 2 NuGet packages!

There is still a lot of work to be done to port everything from the old toolkit to the new one, but here’s some of the things already working:

  • ApplicationBarBehavior, MultiApplicationBarBehavior, MultiBindingBehavior
  • StorageService, EmailComposeService, MessageBoxService, NavigationService, and others…
  • Most of the extension methods have already been ported, including the PNG support ones
  • Most of the value converters

Also, there is the need to write some new samples and documentation, so if you can I could surely use the help!!! ;)


Here are the new Cimbalino Toolkit NuGet packages:

Please check back soon to read about what’s new and what changed! :)

Bye Nokia… Hello Microsoft!

The deal to transfer substantially all of the Nokia Devices & Services business to Microsoft has now officially been closed.

With it, I proudly become a Microsoft employee! :)

I will always cherish the moment I decided in moving to the UK to work for Nokia (even if that stopped any chance of receiving the Microsoft MVP award, but that’s another story!).

Nokia made me feel that I could actually make a difference with my work, and I truly appreciate the company for the opportunity!

I’ve been working with Microsoft technologies for more time than I can remember, both as a user and also as an IT professional, and I consider getting the “blue badge” as a giant career step for me!

In the present moment this doesn’t bring any significant changes: I’ll carry on working in the MixRadio apps here in Bristol, as I did until today!

Thank you Nokia, it’s been really fun… Hello Microsoft! :)

Cimbalino Windows Phone Toolkit Updated to v3.2.3

Version 3.2.3 of Cimbalino Windows Phone Toolkit is now available!

As previously indicated, this will probably be the last version still supporting Windows Phone 7…

Here’s the change log starting from version 3.2.0 to the current 3.2.3:

  • v3.2.1
    • New WebRequestExtensions
    • Ensured that MarketplaceInformationService doesn’t cache the results
  • v3.2.2
    • New EventHandlerExtensions
    • Improved the MultiBindingBehavior by adding the missing Mode property
    • Improved the ShellTileServiceTile to enable tiles update with XML data
    • Fixed a couple of issues on MarketplaceInformationService related to “beta apps”
  • v3.2.3
    • New SaveRingtoneService
    • New ScreenCaptureBehavior
    • New FrameworkElementExtensions
    • DeviceInfo, Location, and UserInfo components can now be used inside Background Agents
    • Improved ShellToastService to add the custom sound support

There are other improvements and bug fixes not stated here, but also quite important too! :)

WrapPanel is great, so please, stop using it!

The WrapPanel control (part of the Windows Phone Toolkit) is a really useful control container.

Having said that, you should definitely avoid using it in your apps if you are planing to use in ListBox.ItemsPanel for large lists items presented with fixed size!!

To demonstrate my point, let’s say we have a list of 10 items:

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}

Now say we want to list 3 items per row and them wrap to the next row, we can use a WrapPanel container control, like so:

<ListBox x:Name="ItemsListBox"
            ItemTemplate="{StaticResource ItemDataTemplate}">
            <toolkit:WrapPanel />

The resulting items layout will look something like the following picture:

WrapPanel layout

This will work fine with 10 items, but what about 100? Or 1.000? Or even 10.000?

Using a WrapPanel with a large number of items will cause the control loading time and memory usage to increase, and if you make it large enough, you’ll probably start seeing your app crash with “out of memory” errors…

Now lets say we first group the items in groups of 3, making the source list look like this:

{ {0, 1, 2}, {3, 4, 5}, {6, 7, 8}, {9} }

All we now need is another ItemsControl inside our main ListBox to iterate the each group, something like this:

<ListBox x:Name="ItemsListBox">
            <ItemsControl ItemTemplate="{StaticResource ItemDataTemplate}" ItemsSource="{Binding}">
                        <VirtualizingStackPanel Orientation="Horizontal" />

Here’s the resulting layout schematic:

Smart Wrapping layout

Major advantages with this approach is the obvious performance improvement and memory consumption reduction. Why? Because we maintained the VirtualizingStackPanel in our main ListBox.ItemsPanel!

To prove my point, I’ve created a small demonstration app showing the result of using these two approaches with a list of 400 items.

Download the code, deploy it on a phone or emulator, then run each approach separately and exit the app after each run in order to check the peak memory usage.

You’ll notice a huge difference in loading times, but I can tell you that memory wise, it’s the difference between using 120MB or just 20MB! :)

Poll: What are your plans for #wp7dev

As I am about to start adding Windows Phone “Blue” support to Cimbalino Windows Phone Toolkit, I’m planning to stopping the WP7 support on the 3.x!

The upcoming 4.x would have WP8 and WP Blue support, allowing for a more future prune implementation and dropping the NuGet packages from 9 to just 2 (the Background package as it stands today and a main one with all the rest).

To actually understand the position of the Windows Phone developers about WP7 development, I started a poll that I now invite you to answer! :)

[polldaddy poll=”7881681”]

Want to meet the Cimbalino Windows Phone Toolkit?

The next W&W WAG (Wales and West Windows Application Group) meeting will be help tomorrow, February 26th, at Nokia Bristol office, and will feature me talking about the Cimbalino Windows Phone Toolkit, and the Mike Hole, talking about Bluetooth and NFC based communication.

The meeting will start at 18h30, you can find more details and register here!

Hope to see you there! :)

Disabling screenshot functionality in a Windows Phone app

Update: Kudos to Murat and Rudy Huyn for pointing me out on a missing return; that would cause the NotSupportedException to be raised all the time… I’ve fixed the code by inverting the if condition.

Update 2: Just noticed that GDR2 is also supported, as the code below will also work in devices with it! :)

Windows Phone 8 made it possible to take a screenshot of your screen at any time, just by pressing the Windows and Power button at the same time.

Sure, this is a really cool feature and can be quite handy from time to time, but it can become a security concern for some specific scenarios, not to mention a way to copy someone else’s graphical designs!

Since Windows Phone 8 update 3 (GDR2) there is now a hidden feature that allows you to disable the Screenshot functionality on a page by page basis: the PhoneApplicationPage.IsScreenCaptureEnabled!

This is a hidden property that requires Reflection in order to access and modify it’s state. The following extension methods will help you with that:

public static class PhoneApplicationPageExtensionMethods
    public static bool CanSetScreenCaptureEnabled(this PhoneApplicationPage page)
        return Environment.OSVersion.Version >= new Version(8, 0, 10322);

    public static void SetScreenCaptureEnabled(this PhoneApplicationPage page, bool enabled)
        var propertyInfo = typeof(PhoneApplicationPage).GetProperty("IsScreenCaptureEnabled");

        if (propertyInfo == null)
            throw new NotSupportedException("Not supported in this Windows Phone version!");

        propertyInfo.SetValue(page, enabled);

    public static bool GetScreenCaptureEnabled(this PhoneApplicationPage page)
        var propertyInfo = typeof(PhoneApplicationPage).GetProperty("IsScreenCaptureEnabled");

        if (propertyInfo == null)
            throw new NotSupportedException("Not supported in this Windows Phone version!");

        return (bool)propertyInfo.GetValue(page);

The first step is to call CanSetScreenCaptureEnabled() from inside your PhoneApplicationPage to check if the Windows Phone version is at least Windows Phone 8 update 3 (version 8.0.10322) as that is the minimum required version for this to work!

If it is, we can then use the GetScreenCaptureEnabled() and SetScreenCaptureEnabled() extension methods to change the property value!

Here is a sample usage code to disable screenshot functionality:

public partial class MainPage : PhoneApplicationPage
    public MainPage()

        if (this.CanSetScreenCaptureEnabled())

If you do try to take a screenshot after that code, this is what will happen:

Application screenshot functionality disabled

The same result will happen from the application switcher screen:

Task switcher screenshot functionality disabled

Nowadays, privacy has become the #1 concern in everything we do, and I’m sure this is a really useful information for a bunch of apps out there (looking at you 6snap and all other Snapchat apps ;) )