Category: XNA Framework

MessageBox, Navigation and Application Life Cycle

One of our applications failed certification today because of an issue I should have known about. Even though the scenario in which an exception occurs is fairly easy, solving the problem properly involves a little work and a little thinking. Other blog entries have been written about this particular problem, although suggested solutions did not seem to work for me. Let me first show the original code:

MessageBox and Navigation
  1. private void TurnCard_Click(object sender, System.Windows.RoutedEventArgs e)
  2. {
  3.     MessageBoxResult mr = MessageBoxResult.Cancel;
  5.     if (nrTimesClicked > 2)
  6.     {
  7.         mr = MessageBox.Show("Continuing now might confuse you. Try again tomorrow?",
  8.             "Continuing tomorrow?", MessageBoxButton.OKCancel);
  9.     }
  11.     if (mr == MessageBoxResult.OK)
  12.     {
  13.         NavigationService.GoBack();
  14.     }
  15.     else
  16.     {
  17.         Random r = new Random();
  18.         int card = r.Next(cardPages.Length);
  19.         NavigationService.Navigate(new Uri(cardPages[card], UriKind.Relative));
  20.         nrTimesClicked++;
  21.     }
  22. }

Running this code and clicking the Start button on the phone while the MessageBox is visible results in the following exception when running with the debugger attached (it results in an application termination when running stand-alone):


The NavigationFailed event is raised. This is caused by the fact that the MessageBox returns when clicking the phone’s Start button with a return value of MessageBoxResult.Cancel. Since in the above code fragment, the Cancel button is used to navigate to some page, even though the application is supposed to go to the background in order to display the start screen on the phone, navigation fails. The interesting part is that the application does not have a clue that the user pressed the Start button on the phone. So some thinking is required to fix this issue.

Single stepping through the problematic method TurnCard_Click showed another behavior:


This at least made clear that indeed the call to the NavigationService caused the problem. To solve the problem, what can be done is protecting calls to the NavigationService by catching this particular exception:

Protecting the Navigate method
  1. private void TurnCard_Click(object sender, System.Windows.RoutedEventArgs e)
  2. {
  3.     MessageBoxResult mr = MessageBoxResult.Cancel;
  5.     if (nrTimesClicked > 2)
  6.     {
  7.         mr = MessageBox.Show("Continuing now might confuse you. Try again tomorrow?",
  8.             "Continuing tomorrow?", MessageBoxButton.OKCancel);
  9.     }
  11.     if (mr == MessageBoxResult.OK)
  12.     {
  13.         NavigationService.GoBack();
  14.     }
  15.     else
  16.     {
  17.         Random r = new Random();
  18.         int card = r.Next(cardPages.Length);
  19.         try
  20.         {
  21.             NavigationService.Navigate(new Uri(cardPages[card], UriKind.Relative));
  22.         }
  23.         catch (InvalidOperationException)
  24.         {
  25.             ;
  26.         }
  27.         nrTimesClicked++;
  28.     }
  29. }

This does solve the problem, although I don’t like it that an exception is thrown in a situation that the operating system should somehow prevent us against (maybe by returning some other value when the MessageBox returns without the user clicking on one of its buttons). If you want to have a little more flexibility, and don’t mind coding a bit more, there is another possible solution. Instead of using a MessageBox, you can make use of the Guide.BeginShowMessageBox method that is defined in the XNA Framework. This method is a bit more complex, but also much more flexible then its Silverlight counterpart. BeginShowMessageBox is asynchronous, which means that you need to take care with calling code that is supposed to run on the UI Thread.

Using BeginShowMessageBox
  1. private void TurnCard_Click(object sender, System.Windows.RoutedEventArgs e)
  2. {
  3.     if (nrTimesClicked > 2)
  4.     {
  5.         ShowContinueMessage();
  6.     }
  7.     else
  8.     {
  9.         Random r = new Random();
  10.         int card = r.Next(cardPages.Length);
  11.         nrTimesClicked++;
  12.         NavigationService.Navigate(new Uri(cardPages[card], UriKind.Relative));
  13.     }
  14. }
  16. private void ShowContinueMessage()
  17. {
  18.     List<string> mbOptions = new List<string>();
  19.     mbOptions.Add("OK");
  20.     mbOptions.Add("Cancel");
  21.     string msg = "Continuing now might confuse you. Try again tomorrow?";
  22.     string title = "Continuing tomorrow?";
  23.     Guide.BeginShowMessageBox(title, msg, mbOptions, 0, MessageBoxIcon.Alert, EnteredAnswer, null);
  24.     messageBoxVisible = true;
  25. }
  27. private void EnteredAnswer(IAsyncResult ar)
  28. {
  29.     int? result = Guide.EndShowMessageBox(ar);
  31.     if (result != null)
  32.     {
  33.         messageBoxVisible = false;
  34.     }
  36.     if (result != null && result == 0)
  37.     {
  38.         this.Dispatcher.BeginInvoke(delegate
  39.         {
  40.             NavigationService.GoBack();
  41.         });
  42.     }
  43.     else if (result != null)
  44.     {
  45.         Random r = new Random();
  46.         int card = r.Next(cardPages.Length);
  47.         this.Dispatcher.BeginInvoke(delegate
  48.         {
  49.             NavigationService.Navigate(new Uri(cardPages[card], UriKind.Relative));
  50.         });
  51.     }
  52. }

The interesting code can be found in the EnteredAnswer method, where we retrieve the key the user entered in the message box. Since EndShowMessageBox returns a nullable integer, it has this nice way of using null in those cases where the user did not click any key (in other words, for instance when the message box is removed as a result of the application going to the background). So now we have a way of detecting if we can navigate (result has a value other then null). The sample code also sets a boolean variable messageBoxVisible, which is used in combination with PhoneApplicationPage.State to display the message box again when the user returns to the application. Hopefully this time the application will pass certification.

Using a BackgroundWorker to load SoundEffects into memory

In a previous post I showed you how to use specific XNA Framework functionality inside a Silverlight application for Windows Phone 7 to be able to use sound effects. Typically, when you want to play a sound effect you want to have it available immediately. As long as you don’t have too many sound effects to be played inside your application you can keep them all available in memory. However, you still need to load the sounds into memory at some time, typically when the application is started. Even if you don’t have too many different sounds that you want to use inside your application, loading sounds from a file into memory is still a time consuming operation, something that especially hurts your application during startup. After all, the end user that starts your application wants to work with it immediately, and it is a frustrating experience if you have to wait a while, even if it is only for a few additional seconds. The obvious choice in this situation is to load the sounds in the background, allowing the user to already working with the application. Of course I am using the sounds I am loading in the background as an example to show a BackgroundWorker in action. More long lasting operations (and not only during application initialization) are candidates to run on a BackgroundWorker. In a later blog post we will talk more about performance of Silverlight based Windows Phone 7 applications and things you have to think about. This post simply shows you how to use the BackgroundWorker. To talk about the BackgroundWorker we will take a look at the same application we used before when discussion the use of sounds inside an application. To separate sounds and sound handling from the rest of my application, I created a SoundPlayer class with a place holder for a number of sounds and a static method that loads those sounds from a number of wav files into SoundEffect objects:

  1. public static void LoadSoundEffects()
  2. {
  3.     soundLoader = new BackgroundWorker();
  4.     soundLoader.DoWork += new DoWorkEventHandler(soundLoader_DoWork);
  5.     soundLoader.RunWorkerCompleted +=
  6.         new RunWorkerCompletedEventHandler(soundLoader_RunWorkerCompleted);
  8.     soundLoader.RunWorkerAsync();
  9. }

In the above code snippet, a new instance of a BackgroundWorker is created and two event handlers are assigned to respectively the DoWork event and the RunWorkerCompleted event. Finally, the RunWorkerAsync method is called, which in turn fires the DoWork event on the BackgroundWorker, allowing the event handler to execute on a separate thread. You have to be careful not to update UI Elements inside the DoWork event hander. It is only allowed to update UI Elements on the thread that created them (typically the UI Thread). In this sample this is no problem since the BackgroundWorker is only used to load sounds into memory. If you need to update UI Elements on a separate thread you must make use of the BeginInvoke method of the Dispatcher class.

In this sample, the DoWork even handler is simple and straight forward. It looks like this:

  1. static void soundLoader_DoWork(object sender, DoWorkEventArgs e)
  2. {
  3.     int i;
  5.     soundEffects = new SoundEffect[nrSoundEffects];
  7.     for (i = 0; i < nrSoundEffects; i++)
  8.     {
  9.         Stream audioStream = TitleContainer.OpenStream(sounds[i]);
  10.         soundEffects[i] = SoundEffect.FromStream(audioStream);
  11.         audioStream.Close();
  12.     }
  13. }

We are simply reading audio information through a number of streams and store them locally. In order to read the audio files, they are defined as content in the Visual Studio project. When all sounds are stored (or in other words when we are leaving the DoWork method), the BackgroundWorker raises the RunWorkerCompleted event. In its event handler, for this example, we are simply unsubscribing from all events, because the BackgroundWorker to load sounds is only called one time:

  1. static void soundLoader_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
  2. {
  3.     if (soundLoader != null)
  4.     {
  5.         soundLoader.DoWork -= soundLoader_DoWork;
  6.         soundLoader.RunWorkerCompleted -= soundLoader_RunWorkerCompleted;
  7.         soundLoader = null;
  8.     }
  9. }

The BackgroundWorker has more functionality, for instance to report progress for long lasting operations. Progress information can be easily displayed to the user. In the above shown example, progress information is not used. The end result of using a BackgroundWorker is that the user interface remains responsive. In this particular example, the application starts pretty fast so that end-users can start playing while sounds are still being loaded.

If you are curious about this game, you can find it Clicker here on the Windows Phone 7 Marketplace. Note: This link will work from a Windows Phone 7, or from a PC with Zune software installed. The game has a trial mode so you can try it for free.

Adding Sound Effects to a Windows Phone 7 Silverlight Application

Certain Windows Phone 7 applications benefit from using sound effects, even if the application itself is written in Silverlight. You most likely have noticed that you can play media inside a Silverlight application by making use of the MediaPlayerLauncher inside your application to pass control to the integrated media player on the phone or by making use of the MediaElement class. Both these options are great if you want to play audio content under control of some form of media player (with MediaElement allowing to integrate player functionality inside your own application).

However, if you want short sound effects that play under control of your application, you can make use of functionality that is available in the XNA Framework, even if you are developing a Silverlight based Windows Phone 7 application. The XNA Framework contains a SoundEffect class. This class holds a sound resource in memory that can be played from inside your application by calling its Play method. You can even alter properties like the pitch and volume of a SoundEffect. Since there is interoperability possible between Silverlight and the XNA Framework (at least to a certain extend), it is possible to make use of SoundEffect inside a Silverlight application. However, given the different application models for Silverlight and XNA Framework applications, you have to be aware of what you are doing when added SoundEffect to your Silverlight application. A first attempt to add sound might look like this:

  1. using System.ComponentModel;
  2. using System.IO;
  3. using Microsoft.Xna.Framework;
  4. using Microsoft.Xna.Framework.Audio;
  6. namespace Clicker.Model
  7. {
  8.     public class SoundPlayer
  9.     {
  10.         public enum Sounds
  11.         {
  12.             Switch = 0,
  13.             Penalty,
  14.             StartGame,
  15.             HighScore,
  16.             EndGame
  17.         };
  19.         static SoundEffect[] soundEffects;
  21.         public static void Play(Sounds soundEffect)
  22.         {
  23.             if (soundEffects != null)
  24.             {
  25.                 soundEffects[(int)soundEffect].Play();
  26.             }
  27.         }
  28.     }
  29. }

This code snippet, taken from a real application, shows how to play a sound that was previously loaded into memory. To focus on playing sounds, loading the sounds into an array of type SoundEffect is omitted. When the static Play method of the SoundPlayer class is called, an exception is thrown.


The exception being displayed clearly indicates the cause of the problem. You can read more about solving this particular exception on MSDN, which contains information about enabling XNA Framework Events inside Windows Phone Applications. The information is very relevant, however, it explains how you should regularly call FrameworkDispatcher.Update(). Calling this method dispatches messages that are in the XNA Framework message queue for processing. The documentation gives the advice to call FrameworkDispatcher.Update() regularly, for instance on a timer. For playing single sound effects, this seems to be an overkill. After all, using a timer means that some code will executed repeatedly (in our case even if no sound is currently played). On a battery powered device like a Windows Phone 7 this means that we are draining more battery power then necessary. Instead, I simply modified my code by adding a call to FrameworkDispatcher.Update() immediately before calling the Play method on the SoundEffect object. This works fine in the following scenario:

  • The only XNA Framework functionality used inside a Silverlight application is one or more instances of type SoundEffect.
  • Only one single SoundEffect is played at any given time.

The following code snippet shows the modified Play method of my own SoundPlayer class (which is playing sounds as expected):

  1. public static void Play(Sounds soundEffect)
  2. {
  3.     if (soundEffects != null)
  4.     {
  5.         FrameworkDispatcher.Update();
  6.         soundEffects[(int)soundEffect].Play();
  7.     }
  8. }

In an upcoming blog entry I will show you how to load a number of SoundEffects into memory using a BackgroundWorker.

Using Silverlight or XNA in a Windows Phone 7 Application

Windows Phone 7 applications can either be Silverlight based or XNA Framework based. Often, it is obvious which framework to use for a particular type of application. Typically, games will either use Silverlight or XNA, depending on the desired functionality they need. All other types of applications typically will be Silverlight based although from a technical point of view it is possible to create ‘non-game’ applications using XNA as well.

Silverlight uses an event driven model for your application. Events are raised by the operating system (often as a result of some user action) and an application can either react on the event or ignore the event. Inside an application you will ignore the majority of events that will be raised, but act on a number of specific events to achieve the desired functionality of the application. A Silverlight based application is often battery friendly, especially if it only reacts on user actions. In this type of scenario, the application will be idle for most of the time. However, if repetitive behavior is needed for an application (for instance, a clock application might want to update the time every second), a timer object can be used that periodically raises an event on which your application can react. In this scenario you have to keep in mind that you are draining the battery faster, because your application is repeatedly executing code. If your application wakes up to react on a raised event, it will execute code that is defined in an event handler for a particular event. The event handler will get information from the operating system about the source that raised the event. That source, for instance, can be a User Interface element, an expiring timer or a hardware interrupt. Because the event sender is known, the application can assure that it executes the code, belonging to a specific event.

The XNA Framework uses a loop driven model for your application. Periodically your application will wake up and it is up to the application to determine if something needs to be done. In order to achieve this, every XNA Framework application maintains a ‘game loop’ that executes 60 times per second (when using default  values). It is the application’s responsibility to first Update the state of the application, for instance by getting user input, updating variables etc. Once a new application state is determined, the application is responsible to Draw to the Windows Phone 7 screen accordingly. Both Update and Draw will execute periodically, with Update taking priority over Draw. Note that these types of applications will drain the battery whenever the user is playing a game, because the application will wake up frequently, even if there is no work to do in either Update or Draw.

From a developer’s perspective, there are a number of reasons to either develop a Silverlight based Windows Phone 7 application or a XNA Framework based Windows Phone 7 application. Silverlight contains a nice collection of ready to use controls like buttons, text boxes etc. You can modify or extend these controls inside your own applications and you can create new controls. The XNA Framework contains functionality to make it relative easy for you to create 2D sprites that support rotation, scaling, stretching and filtering. There is also extensive support to create 3D graphics, including functionality for lighting and shading to create a great 3D experience. When making use of the XNA Framework however, you are responsible to create all of your artwork that is visible inside your application.

In certain situations, a distinct choice between Silverlight and XNA is not that easy to make. Also, in some scenario’s you might want to combine Silverlight with XNA Framework functionality. Using XNA Framework specific functionality inside a Silverlight application will be the topic of another blog entry. For now, if you want to know more about developing applications for Windows Phone 7 and if you want to read more about the initial choice between Silverlight and the XNA Framework, make sure to read this high level overview in the Windows Phone 7 documentation.