Arik Poznanski's Blog : Recipe

WPF Single Instance Application – Update

arik — Tue, 05 Apr 2011 03:36:40 GMT

Back in this post I’ve presented some code that make sure you only have one instance of your application.

As I’ve said before, I didn’t wrote this code, I just presented it since I came across it in a Microsoft reference application and didn’t want this gem to remain hidden.

Microsoft recently released a Windows 7 Recipe named “Windows 7 Taskbar Single Instance”, which despite its taskbar-related name is simply a revised implementation of the single instance feature in both .NET and C++. There are well documented samples for both cases. The credit for this recipe goes to Eran Stiller and Yochay Kiriaty.

I advise anyone who needs this feature to work with the new recipe.

That’s it for now,
Arik Poznanski.

Shake Gestures Library – A Windows Phone Recipe

arik — Sat, 02 Apr 2011 03:34:51 GMT

Note: the following article was first published as part of the Windows Phone Recipe “Shake Gestures Library” found here, which I wrote for Microsoft, together with Yochay Kiriaty.

Document Purpose

This document introduces a helper library for identifying shake gestures by using the accelerometer built into Windows Phone 7 devices. It explains how to use the library, how the library works internally, and how you can configure the library’s parameters to adapt gesture detection to your needs.

Library Features

The shake gestures library uses the accelerometer to detect movement in three directions:

Left-Right (X direction)
Top-Bottom (Y direction)
Forward-Backward (Z direction)

If you’re looking for a general purpose shake gesture and don’t care about the direction of the gesture, then you can simply use any combination of one or more of the supported gestures. However, sometimes you need to have better control and to understand if the gesture was in the “right” direction.

How to Use the Shake Gesture Library

Since the shake gesture library is doing all the heavy lifting for you, using the library requires very little effort from you.

Step 1: Add reference to shake gestures library: ShakeGestures.dll

Step 2: Add a using statement to file header

using ShakeGestures;

Step 3: Register to ShakeGesture event

// register shake event
 ShakeGesturesHelper.Instance.ShakeGesture += new EventHandler<ShakeGestureEventArgs>(Instance_ShakeGesture);
 
 // optional, set parameters
 ShakeGesturesHelper.Instance.MinimumRequiredMovesForShake = 5;

Step 4: implement the ShakeGesture event handler from step 3

private void Instance_ShakeGesture(object sender, ShakeGestureEventArgs e)
 {
     _lastUpdateTime.Dispatcher.BeginInvoke(
         () =>
         {
             _lastUpdateTime.Text = DateTime.Now.ToString();
             CurrentShakeType = e.ShakeType;
         });
 }

The ShakeGestureEventArgs holds a ShakeType property that identifies the direction of the shake gesture.

Finally, you need to activate the library, which binds to the phone’s accelerometer and starts listening to incoming sensor input events.

// start shake detection
 ShakeGesturesHelper.Instance.Active = true;

Note: You can continue working directly with the phone’s sensor. The ShakeGesturesHelper class doesn’t block any sensor events—it just listens to them.

Note: The ShakeGesture event arrives on a thread different from the UI thread, so if you want to update the UI from this event you should dispatch your code to run on the UI thread. This can be done by using the method myControl.Dispatcher.BeginInvoke(), where myControl is the control you want to update.

How Does the Shake Gesture Library Work?

We need to figure out what a shake gesture is and how to identify a shake when it occurs. Then we need to classify the shake according to the gesture direction.

The accelerometer sensor in a Windows Phone measures the gravity forces applied on the phone and reports an AccelerometerReading event about 50 times per second. When you move the phone up and down in 3D space, you’re getting a lot of readings (the sensors are quite noisy), and you don’t really know the phone’s orientation or the distance that the phone moved, since all you have are changes in the relative gravity force on the phone during a given period of time.

With that in mind, we set out to create a simple, high-performance shake gesture library, and came up with the following shake gestures detection process:

Noise reduction
Segmentation into "Shake" and "Still" signal segments
Shake direction classification

We report sensor readings as vectors, since we obtain 3-axis readings (X, Y, and Z, with each having a double value associated with it). We can set the initial point to (0, 0, 0), hence a vector.

Noise Reduction

Before performing gesture detection, the noise must be removed from the accelerometer’s input vectors. This is done by passing the raw input vectors through a low-pass filter. This smooth the signal so that it ignores small changes and only takes into account any “large enough” changes. We’re using an existing noise reduction implementation by Dave Edson. For more details on Dave’s algorithm, check out this blog post.

Figure 1: Before noise reduction

Figure 2: After noise reduction

As you can see, the signal after noise reduction is much cleaner and easier to work with.

Segmentation into Shake and Still Signal Segments

After cleaning the signal, our next step is to separate shake and still segments. Basically, we want to identify shake segments when the following conditions are satisfied:

The magnitude of one or more of the vectors (X, Y, or Z) crosses a certain threshold.
The vector stays above this threshold long enough so that we don’t mistake a one-time blip for a shake.

Note: We don’t use a system timer to measure time. Instead, we depend on the fact that the Windows Phone sensor generates about 50 events per second, so the time between each event is around 20 msec. Therefore, five events total roughly 100 msec. You’ll see in the code that we measure event intervals and not real world clock time.

Figure 3: Signal segmentation

Ignore for a second how we calculate vector magnitudes; we’ll address that topic in the next section. For now, look at Figure 3. You can see from the green line pattern that it’s very clear when the phone was in a shake segment and when it was in a still segment. Therefore, our goal is to be able to understand when a series of vectors represents a shake segment. Once we identify a shake segment, we’ll further process it to extract the shake type and raise the shake event.

Calculating Gravitation Vectors

To start with, we need a reference point that reflects the still state of the phone. The Still segment is used to compute something we call the last-known-gravitation-vector. The last-known-gravitation-vector will be used later to eliminate the effect of gravitation when classifying the shake type.

Note: We can't assume that the gravitation vector will always have the value (0,-1, and 0) for two reasons:

Gravity isn’t exactly 1G everywhere on earth. It varies somewhat according to location and altitude.
The direction of the gravity vector depends on how you hold your phone. If you rotate it, the direction varies. If you’re moving, your hand direction varies.

To calculate the gravitation vector, we take the most recent vectors in the still signal (MaximumStillVectorsNeededForAverage parameter) and average the vectors that have very low magnitude (StillMagnitudeWithoutGravitationThreshold parameters. In case we don't have enough still vectors for a representative sample (MinimumStillVectorsNeededForAverage parameter), we abort the calculation, since we won't get a valid gravitation vector.

The gravitation vector is re-calculated for each new still segment that we get, to account for any changes in how you hold your phone. Remember that we’re looking for real time effects; therefore, we need to maintain an accurate state of the current gravitation forces that are affecting the phone.

Finding Signal Boundaries

Now, let’s assume the user starts shaking his phone. We need to find the shake segment starting and ending points. To do so, we use the following algorithm:

There are only two possible states:

Shake state – Indicates that we’re currently in the middle of a shake signal
Still state – Indicates that we’re currently in the middle of a still signal (that is, not in the middle of a shake signal)

Based on the current state and the input vector type, we decide what the next step is. Each time we get a new input vector from the accelerometer (after noise reduction), we check whether the vector magnitude is equal or larger than a certain shake threshold ShakeMagnitudeWithoutGravitationThreshold parameter. If it’s larger, then this input vector is addressed as a potential shake vector. Otherwise, it’s considered a still vector.

Per each input vector and the current “shake” state we use the following state-machine to determine the next state…

Condition: The current state of the phone is still, and the new vector has a still magnitude value.
Operation: Add the vector to the still signal array (the array is a cyclic array).
Condition: The current state of the phone is still, and the new input vector has a magnitude that is higher than the minimum shake threshold.
Operation: Set shake state, process still signal, add vector to shake signal array (this doesn’t mean that we identified a shake, we’re just adding it to the array for further processing later).
Condition: The current phone state is shake, and the new input vector has a shake magnitude.
Operation: Add vector to shake signal, try to process shake signal array. Here we’re actually trying to identify a shake, since we already got a few shake vectors in the array. Again, we need to wait for the minimum amount of shake vector before we can start processing a shake single.
Condition: The current phone state is shake, and the new input vector has a still magnitude (it’s below the minimum shake magnitude).
Operation: Add vector to shake signal, unless we’ve already received too many sequential still vectors (StillCounterThreshold parameter), in which case move the still vectors to the still signal and change the phone state to still state.

Shake Type Classification

It’s time to dive into the actual vector processing. The following describes the algorithm we’re using, but for performance reasons the code performs some of the processing while the shake vectors are being collected, but the idea remains the same.

Neutralizing Gravitation Effects (Removing Earth Gravity Effects)

All input vectors include the earth’s gravitation forces. And since we don’t have any idea about the position of your phone in 3D space, we don’t know which of the vectors (X, Y, or Z) is affected by the earth’s gravity. Therefore, we need to remove the earth’s gravity effect.

To eliminate the effect of gravity, we first reduce the last known gravitation vector from all the vectors in the shake signal. In this way, when we get acceleration in some axis we can be certain that the user moved the phone along that axis instead of wondering whether this is just the force of gravity trying to fool us. Therefore, for each input vector we’re subtracting the last known gravity vector.

Finding Shake Main Direction

Now we want to find the main direction of the shake signal, which can be one of the following three directions:

X (left-right)
Y (top-bottom)
Z (forward-backward)

To do this, we first need to find the main direction of each vector in the shake signal. We do this by checking which of the vector products has the biggest absolute value. To get a better feeling of why we’re breaking the vector into its products, let’s review a 2D vector. As you can see in Figure 4, the red vector products are broken into the X and Y values [Red value = sqrt(pow(x,2) + pow(y,2))].

Figure 4: Illustration of classifying a 2D vector

It’s clear that the red vector should be classified as an X axis vector, because its X product is much stronger than its Y product. The same methodology is implemented in the library for 3D vectors.

At this stage, we’ve got a vector that isn’t affected by the earth’s gravity, we’ve broken the vector into its products, and we know the main direction of the vector.

Our next step is to create a histogram of the vectors’ products, and then to select the direction with the most products in it. Remember, we started with a vector whose magnitude is strong enough to be considering a shake vector. We removed the earth’s gravity effect, and we broke it into its distinct products, and classified them. For example, Figure 5 shows a histogram of a shake signal that has most of its vectors pointing in X direction, hence the shake signal’s main direction will be X.

Figure 5: Histogram of vector directions in a shake signal

To prevent weak vectors (WeakMagnitudeWithoutGravitationThreshold parameter) that got into the shake signal from affecting the histogram result, we’ll only consider vectors above a certain threshold when calculating the histogram.

In addition, we’ll consider the histogram result as valid only if the number of vectors in the main direction passes a certain threshold (MinimumShakeVectorsNeededForShake parameter). This will enable us to eliminate false results due to histograms done on small amounts of data.

Recognizing the Gesture

Up until now, we’ve identified a movement of the phone in 3D space that’s fast (powerful) enough to be consider a shake. Basically, we know the shake signal’s axis, but that isn’t sufficient. In order to make sure the movement we detected is really a shake gesture, and not just a random (single) movement in one direction, we need to count several intervals of movement and, more importantly, changes in the vector direction. A shake is defined as a movement of the phone on one axis back and forth a few times.

To check whether the shake signal is a shake gesture, we’ll check the sign of the main direction coordinate. For example, if we found that the main direction of our shake signal was X, then we’ll inspect the sign of the X products of all the vectors in the signal. On a real shake gesture, we expect the sign to change a few times, since we move the phone back and forth and thus keep changing the force (acceleration), which translates to a direction change.

For example, in the following figure we see a normalized (without gravitation) shake signal of a real shake gesture. You can clearly see the main direction being Z, and the Z values go back and forth between positive and negative.

Figure 6: Example of a shake vector

In order to identify the gesture, we’ll count how many times the X values goes from positive to negative and back. If the count is bigger than MinimumRequiredMovesForShake, we’ll finally raise the shake gesture event!

Configuring Parameters

During the coding and testing of the library, we found that shake is very individualized. It depends on the nature of the application and the actual shake gesture made by the phone’s user. There are alternative algorithms available that are adaptive and learning algorithms. While these might be more accurate, they require a learning phase that we didn’t want to force on the end user and on the developer building the app. Therefore, we give you plenty of different properties to tweak and tune for your own purposes.

These parameters control various aspects of the gesture detection algorithm. By changing these parameters, you can change your application’s sensitivity to shakes and to the duration of a shake. All parameters have default values kept as constants in the library.

The following section describes the available parameters. Each parameter is mentioned in context in the above algorithm.

ShakeMagnitudeWithoutGravitationThreshold

Description: Any vector that has a magnitude (after reducing gravitation force) bigger than this parameter value is considered as a shake vector.

Default value: 0.2

StillCounterThreshold

Description: This parameter determines how many consecutive still vectors are required to stop a shake signal.

Default value: 20 (about 400 msec)

StillMagnitudeWithoutGravitationThreshold

Description: This parameter determines the maximum allowed magnitude (after reducing gravitation) for a still vector to be considered.

Default value: 0.02

MaximumStillVectorsNeededForAverage

Description: The maximum number of still vectors needed to create a still vector average. Instead of averaging the entire still signal, we just look at the top recent still vectors. This is performed as runtime optimization.

Default value: 20

MinimumStillVectorsNeededForAverage

Description: The minimum number of still vectors needed to create a still vector average. Without enough vectors, the average won’t be stable and thus will be ignored.

Default value: 5

MinimumShakeVectorsNeededForShake

Description: Determines the number of shake vectors needed in order to recognize a shake.

Default value: 10

WeakMagnitudeWithoutGravitationThreshold

Description: Shake vectors with a magnitude lower than this parameter won’t be considered for gesture classification.

Default value: 0.2

MinimumRequiredMovesForShake

Description: Determines the number of moves required to get a shake signal.

Default value: 3

Summary

In this document we showed how you can use the Shake Gestures Library in your application. We did an in-depth tour of the algorithms used for recognizing shakes. Finally, we skimmed through the various parameters that you can change to better fit gesture detection to your application’s needs.

Shake it up!

That’s it for now,
Arik Poznanski.

Ways to Load Applications Faster – A Windows Phone Recipe

arik — Fri, 25 Mar 2011 05:05:12 GMT

Note: the following article was first published as part of the Windows Phone Recipe “Ways to Load Applications Faster” found here, which I wrote for Microsoft, together with Yochay Kiriaty.

Purpose of This Document

This document introduces the loading procedure for Windows Phone Silverlight applications. It explains common mistakes that application developers make during application launch, and how those errors can increase the total application load time and harm the user experience. Next, this document describes some possible solutions for overcoming long load times and explains their implementation.

Application startup is also discussed in Performance Considerations in Applications for Windows Phone. That paper provides excellent background information and can help make your Windows Phone applications shine.

Windows Phone Application Flow: Launching, Running, and Closing

We can't talk about proper loading techniques and optimizing application startup time without explaining Windows Phone application lifetime events. The following section providers a short overview; for more detailed information, see Execution Model for Windows Phone.

Windows Phone provides developers with a series of events and APIs for handling tombstoning and other application state changes, which include launching and closing. The PhoneApplicationService class, found in the Microsoft.Phone.Shell namespace, provides access to various aspects of the application’s lifetime, including management of the application’s state when it becomes active or inactive.

The PhoneApplicationService class exposes four main lifetime events. For any auto- generated Windows Phone application (generated by Visual Studio 2010 Express for Windows Phone or Visual Studio 2010), the App.xaml.cs file includes four methods directly related to the execution model. These methods are your application handlers for the lifetime events exposed by the PhoneApplicationService class:

Application_Launching
Application_Activated
Application_Deactivated
Application_Closing

The names of these methods are self-explanatory. However, there are some subtleties that we need to cover:

Application Launching – A Windows Phone application is considered to be launched when it’s started by a means other than by the user pressing the Back button to return to a previous application. An application is launched when the user taps the entry for the application in the phone’s applications list or the tile for the application on Start. An application can also be launched when the user taps a toast notification.
Application Deactivated occurs when a different application takes control of the foreground; for example, when the user launches a chooser or presses the Start button. In both cases, your application will be deactivated; the Deactivated event is raised, as opposed to the Closing event when your application exits. However, unlike an application that’s closed, a deactivated application will most likely get tombstoned. Don’t become confused: A tombstoned application’s underlying process still gets terminated, so your application does “close.” But unlike a closed application (which has exited), where the Windows Phone operating system removes any trace of the application from memory, in the deactivated scenario the Windows Phone operating system stores a record (a tombstone) of the application's state. Basically, the Windows Phone operating system keeps a tombstone of the application that becomes part of the phone’s application back-stack, which is a journal that enables the use of the Back button to enhance navigation functionality.
Application Activated – After an application has been deactivated, it’s possible that it will never be reactivated. However, it’s also possible that the user will return to the application by pressing the Back button enough times to reach the application. When the user returns to a deactivated application, it’s reactivated and the Activated event is raised. Windows Phone then navigates to the last page viewed by the user in order to give the user the feeling that the application is simply continuing. Note that unlike Launching, some data objects in an Activated application might still be initialized.
Application Closing is simply the outcome of the user pressing the Back button enough times to navigate backwards through the pages of your application, and past the application’s first page. Currently, this is the only way for a user to exit your application. Once your application is closed, its process is terminated, the operating system removes any trace of that application from its memory, and there’s no way to return to the application other than by launching a new instance.

Note that Launching and Activated events are mutually exclusive, as are the Deactivated and Closing events.

These events play a critical role in your application’s loading and closing times. Loading time also applies during application tombstoning and, more importantly, for applications resuming from tombstone.

One last note before we continue. There’s a certain sequence of methods that gets called during launching and tombstoning. This method sequence is critical for optimizing load time operations.

For the most part, when your application is launching or returning from tombstone, the following methods are being executed in the following order:

Application constructor –App() found in App.xaml.cs
Application launching – Application_Launching found in App.xaml.cs
Your application’s “first page” constructor
Your application’s “first page” OnNavigatedTo method

Note: When returning from tombstone, the “first page” is the last page the application was showing, and not necessarily the actual first page of the application.

Note: When your application returns from a tombstone state, this entire sequence is executed. However, in cases where tombstoning is relaxed, and your application is deactivated but not tombstoned, the Application constructor and the Page constructor aren’t executed. For additional information about Application Lifetime events and tombstoning, see Execution Model for Windows Phone.

Application launch time is defined from the time Windows Phone loads your application into memory and starts executing the application constructor (the first method in the sequence) until the end of the execution of the OnNavigatedTo method first page.

Startup and Shutdown Times

Windows Phone enforces a series of time limits on application startup and shutdown in order to preserve a consistent and responsive user experience across the phone’s built-in applications and 3^rd-party applications. If your application exceeds the allowed time for startup or shutdown, it will be forcibly terminated and removed from the back-stack. This means your application doesn’t get tombstoned, it’s simply terminated, and the user can’t use the back button to reactivate it. The following table outlines launch shutdown, deactivated, and reactivated times:

Table 1-1. Application Startup / Shutdown times

Application Event	Limit
Starting the application (application Launching event)	10 sec
Forward navigating away from the application (application Deactivated event)	10 sec
Returning to the application using the Back key (application Activated event)	10 sec
Exiting from the application (application Closing event)	10 sec

You can see that you have up to 10 seconds of real-world time (this doesn’t mean that you have 100% of the CPU for 10 seconds) to handle each application lifetime event. If for some reason your code takes longer than 10 seconds to execute, the Windows Phone system will terminate your application.

Note: Besides the operating system safeguards, part of the Marketplace ingestion process is to check the time it takes to launch and to return from tombstoning. The user experience guidelines are even stricter, and require less than 10 seconds to properly launch your application. According to Windows Phone 7 Application Certification Requirements, the application must render the first screen within five seconds after launch, even when there’s a splash image. Therefore, optimizing and understanding the load sequence are critical to your application’s success.

Startup time – Includes launching or returning to a tombstoned application. It’s the time from when your application process starts executing until your application becomes active or visible. Your application becomes visible only after the execution of the OnNavigatedTo method ends of the page the application navigates to upon launch or returning from tombstoning. Until then, the application’s splash screen is displayed and the application isn’t considered active.
Shutdown time – Includes deactivating and exiting from the application, and mostly consists of the time from when the forward navigation was invoked until the Deactivated or Closing methods execution ends.

Demonstrating the Problem

As explained in the previous section, the application must complete its loading and display its first page (or any page when returning from tombstoning) within 10 seconds or the OS will kill the process. Moreover, even if your application launches in five or eight seconds, you still need to optimize the user experience by loading the application and displaying something as soon as possible; otherwise, the impatient user might tap the Back or Windows button to navigate away from your application.

So let's see how easy it is to create a well-behaved application. In the following demo we’ll create a Windows Phone Silverlight application that needs to execute some long operations while loading.

Note: Our example application describes a very simple scenario for a Silverlight application that displays some information on the first page. This information should be obtained from some web service or local storage. To illustrate the problem, we create a fake workload that intentionally takes about 10 seconds to complete.

To simulate a long operation, we’ll simply trigger a function that sleeps for a second and reiterate that 10 times. (See the MyService.Init methods below.)

To experience this firsthand, simply follow these steps:

Step 1: Create a Windows Phone Application

Step 2: Create long workloads

public class MyService
 {
     private const int NumberOfIterations = 10;
 
     public static void Init()
     {
         for (int i = 0; i < NumberOfIterations; ++i)
         {
             Thread.Sleep(TimeSpan.FromSeconds(1));
         }
     }
 
     public static void Init(Dispatcher dispatcher)
     {
         for (int i = 0; i < NumberOfIterations; ++i)
         {
             if (dispatcher != null)
             {
                 dispatcher.BeginInvoke(() =>
                 {
                     Thread.Sleep(TimeSpan.FromSeconds(1));
                 });
             }
         }
     }
 }

Essentially, both methods perform the same operation: they sleep for about 10 seconds to mimic a long workload. The second Init method accepts a Dispatcher as an input parameter that we use each in sleep period. This forces a sync with the main user interface (UI) page (since that’s the dispatcher we’re passing in), as it isn’t reasonable to write code that completely blocks the UI thread for 10 seconds. Eventually, calling the dispatcher allows Windows Phone to terminate faster, as you’ll see later.

Step 3: Call the long workloads from various locations in your application

Call the function MyService.Init from either one or all five methods:

1. App constructor

public partial class App : Application
 {
     public App()
     {
         ...
 
         MyService.Init();
     }
 
     ...
 }

2. Application Launching event

This event is raised when the user launches the application by tapping on the application’s icon.

public partial class App : Application
 {
     ...
 
     private void Application_Launching(object sender, LaunchingEventArgs e)
     {
         MyService.Init();
     }
 }

3. Application Activated event

This event is raised when the user taps the Back key to return to the application, or after returning from a chooser or a launcher.

public partial class App : Application
 {
     ...
 
     private void Application_Activated(object sender, ActivatedEventArgs e)
     {
         MyService.Init();
     }
 }

4. Page constructor

This function is called when the Page class is created.

public partial class MainPage : PhoneApplicationPage
 {
     public MainPage()
     {
         InitializeComponent();
             
         MyService.Init(this.Dispatcher); //Or you can run MyService.Init();
 
     }
 
     ...
 }

5. Page OnNavigatedTo method

This function is called when the page is navigated to, either from another page or when the application gets launched/activated.

Note: The problem shown in this demo also can occur when your application comes back from a tombstone state, so you need to make sure you don't have lots of work in the constructor and OnNavigatedTo functions of any of your pages in the application.

public partial class MainPage : PhoneApplicationPage
 {
     ...
 
     protected override void OnNavigatedTo(NavigationEventArgs e)
     {
         MyService.Init(this.Dispatcher); //Or you can run MyService.Init();
 
     }
 }

Step 4: Run your application

Simply run your application from your phone and observe that the operating system terminates your application. When it terminates your application depends on specific implementation criteria, as explained below.

Note: To test whether the Windows Phone terminates your application when your application’s load time exceeds the 10-second limit, you must run your application on a real device without attaching the debugger. You need to deploy the application to the phone and then run it. Don’t run the application from Visual Studio, as when the debugger is attached (either to your Windows Phone device or to Windows Phone emulator); the relevant watchdog timers are disabled and the application will simply load after all the fake workload methods complete their task.

If you use the Init without the dispatcher, then the sleep (on the main UI thread) prevents any operations from executing on the main thread (which is the main application thread). This is rather extreme and doesn’t represent a real-life scenario. So we’ve added a call to the dispatcher during each sleep period in order to sync back to the UI thread, and give the Silverlight runtime a chance to do what it’s supposed to do (terminate your application). Therefore, you’ll notice that when calling the MyService.Init method without the parameter, the application will eventually get terminated, but only after all the sleep periods occur (depending on how many times you called the MyService.Init method). When you pass the dispatcher as an input param (this is only possible in the MainPage), you’ll notice that your application terminates faster.

Try removing the MyService.Init method from the Application constructor and Launching method, but leave them in the MainPage constructor and OnNavigatedTo methods. You’ll see that it still takes about 11 or 12 seconds for the operating system to terminate your application. This again proves that it takes only one misbehaving method to significantly impair your application’s load time.

The Solution – Optimizing Your Application Load Time

Now that you understand the Windows Phone Silverlight application launch sequence and the problem of long launch times, it’s time to present some ways to optimize your application load times.

The solution is composed of four action items:

Use a splash image
Defer work
Do work on a background Thread
Use a loading page

Action Item 1: Use a Splash Image

The first thing you can do is to help to solve the user experience issue. If the user sees an image of the application that says "Loading…", he’ll wait a few more seconds before pressing the Back key out of frustration. Therefore, be smart and use a splash screen.

In fact, all Windows Phone project templates include a splash screen image. By default, this image is named SplashScreenImage.jpg, and it automatically appears when your application is starting. The default image looks like this:

Make sure to change the default image to something that suits the theme of your application. That way, when users see the splash screen (which happens instantly), they’ll recognize it as part of your application. Changing the default splash screen is also a Marketplace requirement.

Note: The image must have:

A size of 480 by 800 pixels
The filename set to SplashScreenImage.jpg
The Build Action set to Content

Action Item 2: Defer Work

This against everything your parents taught you, but when it comes to loading an application on Windows Phone, never do now what you can do later.

Postponing non-mission-critical work until after the application loads is always a good technique. At that point you aren’t constrained by time issues, and you might have time to run workload between user actions.

For example, suppose you write a Sudoku game for Windows Phone. You might be tempted to generate the Sudoku game map when the application loads. However, it would be best to delay this action until the application is loaded and the user selects "New game." At this point you can show some nice animation during the game setup process.

You should defer any workload that isn’t critical to the application launch and doesn’t have a severe impact on the user experience when the application loads. Always prefer lazy initialization of objects, which promotes deferring non-essential workloads.

Unfortunately, not every workload in your application launch sequence can be postponed. There are certain scenarios in which you can’t defer the workload to a later time in the application or until the user performs some operation. Some scenarios require you to run a workload as close as possible to the application start time. For example, consider an application that shows the top 10 trends currently on Twitter. Without the trends information, there’s nothing real to show on the application’s main page. However, we can't afford for the application to be terminated just because it’s getting the latest trends over the network.

To address scenarios in which your application has to complete some work close to startup time, you need to run some or all of the workloads in the background. This is exactly what we explain in the next section.

Action Item 3: Do Work on a Background Thread

This is probably the most important step in optimizing your application load time. To keep your application from hanging or terminating, the launch methods sequence must complete as soon as possible. If you can't defer a certain workload, you have to run that work in the background, that is, on a background thread.

You can use the following options:

1. Manually create a thread

using System.Threading;
 
 Thread thread = new Thread(() => { MyService.Init(); });
 thread.Start();

For additional information about manually creating threads, see the Thread Class documentation.

2. Queue work item into the thread pool

using System.Threading;
 
 ThreadPool.QueueUserWorkItem((o) => { MyService.Init(); });

For additional information about using the thread pool, see the ThreadPool Class documentation.

3. Use BackgroundWorker class

By using the BackgroundWorker class, you can assign a delegate that will perform the workload, as well as a callback method that will be executed once the delegate completes its operation.

To use the BackgroundWorker class, you’ll need to add a using statement for System.ComponentModel.

using System.ComponentModel;
 
 BackgroundWorker backgroundWorker = new BackgroundWorker(); 
 
 backgroundWorker.DoWork += 
     (s,e) => 
     {
         // runs on background thread
         MyService.Init(); 
     };
 
 backgroundWorker.RunWorkerCompleted +=
     (s, e) =>
     {
         // runs on UI thread        
     };
 
 backgroundWorker.RunWorkerAsync();

For additional information about using the BackgroundWorker class, see the BackGroundWorker Class documentation

When working with a background thread, you can’t directly update any UI control without marshaling to the UI thread from your back-thread. Silverlight offers a simple mechanism to do that by using the Dispatcher.BegineInvoke method.

Deployment.Current.Dispatcher.BeginInvoke(() =>
 {
     //This happens on UI thread, if you want to marshal info back to UI thread from any other background thread.
 });

Note: When working with background threads, you should always remember that UI components in Silverlight have thread affinity; that is, you can access a control only from the thread that created the control. So if you need to update the UI with progress/completed reports from the background thread, you should dispatch your code to run on the correct thread. This can be done by using the method myControl.Dispatcher.BeginInvoke(), where myControl is the control you want to update.

Action Item 4: Use a Loading Page

Now that you’ve moved some of the workload to the background, your application will load much faster and you should see your application’s first page rather quickly. However, most likely you’ve got nothing meaningful (such as the new data you’re fetching) to show, since the background thread is still executing. Therefore, If you started some work on a background thread , you should consider showing a busy/loading indicator, like a progress bar, during the wait time.

You should avoid having a separate page for the loading indicator UI, since it would become part of the application’s page back stack. This would create a strange scenario in which pressing the Back button from the main page would return the user to the loading page rather than exiting the app.

Instead, in your main page, add a grid that contains two controls: the “loading control” that will show loading information (indicator), and the actual main page content. Toggle the Visibility property of the two controls according to the current loading state. Also, if you set the ProgressBar’s IsIndeterminate property to true , turn it off once you no longer need the loading screen, or you’ll have performance issues. You can read more about this at A ProgressBar With Text For Windows Phone 7.

For example, the following XAML shows how a main page could be structured:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
     <Grid x:Name="loadingContent">
         <TextBlock 
             HorizontalAlignment="Center"
             VerticalAlignment="Center"
             Margin="0,-30,0,0"
             Text="Loading..." 
             />
         <ProgressBar
             x:Name="progressBar" 
             Minimum="0"
             Maximum="100"
             />
     </Grid>
     <Grid x:Name="mainPageContent" Visibility="Collapsed">
         <TextBlock 
             VerticalAlignment="Center"
             HorizontalAlignment="Center" 
             FontSize="56"
             Text="Main page data" 
             />
     </Grid>
 </Grid>

The following code shows how to use the BackgroundWorker class to do the work in the background, update the progress bar, and toggle Visibility when the work’s done:

MyService.BackgroundWorker = new BackgroundWorker()
 {
     WorkerReportsProgress = true
 };
 
 MyService.BackgroundWorker.DoWork +=
     (s, e) =>
     {
         MyService.Init();
     };
 
 MyService.BackgroundWorker.ProgressChanged +=
     (s, e) =>
     {
         progressBar.Value = e.ProgressPercentage;
     };
 
 MyService.BackgroundWorker.RunWorkerCompleted +=
     (s, e) =>
     {
         loadingContent.Visibility = Visibility.Collapsed;
         mainPageContent.Visibility = Visibility.Visible;
     };
 
 MyService.BackgroundWorker.RunWorkerAsync();

In order to receive progress updates from the background thread, we passed the BackgroundWorker to MyService class, and use the ReportProgress method:

public class MyService
 {
     private const int NumberOfIterations = 10;
 
     public static BackgroundWorker BackgroundWorker { get; set; }
 
     public static void Init()
     {
         for (int i = 0; i < NumberOfIterations; ++i)
         {
             Thread.Sleep(TimeSpan.FromSeconds(1));
 
             if (BackgroundWorker != null)
             {
                 BackgroundWorker.ReportProgress((i+1) * 100 / NumberOfIterations);
             }
         }
     }
 
     ...
 }

Another way to toggle between the controls is to bind the Visibility property of both the mainContent and loadingContent to a Boolean flag that signifies the loading state (for example, bool isLoading). To do that, you’ll need a class that implements IValueConverter to convert from bool to Visibility.

Summary

Windows Phone applications must load fast and provide a good user experience. This is enforced by the application certification process and by the operating system. While the sample provided in this article is rather simple, the concepts remain true for all Windows Phone applications, and the techniques explained here will work for any Windows Phone application.

Another important consideration is the actual versus the perceived user experience. There’s more than one way to show loading progress, other than a progress bar, but it’s important to show something that’s meaningful and tells the user,“Hey, soon you’ll see your favorite app.”

That’s it for now,
Arik Poznanski.