Windows Live Writer – Continue writing anywhere


I have been using Windows Live Writer for creating my posts for a while now, but just recently learned that you can actually change where WLW is storing drafts and recent posts. Changing this requires you to “hack” the registry, but doing that enables you to save your posts in SkyDrive so that you can continue working on your posts on any device that has access to your SkyDrive account.

It’s actually a really simple procedure:

  1. Create a folder in your SkyDrive, for example: FierceDesign Posts
  2. Open regedit (WIN+R and type regedit)
  3. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows Live\Writer
  4. Right-click the Writer folder in left pane and select New > String Value
  5. Name the resource key: PostsDirectory
  6. Double-click the PostDirectory key to change its value and past the url to your folder you created in step 1, in my case: C:\Users\<USERNAME>\SkyDrive\FierceDesign Posts


Now when you start WLW and save drafts they are stored in SkyDrive so that you can continue on your drafts from anywhere. Very nice!

Since I use WLW and have by blog on wordpress and have source code sections I use the following plugin to WLW to get nice code formatting. There might be better plugins out there but this one has worked for me :)

Happy coding and blogging!

Windows Phone 8 Development – Localization

WP8 Development Serie

1. Introduction
2. Screen resolutions
4. Localization (this post)

A while ago I wrote a post about Localization in WP7 and thought we should have a refresh on localization and what is new in Windows Phone 8.

Windows Phone 8 Localization
Windows Phone 8 supports 50 display languages (shipped with the phone depending on market and country/region) and selectable by the user on the language+region section of the Settings page. Windows Phone 7.1 only supported 24 and I bet more languages are coming. WP8 also allows you to build apps that read from right to left.

New Project Templates Have Localization Support Built In

One really nice addition is that every new project you create in Visual Studio 2012 has a class included called LocalizedStrings that provides the developer programmatic access to resources. An instance of this is created in App.xaml, in the Application Resources with the key LocalizedStrings. I might argue on the default names selected, but Microsoft has selected that in our templates, so better stick to it I guess.

Every new project also includes the default resources for the apps neutral language, Resources\App.Resources.resx. Note that some strings are already defined here and it is now up to the developer to create all literals in here to support localization for the default language you choose. All new projects also includes a commented-out code section in MainPage.xaml.cs to setup a localized Application Bar. You make it to simple for us!


Accessing String Resources from XAML

Now that we have the “framework” setup to handle localization in our WP8 app we need to databind the Text property of your TextBlock and other controls to the StaticResource  with a key of LocalizedStrings. Binding to resources has always been really simple in Expression Blend, although a bit more complicated in Visual Studio, you really need to know how to type the binding expression etc. Although I don’t think that is a huge problem to most of us developers, but for the UI developers the addition of better support to XAML design in Visual Studio 2012 is always welcome.

To databind to a localized string resource we simply select the element we want to localize, and then click the Rectangle icon next to the property we want to bind to in the Properties Window, in my example the Text property of the Application Title.


In the dialog that appears we need to select StaticResource in the Binding type drop-down and navigate to App.xaml and select LocalizedStrings (the key for the LocalizedStrings class instance)

It will then provide access to all the string resources, and we can just select what resource string we want to bind to. Very nice!


Add Support for Additional Languages

By default we have one AppResources file created for us, that is the Neutral Language used by the application. With VS2012 it is super simple to add support for additional languages:

  • Double-click project properties to open the Properties editor
  • On the Application tab
    –  Check each of the languages your app will support
  • Save the Project Properties
    – Visual Studio will now automatically create new AppResource files for each selected language/culture


Translate the Additional Languages Resource Files

  • Visual Studio adds a resource file for each additional language that the app will support. Each resource file is named using the correct culture/language name, as described in Culture and language support for Windows Phone in the documentation
  • For example:
    – For the culture Swedish, file is
    – For the culture German (Germany), file is
  • Supply appropriate translations in each resource file

Define the Default Language

Now when we have added and let Visual Studio create the resource files for us, all we need to do now is to select what language the app is using as default language. This is also very simple:

  • Double-click WMAppManifest.xml to open the manifest editor
  • On the Packaging tab
    – Set the Default Language to the language of your default resources

This identifies the language of the strings in the default resources file. For example, if the strings in the default resources file are English (United States) language strings, you would select English (United States) as the Neutral/Default Language for the project.


Happy Coding!

Windows Phone 8 Development – MVVM

WP8 Development Serie

1. Introduction
2. Screen resolutions
3. MVVM (this post)
4. Localization

I guess most of us know the core concepts of MVVM, so this post will not talk about the pattern itself, but more highlight a new way of defining our properties that are bound in UI. Shortly anyway, binding to properties in XAML requires the properties to implement the INotifyPropertyChanged interface for the UI to automatically reflect changes.

ViewModel Implementation in Windows Phone 7.1
The old style of implementation was error-prone because of use of “magic strings”. Imagine that you rename/refactor a property name then that will not change the string representation of the property name used and you might end up with bugs that are hard to find.

public class ItemViewModel : INotifyPropertyChanged
    private string _id;
    /// Sample ViewModel property; this property is used to identify the object.
    public string ID
        get { return _id; }
        set {
            if (value != _id)
                _id = value;
    public event PropertyChangedEventHandler PropertyChanged;
    private void NotifyPropertyChanged(String propertyName)
        PropertyChangedEventHandler handler = PropertyChanged;
        if (null != handler)
            handler(this, new PropertyChangedEventArgs(propertyName));

ViewModel Implementation in Windows Phone 8.0
New style of implementation – CallerMemberName Attribute.

public class ItemViewModel : INotifyPropertyChanged
    private string _id;
    public string ID
        get { return _id; }
        set { this.SetProperty(ref this._id, value);  }
    public event PropertyChangedEventHandler PropertyChanged;
    protected bool SetProperty<T>(ref T storage, T value, [CallerMemberName] String propertyName = null)
        if (object.Equals(storage, value)) return false;
        storage = value;
        return true;

    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
        var eventHandler = this.PropertyChanged;
        if (eventHandler != null)
            eventHandler(this, new PropertyChangedEventArgs(propertyName));

This is not a huge change, you can still use the old way of literal strings for the property name, although I suggest using the new way to be pragmatic about future rename refactorings.

Happy Coding!

Windows Phone 8 Development – Screen Resolutions

WP8 Development Serie

1. Introduction
2. Screen resolutions (this post)
4. Localization

This post will focus on the different screen resolutions that are now supported in Windows Phone 8.

3 Screen resolutions

Windows Phone 8 supports three different resolutions and the first question that pops into mind is; Do I have to do three different UIs? Well actually no, but you can do custom things when you have different resolutions, but  we as developers work with device independent pixels, the OS applies a scale factor to the actual resolution so that we do not have to worry about that.

Resolution Aspect ratio Scale Factor Scaled resolution
WVGA 800 x 480 15:9 1.0x scale 800 x 480
WXGA 1280 x 768 15:9 1.6x scale 800 x 480
720p 1280 x 720 16:9 1.5x scale, 80 pixels taller (53 pixels, before scaling) 853 x 480

If we would like to do custom UI we can, and we can also select what resolutions the application supports (double-click the WMAppManifest.xaml file and check the Supported resolutions) but if we do not specifically specify supported resolutions, all are supported and the OS handles the scaling.


In most cases, you should supply images targeting the WXGA (1280 x 768) screen

  • WXGA assets are of the highest quality
  • Will automatically scale down on WVGA phones
  • Still look great on 720p (1280 x 720)

Although if we want to give the users maximum user experience then we should consider supplying images with three resolutions.

E.g. Logo.screen-wvga.png, Logo.screen-wxga.png and Logo.screen-720p.png and then at runtime get Application.Current.Host.Content.ScaleFactor to determine the current resolution of the screen on the phone and write custom code to load the correct corresponding image. ScaleFactor returns 100 for WVGA, 160 for WXGA and 150 for 720p.

One common way is to create a resolution helper class

public enum Resolutions { WVGA, WXGA, HD720p };

public static class ResolutionHelper
   private static bool IsWvga
         return App.Current.Host.Content.ScaleFactor == 100;

   private static bool IsWxga
         return App.Current.Host.Content.ScaleFactor == 160;

   private static bool Is720p
         return App.Current.Host.Content.ScaleFactor == 150;

   public static Resolutions CurrentResolution
         if (IsWvga) return Resolutions.WVGA;
         else if (IsWxga) return Resolutions.WXGA;
         else if (Is720p) return Resolutions.HD720p;
         else throw new InvalidOperationException("Unknown resolution");

Then create a class that uses the above resolution helper to select the correct image.

using System.Windows.Media.Imaging;

    public class MultiResImageChooser
        public Uri BestLogo
                switch (ResolutionHelper.CurrentResolution)
                    case Resolutions.HD720p:
                        return new Uri("Assets/Logo.screen-720p.jpg", UriKind.Relative);
                    case Resolutions.WXGA:
                        return new Uri("Assets/Logo.screen-wxga.jpg", UriKind.Relative);
                    case Resolutions.WVGA:
                        return new Uri("Assets/Logo.screen-wvga.jpg", UriKind.Relative);
                        throw new InvalidOperationException("Unknown resolution type");


Then in xaml we can simply use the following expression to bind and get correct image for pixel-perfect result



<!--Application Resources-->
   <h:MultiResImageChooser x:Key="MultiResImageChooser"/>


<!--ContentPanel - place additional content here-->
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
   <Image Source="{Binding BestLogo, Source={StaticResource MultiResImageChooser}}"/>

Splash Screens

To add a splash screen to your project suitable for all resolutions, add a file as content called SplashScreenImage.jpg at 768 x 1280 resolution. This means that the framework automatically scales it to the correct size on different resolution screens. But we can also provide pixel-perfect splash screens for all resolutions, add images with the  following names:

  • SplashScreenImage.Screen-WVGA.jpg
  • SplashScreenImage.Screen-WXGA.jpg
  • SplashScreenImage.Screen-720p.jpg
  • In addition to these images, you must still include the default SplashScreenImage.jpg file

Note that Windows Phone 8 apps starts much faster than WP7.1 apps, so unless you have an app that is unusually slow on loading (might be due to amount of resources needed etc) we should omit the splash screen image. If you decide to use a splash screen, one suggestion is to create an animated splash screen to give the users something more appealing to look at, One way to do this is by creating a Popup control that displays the animation while the app resources are loading. When the app has finished loading, you can hide the Popupcontrol. For more info about animations, see Quickstart: Animations for Windows Phone.

App Icon and Tiles

  • You must supply app icon and tile images sized for WXGA
  • The framework automatically scales to the correct size for WVGA and 720p
Tile size WXGA
Application Icon 100 × 100
Small 159 × 159
Medium 336 × 336
Large 691 × 336

Happy Coding!

Windows Phone 8 Development – Introduction

1. Introduction (this post)
2. Screen resolutions
4. Localization
5. …
6. …
7. …
8. …
9. …
10. …

This will be the first post of several regarding Windows Phone 8 development. To get started it would be good to get an overview of what is new and what to expect in upcoming posts. So let’s go through most of the features and technologies provided and available for Windows Phone 8 development.

Shared Core

So the first statement that a lot of people has gotten wrong is about “Shared Core”. That Windows Phone 8 has Windows 8 OS and that you can build apps that runs on both Windows 8 and Windows Phone 8.

This is not exactly true. With shared core we mean

  • Some OS components such as the kernel, networking, graphics support, file system and multimedia are the same on both Windows 8 and Windows Phone 8
  • Hardware manufactures work with the same driver model on both platforms
  • Windows Phone 8 now also has support for multi-core and other features like Windows
  • Most important is that this common foundation makes it easier to extend the Windows Phone platform into the future

But where there is a misunderstanding is that shared core does NOT mean

  • that Windows 8 and Windows Phone 8 work against the exact same API

Windows Phone 8 is also said to be backward compatible, meaning all WP7.1 apps will run on WP8, but this is not true either, since all the apps that has used special SDKs, like the Hybrid SDK will not run by default on a WP8 device. So don’t be alarmed if you are missing some of your favorite apps in the Store on your Windows Phone 8 device.

Windows Phone 8 Programming Model

Let’s take a closer look at the Windows Phone 8 Programming Model

  • Windows Phone 8 will use the WinPRT (Windows Phone Runtime) programming model which is a subset of WinRT. This allows a lot of code to actually be shared between the two platforms.
  • We also have access to managed app development targeting WP7.1 and WP8.0
  • Native app dev using WinPRT and Win32
  • Games dev using WP7.1 XNA framework
  • Games dev using Direct3D or DirectX

WP8 Programming Model

managed The .NET API for Windows Phone is the primary managed API used. It contains all the types and APIs from WP7.1 but there as also been a lot of new classes added for Windows Phone 8, like for example, Microsoft.Phone.Wallet and many more…
managedAndNative WinPRT (Windows Phone Runtime) is a subset of the full WinRT with some phone-specific additions. One important part to high-light is that WinPRT is implemented in  C++ and projected into C#, VB.NET and C++ but HTML5/JavaScript projection is not available on Windows Phone 8.
win32Com Win32 and COM API gives you access to native app dev and access to for example:

  • Winsock for low-level networking
  • Camera API
  • and a bunch of COM APIs such as ReadFile, WriteFile and many more…

Note that managed application could call these APIs if we add a native project to the solution, but I don’t think to many projects will need that.

Tile Templates and Tile Sizes

Windows Phone  8 now supports 3 different Tile templates that you can use/support to let users pin your app to the start screen.


Flip Template, which is similar to what we have in WP7.1 template that flips the tile front to back
Iconic Template (new in WP8) that has a clean iconic design that incorporates Windows Phone Design Principles
Cycle Template (new in WP8). The Cycle Tile template cycles through between one and nine images.

Lock Screen

One new awesome feature is that you can now register your app as a lock screen provider which enables users to select your app to show detailed status on the lock screen. The possibility to select your app as one of the five apps to show quick status as an icon and count. And also select your app as the lock screen background image provider. I see a lot of potential good apps that I would love to be able to get detailed status info from directly on the lock screen. Let’s see if there are some apps that actually use this feature.


Windows Phone 8 introduces a few new launchers. Launchers are APIs that helps the user perform common tasks, which means that the users can invoke parts of the phone’s built-in capabilities to perform tasks.

The new launchers in WP8 are:

For a complete list of Tasks available see Windows Phone Dev Center


One big news is that Bing Maps control has now been set as obsolete/deprecated and the new Maps control is provided by Nokia (although you can still use Bing Maps but it will probably eventually be removed). The new Maps control provided by Nokia is really good and has a lot of good features

  • Vector-based for faster rendering
  • Four cartographic map modes
  • Light and dark color modes
  • Display landmark and pedestrian features

Location and Location Tracking

WinPRT has a new location API that is similar to Windows 8 Location API. The Windows Phone 7.1 .NET Location API is still supported.

We can also implement Background location-tracking apps that
– run continuously in the background when the user navigates away from your app
– enables scenarios such as a Run Tracker, turn-by-turn navigation etc.


Another really nice feature that existed on WP7 is Speech, but in WP8 we as developers can also add speech support to our apps!

There are two types of voice interactions

  • Voice Commands, that basically allows users to deep-link into your app
  • Speech Recognition and Text-to-Speech APIs


  • Credit & Debit  Cards
  • Loyalty & Membership Cards
  • Access Saved Deals
  • Supports NFC ‘Tap to Pay’

More Screen Resolutions

WP8 now supports 3 different screen resolutions


More on this in later post regarding what we as developers need to think about to support the different resolutions.

Camera and Photos

  • Lenses
  • New Picture.GetPreviewImage() method to return thumbnail images
  • New Photos extensibility features
  • Background Photo Auto-upload
  • Advanced camera capture APIs for apps that require fine control of the camera


  • Add and remove music files from the users’s collection with SaveSong and Delete methods
  • Each picture saved on the phone will automatically generate two different thumbnail images and be possible to be retrieved by your app
    – A small thumbnail image
    – A preview image that has the same dimensions as the phone’s screen resolution.
    this enables the developers to get better performance when displaying images on the phone
  • There is now also a new PlayStateChangedEventArgs that returns data when the state of the BackgroundAudioPlayer changes. This was very difficult to handle in previous versions and should now enable the developers to create more robust and performing audio apps.

VoIP and Video Chat

  • Incoming VoIP calls work like any other call
  • Integrates with built-in phone features
  • VoIP apps continue to run in the background
  • Available to all developers!

Bluetooth and NFC

  • Create apps that communicate with other phones using Bluetooth technology
  • Bluetooth API enables the following scenarios for Windows Phone 8:
    – App-to-app communication
    – App-to-device communication
  • Proximity API enables:
    – App-to-app connection using Bluetooth technology
    – Establish a Wi-Fi, Bluetooth, or Wi-Fi Direct connection between your app and an instance of your app on a proximate device
    – Send data between devices using NFC.
    – Use a phone to interact with NFC tags

Using NFC developers will now be able to build apps that can easily share data between Windows Phone 8 and a Windows 8 device, can’t wait to see what the community/developers creates!

Networking Enhancements and Changes

  • Windows.Networking WinPRT API
    – New networking API highly compatible with Windows 8
  • Incoming Sockets
    – Supported in both System.Net.Sockets and Windows.Networking.Sockets, which means your app can listen for an incoming network connection
  • Support for IPV6
  • Winsock native API support
    – Helps porting of existing native libraries that use the Winsock API


Apps can now use the Microsoft.Phone.Storage API to read files from an SD card. More on this in upcoming posts.

Custom Contact Store
  • Create a set of contacts owned exclusively by the app, though visible through the phones built-in Contacts app! How cool isn’t that, although don’t really know what types of apps will use it except apps like Facebook and similar.
  • APIs are provided to create, update, delete, and query the app’s contacts
  • Sync the app’s contact list with a remote list maintained by the app’s cloud service

File and Protocol Associations

This is another really awesome new feature. Apps can now register their own File Associations which means that we can automatically launch your app when a file of the registered type is received as an email attachment or opened in the browser or even through SharePoint. This actually enables App-to-App communications. One app can launch another app by sending it a file of the registered type. If the user opens a file that is associated with your app, this will actually not prevent other apps from registering the same file extensions. How this will actually work in the end is yet to see. A really cool feature but will it be used?

An app can register a protocol that allows your app to automatically launch when another app ‘opens’ a special URI
– Protocol is the first part of the URI, e.g. myprotocol:/ShowItems?ItemID=4711
– App launches another and passes data in the remainder of the launch URI

Windows Phone 8 apps run faster!
In Windows Phone 8 Managed Apps are actually NGEN’d for you (compiled to native) in the Windows Phone Store, which means they will typically start and run faster without any special tasks performed by the developer!! This means that when you build your app in Visual Studio, the code is not compiled into a native image, but into a machine-independent Common Intermediate Language (CIL) binary file (formerly known as Microsoft Intermediate Language, or MSIL) and when you submit your app to the Windows Phone Store, you submit the CIL file and that is converted automatically and optimized to Machine Dependent Intermediate Language, or MDIL. So when the users download your app to their device, it is actually pre-jitted to native image to increase performance!
Stuff to know
Other new features we have in WP8 and important stuff we need to know about that I hopefully will cover in upcoming posts are among others
  • In-App Purchase
  • Enterprise App Development
  • Company Hub
  • Converting Apps from 7.1 to 8.0
    – Source Code incompatibilities
    – Binary App Incompatibilities (basically code that behaves differently when run on WP8 compared to WP7.1)
  • Development Tools, Visual Studio tools, Emulator tools, Network Simulations
  • etc…

Hopefully this gives you a good introduction on what new features we have in Windows Phone 8 development and in upcoming posts I will dig in more to give you more meat to the bones!

Happy coding!

Windows 8 Nested GridView Scrolling

One annoying issue I’ve had with proper mouse wheel scrolling is that if you have a ScrollViewer that contains several different item controls, then mouse wheel scrolling is not always working as expected. For example if you have the following setup

then while you have your mouse pointer over any nested GridView, mouse wheel scrolling stops working. There is actually a simple explanation to this and that is how routed events works. The “inner” GridView will handle the scroll event and stop it from bubbling up the visual tree.
Although my first approach was to create a custom style for the inner GridView that removes the GridView inner ScrollViewer and only have the outer ScrollViewer. This seems to work, since mouse wheel scrolling is now working as expected. But, once I tried the app on a Slate, then all the touch events stopped working. I could no longer select items by a “swiping down” action on GridView items. I was trying all kinds of solution without any success. Then it struck me, the inner GridView is stopping the scroll event from bubbling up, then perhaps all I need to do is to add an event handler to the PointerWheelScrollEvent and make sure it is not handled.

So in the constructor for the View that contains the ScrollViewer with nested GridViews I simply add the following

GridView1.AddHandler(UIElement.PointerWheelChangedEvent, new PointerEventHandler(OnPointerWheelChanged), true);

GridView2.AddHandler(UIElement.PointerWheelChangedEvent, new PointerEventHandler(OnPointerWheelChanged), true);

// etc...

and add the following simple implementation for the PointerWheelChanged event handler

private void OnPointerWheelChanged(object sender, PointerRoutedEventArgs e)
      e.Handled = false;

By doing the above changes, the nested GridViews are no longer stopping the mouse wheel changed event from bubbling up the visual tree, and the outer ScrollViewer now works properly, and all touch actions with built in animations now also works as expected.

Lessons learned, always “go back to basics” don’t try to complicate things. There is usually a simple solution :)

Happy Coding!

Windows Phone – Performance Best Practices

Performance issues is where we usually spend most effort in finding, so it is very important to understand how you find them, and how you prevent them in the first place.

This post will be fairly long containing some basic info about performance in apps and at the end go through some of the more common occasions where I usually see performance issues and how to fix them.

Let’s start with looking at the threading model.

Silverlight for Windows Phone has two threads that handle all the presentation related work. One UI Thread and one Composition/Render thread.

UI Thread

The UI thread is the main thread in Silverlight for Windows Phone and functions very similar to the UI thread for the Silverlight browser plug-in.

The UI thread handles all input, which includes touch, parse and create objects from XAML, layout calculations, data binding, draw all visuals (at least the first time they are drawn), rendering/rastering, process per-frame callbacks and execute other user code and event handlers.

Composition Thread

The composition thread is new for SL on WP7, it’s actually the only platform that has it (as far as I know) and is created to talk directly to the graphics processor, GPU. It basically feeds the GPU with textures to draw and handles transform (scale, rotate, translate) animations and plane projections.

The composition thread handles some work that the UI thread would normally handle, and therefore improves performance of Silverlight applications for Windows Phone. The composition thread combines textures and passes them to the GPU for drawing. Also storyboard-driven animations that run on the composition thread are automatically cached and handled by the GPU on the device in a process called auto-caching.

Note: To use the composition thread, scale transforms must be less than 50 percent of the original size.

In addition, opacity and clip property settings are handled by the composition thread. However, if an Opacity mask or non-rectangular clip is used on the animated object, these operations will be passed to the UI Thread. This means that even if the clip region is a rectangular shape but uses the PathGeometry the operations will be passed to the UI thread. So make sure to always use the RectangleGeometry for clipping paths if possible.

Animations and Threads

As mentioned previously, storyboard-driven animations are handled by the composition thread. This is ideal because the composition thread passes these to the GPU for processing. In addition, the composition thread can run more frequently than the UI thread if the CPU is overloaded.

Translate animation will run on the Composition Thread

There are times, however, when storyboard animations do not satisfy the requirements of your application. In this case, you may choose to drive animations in code. These animations are handled on a per-frame basis. In many cases, this is fine, but you should be aware of the implications of running animations on a per-frame callback.

Per-frame callbacks are handled strictly on the UI thread. Animations will update only as fast as the UI thread can process them, and depending on what else is happening in your application, the animations may appear less smooth than if they were running on the composition thread. Also, when you update animations in code, the elements are not automatically cached as they would be if they were updated in a storyboard. If you manually place a bitmap cache on these elements, the transformation and blending is passed to the GPU, but the animation is still being updated on a per-frame callback and processed by the UI thread. In these cases, the animation will update only as fast as the frame rate of the UI thread.

Color animations will run on the UI Thread and if blocked it will miss changing color


It is extremely important to think about threading and have a solid understanding of how critical the UI thread is, it already does a lot as it is, so extremely important not to do to much work on the UI thread then necessary .

Progress bar

One of the most common controls used to show an indication that something is taking time to process is the ProgressBar. Although not everyone knows that the progress bar that is shipped with the SDK is lacking performance, it is running all the animations on the UI thread and is not really a valid option for a progress indicator. If you need to place a progress bar somewhere in the application that is not at the top of the page, then you should use the PerformanceProgressBar that is shipped with the Silverlight Toolkit for WP7. But, that progress bar is not perfect either, it will actually continue executing the animations even if the progress bar is invisible. Toggle visible on and off is often how we show/hide the progress bar, but setting it to indeterminate will make the animation to continue even when it is hidden. So in this case you should also toggle the IsIndeterminate property using the same data binding you use to toggle it’s visibility.


<ProgressBar IsIndeterminate="{Binding IsProgressBarVisible}" Visibility="{Binding IsProgressBarVisible, Converter={StaticResource VisibilityConverter}}" >

The best option with respect to performance is to use the ProgressIndicator on the system tray on an application page. It performs very well and I have never had any issues with it, even when totally blocking the UI thread and have really advanced animations handled by the composition thread.

I often hear that we don’t want to use the ProgressIndicator since that requires the system tray to be visible and it will make the app look bad. But remember that you can set colors, opacity etc. on the system tray so it should not be to hard to design it to fit to the overall design. Changing the opacity on the system tray to something less than 1.0 will make the system tray hover over the page and let the page take the entire area, so you could also toggle the visibility of the system tray in the same way you toggle the progress indication.

Performance Counters


These counters are really important to use and understand, they are in great help when you try to find what the actual performance issue is. You enable/disable the performance counters by toggling EnableFrameRateCounter property in the App constructor.


Composite Thread – Aim for 60 FPS, it becomes red when under 30. 30 FPS doesn’t sound to bad, but MSFT has seen that the experience is not perfect when you come under that threshold, it just doesn’t look and feel good. So try to get at least 45 but aim for 60!

UI Thread – Becomes red when counter is under 15

Video Ram – the number of textures that has been created for all objects, for example a button that has been rasterized to a texture and drawn on the screen.

Internmediate textures – textures that SL has created for us to improve performance. If two or more textures are placed on the same layer, then SL will create one large texture of it so that we do not have to send one texture for each object, instead SL will just send one large.

Fill rate – fill rate tells us how many pixels that we send to the screen in each frame. A fill rate of 1 means that 800×400 pixels are drawn in each frame. There will be performance implications if the fill rate comes larger than 3, to much pixels to process and we get a drop in frame rate.

Redraw Regions

Objects that are animated but does not change, that is, pixels in the image looks identical in each frame but the object is moving, then SL will not have to send all the pixels over and over again to the GPU to calculate what is to be drawn. Instead the composition thread will just animate the object and render the same texture over and over, just in new positions.

By enabling Redraw Regions, then each time SL need to re-calculated and send pixels to the GPU it will be shown by a color tint on the texture with different colors. If we see a lot of flickering then we now something might be wrong.

You enable redraw regions in the same way you enable performance counters, but by toggling the EnableRedrawRegions property.


If we have a lot of flickering and want to remove that due to performance hit, then what we want is to cache the texture on GPU and only tell it to move the object and draw it again, we do not want to send the same pixels over and over again when they are not changing.

Recall in the section above about performance counters and intermediate textures, these sound really good but there might be times when intermediate textures means performance issues. If we have one or more moving objects on the same layer as for example a button, then SL will try to be smart and create an intermediate texture out of these, but since we are animating the objects the intermediate texture needs to be recalculated in each frame and sent to the GPU, so we get a performance drop due to that.

In this case we want to do two things, first of all make sure that pixels for an object that is not changing is not sent to the GPU in each frame and also prevent an intermediate texture from being created since it doesn’t add anything, just gives us worse performance.

The solution to this is setting cache mode. SL is smart and does this for us, but not in all types of animations. If we use a per-frame callback for animations then SL will not cache the texture for us. You set the cache mode manually by setting


for each object you want to cache.


Look at the left part, a lot of redrawing is done while the rectangle is animating to the right

Fill Rate

So fill rate tells us how many pixels we send to be processed in each frame. It’s important to understand that fill rate will increase by 1 if you explicitly set background color on the page. So setting background color on pivots, panels etc. is something you should avoid unless you really need to.

Bitmap Cache sounds like a “silver bullet” if you look at the above example about redraw regions. So shouldn’t we just set cache mode on all objects?

It sounds like a good idea, but the answer is NO! Caching an object means that we increase fill rate since each object becomes its own object that needs to be rendered. And an increased fill rate means a drop in UI thread FPS. For example, if we have an application with a background image of a sky, then several of other images that builds up the scene like trees, hills, bushes, birds etc. If we then set explicit caching on all objects then we will have several layers that the GPU needs to render, even if the texture for one object is not even visible since some other object is drawn in front of it. But if we do not set cache mode explicitly then SL will be smart and create one intermediate texture for us and cache just ONE texture instead of one for each object.

So it really depends on your app, and you have to be smart on when to use and not use bitmap cache, be ware of fill rate. So USE performance counters, use redraw regions etc. to figure out if your app is performing well or not.

Data serialization/deserialization

A Windows Phone app has the possibility to store data on “disc” where all I/O operations are working through Isolated Storage. WP7 works in a sandboxed environment separated from all the other apps on your phone, so it is “safe” to store application specific data on the phone without worrying about other apps accessing your data.

There is a specific API that makes it possible to save application settings as objects in isolated storage really easy, which facilitates storing simple objects a lot.

IsolatedStorageSettings.ApplicationSettings[yourKey] = yourObject;

Even though it is simple to store objects in application settings, you will probably need to serialize and deserialize more advanced/complex objects in isolated storage throughout the application lifecycle. Below are some common occasions when you need to serialize and deserialize data.

  • App Launch – Deserialize
  • App being dormant/tombstoned – Serialize
  • App being reactivated – Deserialize
  • App being terminated – Serialize

So what do we have to think about when serializing data? The most important thing is how long it takes to serialize/deserialize data and when you do it.

First of all there are certification requirements that could be jeopardized and eventually hinder your app from being accepted to marketplace.

Launch Time, your main screen of the app needs to be rendered and shown within 5 seconds and the user needs to be able to interact with your app within 20 seconds.

Activation Time, if an app is deactivated (for example the user clicks the hardware Start button) and later activated, then the app needs to start with the same criteria as app launch time.

Most of our apps will have to save lists of object that you need to cache for quick access when the user returns to your application. This means that we need to serialize data to XML/JSON or some other format when the app is de-activated and when the user returns and the app is re-activated, data needs to be deserialized from isolated storage to a list of objects.

This serialization and deserialization can take time and if we do it in Application_Launching or Application_Activated event handlers then we could end up with performance issues at app startup. You need to think about where and when you need the data, make sure long running processing is done in background workers to prevent blocking the UI. For example, if you have a lot of data that you need to deserialize when starting your app, your app is useless without it, then think about other “dirty tricks” of how to fool the user into believing that your app is starting quickly. Perhaps use a second splash screen, you could even make the second splash screen look like your app (that is take a snapshot of your app en store it as a jpeg) and show that while you are deserializing data.

It is also important to select the correct serialization type, there are several options where some of them are shown in the table below with metrics showing how long it takes to serialize/deserialize 200 objects and 18 000 objects.

Isolated Storage Demo (executed on phone)

200 serialized 200 deserialized 18000 serialized 18000 deserialized
XML 76ms 174ms 6.1s 14.4s
DataC 149ms 191ms 12.9s 16.3s
DataCJSON 131ms 98ms 11.1s 8.4s
JSON.NET 63ms 147ms 5.2s 12.7s
Sharp 282ms 101ms 10.7s 9.6s

Note that this is just how it turned out in my sample app, the numbers could be totally different for your objects so you need to profile and try out different formats before you decide what format you should serialize data to. Most common is using JSON.NET in my experience.


As with serialization and deserialization to and from isolated storage, it is equally important to think about the size of messages that you send and receive over the wire. So use the above table to figure out what type of message to send when creating web services that are consumed from your Windows Phone application. It’s really simple to create a RESTful web service that provides JSON formatted output, so start with that unless you need a specific format.

Below is a screen shot of the message size for different types of message formats. (the sample app fetches all the suppliers that exists in the Northwind database)


JSON data sent: {“Address”:”49 Gilbert St.”,”City”:”London”,”CompanyName”:”Exotic Liquids”,”ContactName”:”Charlotte Cooper”,”ContactTitle”:”Purchasing Manager”,”Country”:”UK”,”Phone”:”(71) 555-2222″,”PostalCode”:”EC1 4SD”,”SupplierID”:1},{“Address”:”P.O. Box 78934″,”City”:”New Orleans”,”CompanyName”:”New Orleans Cajun Delights”,”ContactName”:”Shelley Burke”,”ContactTitle”:”Order Administrator”,”Country”:”USA”,”Phone”:”(100) 555-4822″,”PostalCode”:”70117″,”Region”:”LA”,”SupplierID”:2},{“Address”:”707 Oxford Rd.”,”City”:”Ann Arbor”,”CompanyName”:”Grandma Kelly’s Hom… and so on…

WebClient vs HttpWebRequest

WebClient is a wrapper class around the HttpWebRequest class that is used to perform Web service requests. WebClient can be easier to use because it returns result data to your application on the UI thread, and therefore your application does not need to manage the marshaling of data to the UI thread itself. However, if your application processes the web service data on the UI thread, the UI will be unresponsive until the processing is complete, causing a poor user experience, especially if the set of data being processed is large.

My suggestion is to use HttpWebRequest instead of WebClient and process the resulting data on the asynchronous request thread and then use BeginInvoke to marshal the data to the UI thread.

Making Large Numbers of Requests for Small Amounts of Data

To preserve battery life, the operating system will turn off the device’s radio after a preconfigured timeout interval. If an application is going to make a large number of requests for small amounts of data, I recommend that these requests be executed in parallel instead of serially. This helps to ensure that the device’s radio stack will not go to sleep, avoiding the lag incurred when the radio is powered on and off for each request and also saving battery life. Although there is a limit on maximum outbound network calls the rest will be queued and processed as soon as possible.

Where does it usually go wrong?

Below I’ll try to summarize some of the common performance issues that I have encountered and how to fix them.


Performance issues at startup is probably the most common problem I encounter when helping customer with their apps and causes everything from failed marketplace submissions to users giving up on your app since it takes to long to load and you end up with bad reviews and in worst case no one using your app.

Imagine that you start an app, see the splash screen and eventually the app is shown quickly, but it is really jerky, doesn’t seem to respond to user input and so on. These are the performance issues you really need to think about to fix. So what is actually going on at startup?

Assemblies are loaded and jittered, objects are instantiated and loaded and so on. Although the problem usually doesn’t reside here but it could. More common is what happens after that and all processing that needs to be completed before the app is “done” and fully ready for usage, deserialization of state (tombstone), loading UI (which means XAML parsing, element creation, layout calculations, redering etc).

So what can we do and what should we do to increase app startup time?

1. use a Splash screen and load data during startup. But if the app loads really quickly then you should perhaps remove the splash screen, only use if you need it. Don’t spend time designing the super cool and awesome looking splash screen since it could be so that the app starts really quickly and the user will not really see it to long. I have actually heard about cases when developers has put a Thread.Sleep() during startup to make sure the splash screen is visible longer. Not a good approach :) When the app is loaded you continue loading data that should be shown in background threads and when done publish/display it on UI using the dispatcher.

2. Use a second copy of the splash screen and show that as the first thing in your app with a progress bar if you need to load data from a web service or do something that takes time. But try to avoid this since the user wants to get into your app quickly and immediately start interacting with it. And even if you use a second splash screen with a progress bar you cannot take all the time you want, a max of 3-4 seconds, after that the user will start loosing his/her patience.

3. Keep the assembly size small of all the assemblies that are being loaded at startup. If your assemblies contains complex and demanding constructors, make sure to refactor and move the code to separate assemblies. If the app contains a lot of media like images, videos etc. then think about if you can set “build mode” as Content. If build mode is set to “embedded resources” then they will be loaded each time and make the loading of assemblies heavier, as build mode “Content” then assemblies will be loaded a lot quicker and content will be loaded “on demand”.

4. Keep your XAML clean and as simple as possible, try creating a small visual tree as possible to optimize layout calculations and rendering. Delay creation of controls to a later time when they are really needed and shown. For example in a Panorama all items will be loaded and kept in memory, which means that if you have 5 panorama pages, then all pages will be parsed, loaded and rendered (measure, arrange, bind etc.) on all UI if you do not create a custom page/control virtualization. You could optimize this by only loading the first and +/- one page and when the user pans load adjacent panorama pages and controls.

The Pivot control is using virtualization by default. 3 pages are loaded and kept in memory, current, previous and next pivot page.

One way is to set page visibility as Collapsed until they are needed (this means that they will not even be in the visual tree). But remember that even if you set visibility as Collapsed calculations and processing will still happen before they are eventually hidden from UI. A better approach is to remove XAML and manually add it when needed.

5. A somewhat strange but pretty cool solution is to take a screen shot of the app where you have hidden all dynamic data and then use that as a “second splash screen” while the app warms up loading data etc. and then do a nice fade from “splash screen” to the actual app with live data. In this way we are tricking the user to think that the app starts really quickly, loads some data and shows it. But be aware, this solution could give the wrong feedback to the user since the users cannot interact with the app directly if not done correctly.


When we now have followed all the advices above and the app starts really quickly we often hit the next common performance issue and that is with lists. It often feels like lists are not scrolling fast enough and are a bit jerky, they simply doesn’t perform good enough.

The problem is probably not that the lists doesn’t scroll fast enough, more common is that the phone doesn’t have time to render the UI while you are scrolling quickly.

Long lists are using virtualization by default, which means that SL will keep 3 full “pages” of elements in UI and memory and while we are scrolling new “pages” will be loaded as needed, which means parsing XAML, generating new objects, inserting these into the visual tree, layout calculations, measure, arrange, bind and so on. So there is a lot that needs to be done and if SL doesn’t have time to process this then, bam, you get black “pages” that show up and it feels like the list doesn’t scroll fast enough.

So what should we and can we do to optimize lists?

1. If the list is short, less that 3 full pages, then you should try to use a regular stack panel instead of a virtualizing stack panel (easily accomplished with templates). Using a stack panel all objects will be loaded immediately and you get a perfect scrolling experience.

2. Try to delay loading and processing while you are scrolling, you might end up with scrolling past objects that you will not even see in the end and then it is useless to loaded and process these objects. For example, if you have a list of images that are downloaded from Internet and when you scroll past a lot of images quickly then you do not need to load the images since the user will not even seem them when he/she stops scrolling. Listening to the scroll event is trivial and easy to implement.

3. Another problem is XAML itself. Windows Phone will not cache Data Templates and Control Templates after they are parsed, so by making simpler XAML and binding to less properties you will increase performance. Make sure you do not set properties in XAML that are default values, since that only adds more processing and try to avoid having objects as Collapsed that you don’t even need, they will add processing and eventually a performance hit.

4. Try to avoid value converters in data bindings. Data binding is a low-level operation and if you need to call external code to calculate values then you will have to pay for that. Instead use a ViewModel approach and add convenience properties that gives you the value directly. It is often really easy and possible to add more properties to your ViewModels to contain all the values your UI needs to show, and in the end not use value converters in lists at all.

5. If you still need really advanced XAML and perhaps different XAML for different items in the list then there are some more advanced techniques to use.

A ListBox will by default recycle containers, which is good, we want that to keep our memory footprint low, but there are scenarios where Data Templates becomes really advanced and you might end up with several visuals that are Collapsed or a very complex UI. Again, this means a lot of parsing, object creating etc. that in the en will be hidden for the user. A common solution I usually try to follow is to create one simple base data template that only contains the parts that always will be visible on all items in the list and then manually in code behind decide what XAML should be in the item and manually add them to the visual tree.

The process is fairly simple:

a) start with a “dummy control” with a Control Template that shows elements that are always visible for all list items.

b) create an Attached Property for the control.

c) set the value for the attached property using regular data binding and in the implementation of the attached property and “Property Changed” event handler you generate/create the UI elements needed for the specific item and manually add them to the visual tree.

6. Use third party list controls. There are several developers that has tried to tackle the performance issues with lists, some are good some are not so good, they all seem to have good and bad “features”.

a) DeferredLoadListBox, by David Anson. This list uses a regular stack panel and delays loading of controls. But there is an issue with this control (unless that is fixed in later version then I have tested) and that is that items are not unloaded when they are not used/visible which means that if you have a really long list and scroll a lot, you will hit a memory problem.

b) LongListSelector is an ItemsControl in Silverlight Toolkit that virtualizes the list without using a VirtualizingStackPanel, you can even tweak some parameters like how many pages to keep in memory and how fast it should scroll.

c) LowProfileImageLoader is another awesome control by David Anson and this class helps us with preventing that we load images on the UI thread. This one I have used a lot and think it is a really great asset.

d) LazyListBox by Peter Torr, it basically delays work until we are not scrolling.

So try them out and pick one that suits your needs.


Problems that usually occur is that the UI doesn’t really feel like it responds to user interaction, it might be hard to pan in a panorama or change pivot, you might have to try several times before anything happens. These are really common in several apps I have used and is extremely frustrating every time.

Issues like this most likely is due to that the UI thread has to much to do, remember that the UI threads is responsible of handling touch, parsing and creating objects, rendering/rastering visuals, processing per-frame callbacks etc. so the UI thread has a lot to do as it is, and if we start to do to much work on it our app will have to pay for it. But it can also happen if we do to much work in background threads which also might result in UI thread gets to little time to process.

So what can we and should we do?

1. Simply stop processing to much work on the UI thread, make sure you move any heavy work to a background thread. If you still have issues since the work is to heavy anyway, then you can add artificial sleeps to give the UI thread some slack. Simply add a 1 ms second sleep, Thread.Sleep(1); , and the UI thread will perform a lot better. A 1 ms sleep is something that the users will most likely not see or know about.

2. Use PerformanceProgressBar or ProgressIndicator

3. Try not to use color animations since these will be executed on the UI thread. You can often accomplish the same effect by animating the opacity, but remember that animations with OpacityMasks will be executed on the UI thread so try to avoid using opacity masks on objects that are animated often. I’m not implying that you should never use opacity masks, but you need to think about the consequences. If you need an opacity mask then there is a simple trick that you can use. Place the object in a Canvas and set the CacheMode to BitmapCache and then animate the container instead of the object itself.

4. Use RectangularGeometry for clipping paths on objects that are animated or drawn often, all other types of paths will be sent to the UI thread for processing.

5. Popup is also rendered on the UI thread, might want to change this to a simple Panel where you set z-index and toggle it’s visibility instead, you will get a lot better performance and even support for orientation change in your app.

As I wrote in my previous post about the importance of UX, the perception of how the user thinks your app performs is key. UX is King! So all the “dirty tricks” your can think of are valid, as long as the users gets the impression that your app is performing really well, then all tricks are valid. So be creative and think about how can we trick the user into believing that your app is super fast.

Background Agents

You have the possibility to schedule one Background Agent per application which is executed while your app doesn’t have focus. Each background agent can execute one or both of the following:

Periodic Task – is executed approximately each 30 min or so and is allowed to execute for 25 seconds, use less than 6MB of memory and is automatically un-scheduled if it has more that two adjacent crashes.

Resource Intensive Task – executed if the phone is charging, has WiFi or USB pass through (connected to the computer), the screen is locked and the battery is over 90% charged. So this will most likely occur for example while you are charging your phone during night. A resource intensive task is allowed to execute for approx. 10 minutes and use a maximum of 6MB of memory.

In any of the tasks you can do/access the following

  • Titles
  • Toast
  • Location
  • Network
  • R/W ISO Store
  • Sockets
  • Most of the framework API

The following is not allowed

  • Display any UI
  • Use XNA
  • Access the microphone or camera
  • Sensors
  • Play media (only use background audio API)

I usually ask myself, do I really need a background agent?

If you do, then make sure you do not have any important functionality in them since there are several ways to disable them or prevent them from even being executed:

  • to many are already running, you cannot schedule any more
  • not available at all on 256MB devices
  • prevented by the user in settings
  • battery is to low


You should think about background agents like Batman and Robin, Batman does all the important stuff (your app) while Robin is there once now and then and helps out doing some really simple stuff (your background agent), but Batman is so awesome so he can always handle everything himself, not dependent on Robin at all. You should implement your app the same way, they have to function to a 100% without background agents. I usually try to avoid using background agents in the first place since there are so many cases that could prevent them from being executed in the first place and instead invest in a Push Notification solution.

Location in background agents

if you need to get hold of the geo location in a background task then you might end up not getting them in time. Since a periodic task only has a few seconds to execute them you might not have time to start the GeoCoordinationWatcher to get the exact position. What you can do is to create a GeoCoordinationWatcher object and them immediately get the location, you will then get a cached position that the phone caches for you automatically around each 15 minute or so. Not accurate but might be good enough.

ISO store is available for background agents and is the same used as for the app, so you can easily share information between the app and your background agent. Although there are cases where the agent may try to access the same file in isolated storage at the same time as your app. If you start to or could encounter these types of issues then you should use a Mutex.

Debug background agents using

ScheduleActionService.LaunchForTest(“task name”, TimeSpan);

In that way we can schedule our task to execute each minute or some other timespan that is suitable for testing instead of waiting for 30 minutes. If you start your app debugging and exit the app by pressing the hardware Start button then Visual Studio will not stop debugging so you can easily place break points in your OnInvoke method to debug your task.


Re-Schedule often, each time you start your app since a scheduled agent will be removed after 2 weeks by the phones OS.

Do NOT implement critical functionality in a background agents since it is not sure that your agent will even execute.

if you need a more secure functionality to execute some code now and then to update Tiles or show Toast notifications then evaluate if you cannot use Push Notifications

Well that’s it for now regarding Performance Best Practices for Silverlight Windows Phone apps. There is so much to think about when it comes to performance optimizations, but this post might have given you something to think about and at least gotten your attention on how important it is and that you should always think about it while developing apps for The phone.

Happy Coding!

%d bloggers like this: