Tag: Windows Phone 7

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:

public static void LoadSoundEffects()
{
    soundLoader = new BackgroundWorker();
    soundLoader.DoWork += new DoWorkEventHandler(soundLoader_DoWork);
    soundLoader.RunWorkerCompleted += 
        new RunWorkerCompletedEventHandler(soundLoader_RunWorkerCompleted);
 
    soundLoader.RunWorkerAsync();
}

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:

static void soundLoader_DoWork(object sender, DoWorkEventArgs e)
{
    int i;
 
    soundEffects = new SoundEffect[nrSoundEffects];
 
    for (i = 0; i < nrSoundEffects; i++)
    {
        Stream audioStream = TitleContainer.OpenStream(sounds[i]);
        soundEffects[i] = SoundEffect.FromStream(audioStream);
        audioStream.Close();
    }
}

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:

static void soundLoader_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
    if (soundLoader != null)
    {
        soundLoader.DoWork -= soundLoader_DoWork;
        soundLoader.RunWorkerCompleted -= soundLoader_RunWorkerCompleted;
        soundLoader = null;
    }
}

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.

Another year, another MIX

Last year in April, the place to be was Las Vegas, NV for MIX 10. During this conference Windows Phone 7 was officially introduced. Immediately after MIX 10 the development tools were available for download. Also, the great content that was presented during MIX 10 is still available for you to watch. It seems hard to believe that we have been developing Windows Phone 7 applications for less than a year. We really have come a long way. Windows Phone 7 is released in a number of countries, devices are available in many more countries and the list of applications being released on Marketplace is growing rapidly.

Update: It is no longer possible to vote for MIX11 sessions. Thank you very much if you voted for one (or more) of my sessions that are listed below.

This year, before attending MIX, there is a call to action for everybody (especially for you since you are reading this blog post). You are in control of voting for a number of sessions of which the most favorite sessions will be presented at MIX. Amongst the Windows Phone 7 sessions that are up for voting, three were submitted by me. I am counting on you to help me become part of MIX 11. If you like the things I am writing on this blog or if you have seen me speaking in the past, or just because you are visiting this website, make sure to vote for my MIX 11 sessions. You can vote for all these sessions by clicking on the links. You can only vote for each session once on a physical machine, but of course I can’t prevent you against voting multiple times on different machines. Here are the sessions I submitted for voting (clicking on the individual links will bring you to the voting page for the particular sessions):

Windows Phone 7: Application Architecture

When you start developing Silverlight applications for Windows Phone 7 using Visual Studio 2010, you might be tempted to use code behind to connect your user interface (written in XAML) to your functionality (written in C#). In this sample filled presentation, Maarten Struys explains why this relatively easy approach is not necessarily the best approach to create testable, maintainable and great Windows Phone 7 applications. During the presentation, the power of DataBinding in Silverlight will be revealed and a traditional application, using code behind will be converted into an application that makes use of the MVVM design pattern.
Windows Phone 7 and the Cloud: The Sky is The Limit

Windows Phone 7 is a powerful platform for which you can create great stand-alone Silverlight based applications. To create Windows Phone 7 applications with limitless processing resources and virtually unlimited storage capacity, Windows Azure and Windows Phone 7 are great companions. In this sample filled presentation, Maarten Struys shows you how to create a Windows Phone 7 application together with a Windows Azure based back-end. He explains how the application can efficiently communicate with the back-end using a REST based Web Client interface. He also shows you how to efficiently cache information locally on the phone to make Windows Phone 7 applications operate independent of network connectivity. After attending this session you know how to create Windows Phone 7 applications that are as powerful as server applications.
Fast starting and State Saving Windows Phone 7 Applications

In this sample filled presentation, Maarten Struys shows you the impact of Tombstoning on Windows Phone 7 applications. He shows you how to store the application’s state and individual page state information efficiently. He also explains how your application can start fast and efficiently by making use of multithreading and asynchronous programming techniques. After attending this presentation, your Windows Phone 7 Tombstone headaches will be history and your end users will be happy with your fast starting applications.

Thank you very much for voting! I really hope to see you in Las Vegas between April 12 – April 14 for MIX 11. If you are planning to visit MIX 11, make sure to register before February 11 to benefit from a nice discount.

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:

using System.ComponentModel;
using System.IO;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
 
namespace Clicker.Model
{
    public class SoundPlayer
    {
        public enum Sounds
        {
            Switch = 0,
            Penalty,
            StartGame,
            HighScore,
            EndGame
        };
 
        static SoundEffect[] soundEffects;
 
        public static void Play(Sounds soundEffect)
        {
            if (soundEffects != null)
            {
                soundEffects[(int)soundEffect].Play();
            }
        }
    }
}

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.

Exception

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):

public static void Play(Sounds soundEffect)
{
    if (soundEffects != null)
    {
        FrameworkDispatcher.Update();
        soundEffects[(int)soundEffect].Play();
    }
}

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.

Modifying existing Silverlight Controls

During development of a brand new Windows Phone 7 application, I ran into a dilemma. The application is a game in which the user needs to memorize a number of fields. After the playing board has been displayed for a limited amount of time, the user needs to find particular fields by clicking on them. The playing board looks like this:

The different squares that are part of the playing board follow the theme color that the user currently has selected on the phone. Since the user needs to be able to click on the different squares, it is necessary to deal with some form of hit testing. In my initial approach I decided to build the different squares as Silverlight Rectangles, all hosted in an individual row / column inside a Grid control. Each time the user hits one of those squares, something has to happen to its appearance. In my first attempt (when creating a quick and dirty prototype), I decided to subscribe to the MouseLeftButtonDown and MouseLeftButtonUp events since Rectangles do not implement Click events. By handling both button down and button up events and capturing the mouse in between a button down and a button up event sequence, I made sure to have both events acting on the same Rectangle. Even though this approach is feasible, it takes a lot of code, just to make sure that a proper click is recognized on a Rectangle. Since this game needs to react very fast on user input, I want to execute as little code as possible to recognize which Rectangle is currently selected by the user. Also, I want to write as little code as possible, and the whole mouse capturing in combination with some different actions that need to be done on the user ‘clicking’ a Rectangle got me into writing more and more code. Until of course I realized that it was time to do some thinking and to make use of the power of Silverlight, extending existing controls and ‘good old object oriented programming’. What if I could make use of a Button control? Silverlight Buttons do expose Click events, the Button takes care of low level MouseLeftButton handling and contain lots of other functionality. In fact, Buttons contain too much functionality for the different items of my playing board. If you take a look at the Button documentation, you can see the different button styles and all different visual states, including animations that are used to move from one visual state to another. For my particular need, this is way too much functionality. So what if I can limit the functionality of a button (to only display a colored square and to expose a Click event)?

PlayButton – A very simple derived and restyled Silverlight Button

I started by creating a new Windows Phone Class Library to an existing solution in Visual Studio 2010. This Class Library contains my PlayButton class, that simply derives from Button. Replacing the original Rectangle controls on my playing board by PlayButton controls gave the following result:

Surely, the Rectangles are replaced by PlayButtons. Because PlayButton derives from Button without modifying anything, a PlayButton is simply a Button. This is the reason why a border is shown and why the theme color of the original Rectangles is lost. It also means that there are placeholders for Content and it is possible to act on Click events. However, each time a button is clicked it is going through a number of state transitions, potentially slowing down users that want to play this particular game. To overcome these issues, I created a brand new control template, including a default style to define and render my PlayButton. In order to work properly, the default style needs to be defined in a file called ‘generic.xaml’ that should be stored in a Folder called “Themes” inside the project that hosts the user control. In this particular case, my Visual Studio 2010 solution looks like this:

Instead of creating a new user control, including a control template and a default style, I could also have taken an alternative approach, using Expression Blend to create and modify a copy of the existing Button Control style and store the new style as resource in my Windows Phone application or in the Windows Phone application page where the style will be used. This approach is a little bit easier. I did chose to create a new default style for this particular application because I might want to re-use the PlayButton for a few other applications as well. The style I am using for the PlayButton defines a BorderControl that takes the Background and the Opacity that are defined for Button controls. The Background defaults to a PhoneAccentBrush, allowing the PlayButton to be theme aware. Here is the complete XAML for the PlayButton (definied in generic.xaml):

<ResourceDictionary xmlns="http://schemas.microsoft.com/client/2007&quot;
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml&quot;
                    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
                    xmlns:src="clr-namespace:ClickerControls"
                    xmlns:vsm="clr-namespace:System.Windows;assembly=System.Windows">
    <Style TargetType="src:PlayButton">
        <Setter Property="Width"
                Value="100" />
        <Setter Property="Height"
                Value="100" />
        <Setter Property="Margin"
                Value="2" />
        <Setter Property="Background"
                Value="{StaticResource PhoneAccentBrush}" />
        <Setter Property="Opacity"
                Value="0.5" />
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="src:PlayButton">
                    <Border x:Name="RootElement"
                            Background="{TemplateBinding Background}"
                            Opacity="{TemplateBinding Opacity}">
                    </Border>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

As you can see in the XAML, both the style and the control template specify the control for which they are intended (being src:PlayButton). All that is left to do is setting the DefaultStyleKey to refer to the default style for the control.

public class PlayButton : Button
{
    public PlayButton()
    {
        DefaultStyleKey = typeof(PlayButton);
    }
}

This is all there is to do to create a PlayButton which inherits Click events from a Button Control. The PlayButtons look identical to the original Rectangles, but they are simpler to use inside this particular application.

Hopefully, this blog entry helps you making a decision on re-using existing Silverlight controls. You can give existing controls a completely new look and feel by applying new styles. Often you might be thinking about adding functionality to existing controls or adding behavior to existing controls. However, it is also completely valid to limit existing behavior on controls, just like this example shows. The PlayButton acts on Click events, but the PlayButton itself will not give visual feedback when it is clicked or when the PlayButton is disabled. So it is really up to you to get all the functionality you want. In my opinion, Silverlight is extremely powerful in allowing you to alter the appearance of existing controls or create new controls based on existing controls. I get more excited by the day that this Silverlight based programming model is one of the two different technologies that you can use to develop applications for Windows Phone 7.

Be careful with Theme Resources for Windows Phone

As a developer you of course know that end users can select different themes on a Windows Phone 7. You most likely also know that you can access theme settings through Theme Resources from inside your Windows Phone 7 application. However, what you should realize is that the Theme Resources are used throughout your entire application, and that you can change the appearance of theme aware controls by modifying the Theme Resources inside your application. This is something I recently found out while working on a little application that utilizes the PhoneAccentBrush. My first attempt to use a copy of the PhoneAccentBrush looked like this:

normalBrush = (SolidColorBrush)Application.Current.Resources["PhoneAccentBrush"];
normalBrush.Opacity = 0.3;

After executing this code somewhere in my application, it turned out that some of the controls inside my application looked wrong, for instance the currently selected item in a ListPicker and the checked ToggleSwitch:

Instead of the selected item showing up in green, which was my selected theme color, the selected item looked really pale. At the same time, the checked ToggleSwitch looked really dark. It took me a few seconds to realize what was going on here. Especially since the same screen showed up nicely some times and ‘wrong’ at other times. What really happened here was the following. Each time I executed the above shown code snippet before displaying the settings screen, the ListPicker showed up pale. However, displaying the settings screen without executing the code snippet made the ListPicker appear crisp and colorful. Of course my mistake was a real beginner’s mistake. I thought I created a copy of the PhoneAccentBrush, but that was not the case. Instead I just assigned a brush variable to the PhoneAccentBrush and I modified the PhoneAccentBrush through the brush variable, thus influencing all UI controls that make use of the PhoneAccentBrush inside my application. By doing the proper thing, creating a new brush, based on the PhoneAccentBrush, my problems were history. This is how I created a copy of the PhoneAccentBrush for local use inside my application:

SolidColorBrush b = (SolidColorBrush)Application.Current.Resources["PhoneAccentBrush"];
 
normalBrush = new SolidColorBrush(b.Color);
normalBrush.Opacity = 0.3;

Changing the Opacity on a copy of the PhoneAccentBrush did not influence the appearance of theme aware UI controls any longer. This is what the ListPicker looked like after solving my problem:

In this way I could create a User Interface for a little application that is theme aware, but modified the accent color slightly for exclusive use inside my own application. This is an example of a very simple problem that can take you some time to solve. The solution for this problem was easy, but understanding what you are really doing can prevent mistakes like this one. Each time I run into one of these issues I will definitely blog about them.

Configuration dependent references

When you are developing Windows Phone 7 applications, especially if you are using additional assemblies that you developed yourself, it might not be sufficient to just add a reference to those particular assemblies from inside Visual Studio 2010. For instance, take this scenario that is taken from a real Windows Phone application:

This application makes use of an assembly that contains lots of re-usable functionality around MVVM support, IsolatedStorage support for tombstoning purposes and a few goodies to test an application’s Trial mode support. The latter item is the one I want to talk about in more detail in this article.

On a side note: even though I partly re-invented the wheel, there is a very nice MVVM implementation available with great Windows Phone 7 support. Take a look at Galasoft’s MVVM Light, a great resource for developing ‘serious’ Windows Phone 7 applications.

If you are developing Windows Phone 7 applications, you are most likely aware of the fact that the IsTrial method of the LicenseInformation class always returns false when running your application locally from a development machine. In order to test your application’s behavior in trial mode, you probably end up with something like this:

using Microsoft.Phone.Marketplace;
 
namespace DotNETForDevices.Tools.Controls
{
    public class RunningMode
    {
        public static bool CheckIsTrial()
        {
#if DEBUG_TRIAL
            return true;
#else
            return new LicenseInformation().IsTrial();
#endif
        }
    }
}

By defining a conditional compilation symbol ‘DEBUG_TRIAL’, it is now possible to test the application as if it is running in trial mode. However, if you are lazy like me, you probably get tired of manually setting conditional compilation symbols. I am also afraid to forget undefining symbols like this one when I submit applications for verification, especially since the above code snippet lives in a separate assembly. For me, it would be very helpful if I could create an additional configuration, that would allow me to build my entire solution for trial mode testing. Creating a new build configuration is very easy inside Visual Studio.

Inside this new configuration I can define my DEBUG_TRIAL conditional compilation symbol as well as additional symbols. Because I derived my new configuration from the existing Debug configuration, all other settings in my new configuration are copied from the existing Debug configuration. This is exactly what I want. Unfortunately though, even though I can define additional settings, at first sight it seems that Visual Studio 2010 does not help me to refer to other versions of assemblies that I add to my solution. In other words, I would really like to refer to a DebugTrial build of my additional DotNETForDevices.Tools.Controls assembly when I am building my application in the DebugTrial configuration. Of course I want Visual Studio to update to the Release configuration of all my own assemblies as well when I decide to build my solution in Release mode. If you take a look at the path to my referred assembly when I switch from Debug mode to DebugTrial or to Release mode, you will see that the referred assembly is still the original Debug assembly.

At first glance it seems that there is no way to be able to import my own assemblies with the same build configuration that I am using during the current build of my solution. There is a way to overcome this situation. As you might now, Visual Studio 2010 project files are XML based files, so it is possible to view them with a text editor and it is even possible to modify them. Of course you have to be very careful with modifying project files because it might lead to Visual Studio not being able to open your project any longer. If you want to modify your project files, make sure to always make a back-up of the original file.

<ItemGroup>
  <Reference Include="DotNETForDevices.Tools.Controls">
    <HintPath>..\..\..\DotNETForDevices\Controls\Bin\Debug\DotNETForDevices.Tools.Controls.dll</HintPath>
  </Reference>
  <Reference Include="DotNETForDevices.Tools.Persistence">
    <HintPath>..\..\..\DotNETForDevices\Persistence\Bin\Debug\DotNETForDevices.Tools.Persistence.dll</HintPath>
  </Reference>
  <Reference Include="Microsoft.Phone" />
  <Reference Include="Microsoft.Phone.Interop" />
  <Reference Include="System.Windows" />
  <Reference Include="system" />
  <Reference Include="System.Core" />
  <Reference Include="System.Net" />
  <Reference Include="System.Xml" />
</ItemGroup>

Looking inside my Clicker.csproj file, it becomes clear that the paths to referred assemblies are defined in a configuration independent way. This is fine for all system assemblies, but less ideal for my own assemblies, especially since they might still be under development as well. If you take a further look inside the *.csproj file, you will see that there are configuration dependent definitions.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>Bin\Debug</OutputPath>
  <DefineConstants>DEBUG;TRACE;SILVERLIGHT;WINDOWS_PHONE</DefineConstants>
  <NoStdLib>true</NoStdLib>
  <NoConfig>true</NoConfig>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>Bin\Release</OutputPath>
  <DefineConstants>TRACE;SILVERLIGHT;WINDOWS_PHONE</DefineConstants>
  <NoStdLib>true</NoStdLib>
  <NoConfig>true</NoConfig>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
</PropertyGroup>

It seems that conditions can be defined very easy inside project files. If I could do something similar for paths to assemblies that I have added as references, I could add assemblies with the same build configuration as my current solution has. This guarantees me building against the right configuration of my own additional assemblies. So this is the final solution I came up with, indeed modifying the project file manually:

<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <Reference Include="DotNETForDevices.Tools.Persistence">
    <HintPath>..\..\DotNETForDevices\Persistence\Bin\Debug\DotNETForDevices.Tools.Persistence.dll</HintPath>
  </Reference>
  <Reference Include="DotNETForDevices.Tools.Controls">
    <HintPath>..\..\..\DotNETForDevices\Controls\Bin\Debug\DotNETForDevices.Tools.Controls.dll</HintPath>
  </Reference>
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <Reference Include="DotNETForDevices.Tools.Controls">
    <HintPath>..\..\DotNETForDevices\Controls\Bin\Release\DotNETForDevices.Tools.Controls.dll</HintPath>
  </Reference>
  <Reference Include="DotNETForDevices.Tools.Persistence">
    <HintPath>..\..\DotNETForDevices\Persistence\Bin\Release\DotNETForDevices.Tools.Persistence.dll</HintPath>
  </Reference>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)|$(Platform)' == 'DebugTrial|AnyCPU'">
  <Reference Include="DotNETForDevices.Tools.Controls">
    <HintPath>..\..\DotNETForDevices\Controls\Bin\DebugTrial\DotNETForDevices.Tools.Controls.dll</HintPath>
  </Reference>
  <Reference Include="DotNETForDevices.Tools.Persistence">
    <HintPath>..\..\DotNETForDevices\Persistence\Bin\DebugTrial\DotNETForDevices.Tools.Persistence.dll</HintPath>
  </Reference>
</ItemGroup>

Changing to another build configuration now also results in referring to assemblies that correspond with that particular build configuration.

One very important thing to keep in mind though is that you need to manually modify the project file each time you add references to additional assemblies that you own and that you want to be build configuration aware. Other than that, I have not seen any issues by extending project files for this particular purpose. However, things might of course change with future versions of Visual Studio.

Publishing my first Windows Phone 7 application

Over the last year I have spent a lot of time talking about Windows Phone 7 development, both at (international) conferences, for students and at companies. During these presentations I always used a significant part of my speaking time to show Visual Studio 2010 in action. Live coding is something I like to do, and definitely helps showing an audience how powerful the development tools for Windows Phone 7 application development are. One question I got frequently was to show the applications I already had published on the Windows Phone 7 Marketplace. Up until now I have not really been interested in publishing Windows Phone 7 applications, teaching folks how to develop these applications is just more fun for me. However, over the last couple of weeks I decided to create a simple application for publication on Marketplace. Even though simple, the application is making use of MVVM instead of making use of code behind files. Making use of MVVM helped testing the application and definitely increases maintainability. To my surprise, getting the application certified and published was a very simple process. It was just a matter of submitting my (obfuscated) XAP file, some artwork, screen shots and a description. A few more details needed to be filled out on the submission pages, like a category under which the application will be visible on Marketplace, the price for the application and support for Trial mode. All in all, submitting the application took less then 15 minutes. After some waiting time (which can vary between a couple of hours and a few working days), I got an email, indicating successful submission to Marketplace. This process is easy and fast. Funny enough, it also made me feel good to see my own application available on Marketplace. I really start getting excited about submitting Windows Phone 7 applications. Just wait and see. I am pretty sure I will get more applications out to Marketplace. Oh, just in case you are curious: You can find my first ever published Windows Phone 7 application by clicking on this link to Marketplace. Note: This link will work from a Windows Phone 7, or from a PC with Zune software installed.

A small design-time issue with Visual Studio 2010

During the development of my first Windows Phone 7 application that will appear soon on the MarketPlace, I ran into a small issue with Visual Studio 2010. For the game I am developing I am making use of a number of UserControl’s. They contain a lot of intelligence about how to be drawn, what action to be taken and a few more things. I am also making use of a number of application settings, wrapped inside a class and stored in IsolatedStorage. These settings can be modified using a Settings Screen, and after modification, the settings will immediately be stored to IsolatedStorage without user intervention. So far so good. Until I decided to make use of a number of these settings inside my UserControl. All of a sudden I got exceptions in the designer.

Interestingly enough, the exceptions occur due to IsolatedStorage issues when running constructor code of my UserControl’s. Looking at the code inside the constructor it was obvious that I wanted to access a few properties from my Settings class. Of course this class is not initialized in designer mode, meaning it tried to read the values from IsolatedStorage on my development machine. This caused the exceptions. At first I thought that this was a bad thing happening to me. However, it turns out that it is not bad at all that this particular error occurred. It started me thinking. It also made me realize that my ‘generic’ UserControl should not directly make use of application specific settings. After all, this would make my UserControl less generic. Instead, what I should have done is passing important settings to my UserControl from within my application. After all, the application knows when settings are available and where they are coming from, knowledge that the UserControl should not know anything about. A ‘perfect’ example of a situation where design time errors inside Visual Studio 2010 helped me to make my application better.

Windows Phone 7 and WebClient

Inspired by Rob Tiffany’s great series of articles around Windows Phone 7 Line of Business Application Development I started playing with a Windows Phone 7 Client / Azure Service combination. Since I really want to understand what is happening under the hood, my samples are usually extremely simple, yet explaining a lot about the used technology. Developing Windows Phone 7 applications however often makes me feel blind and curious. As an application developer, Windows Phone 7 appears much as a black box. Of course I know that I am running a managed application inside a Sandbox, but it would be able to sometimes take a look inside the box. Take the following scenario:

I have created a small WCF based Azure REST service. It has the following extremely simple functionality:

Store a single numeric value (BaseURI/setdata?number={value})
Retrieve the stored value (BaseURI/getdata)

I also created a Windows Phone 7 application that can used this service to store / retrieve a single number. Retrieving data from the service can be done using the following code snippet:

private void GetWithLocalWebClient(object param)
{
    WebClient wc = new WebClient();
 
    wc.BaseAddress = IsDevice ? azureServerBaseAddress : localServerBaseAddress;
    wc.DownloadStringCompleted += 
        new DownloadStringCompletedEventHandler(wc_DownloadStringCompleted);
    wc.DownloadStringAsync(new Uri("getdata", UriKind.Relative));
}
 
void wc_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
{
    WebClient wc = sender as WebClient;
    if (wc != null)
        wc.DownloadStringCompleted -= wc_DownloadStringCompleted;
    RawRESTServiceData = e.Result;
}

In this code snippet, each time the number is retrieved from the service, a new object of type WebClient is created that is used only once. The code to store a number in the cloud is very simple as well:

private void SetNumber(object param)
{
    webClient.UploadStringAsync(
        new Uri("setdata?number=" + Number, UriKind.Relative), string.Empty);
}

To store a number, I am using another instance of WebClient, with a base URL set. This same instance can also be used to retrieve the number from the service, so my application has the possibility to retrieve a single number from an Azure hosted web service in different ways.

While testing the application, I started by retrieving the number that is currently stored in my Azure service, followed by storing a new number in the cloud and again retrieving the number that is currently stored. As you can see in the following screen dump, the last retrieval came with an unexpected result (1 instead of 3). Where did my stored number go?

It turns out that the WebClient is caching data, and it appears it does so to the extreme. Even if I create a new WebClient, it still uses cached data which is a complete surprise to me. On one hand this seems like a good thing, because it will result in less calls being made to the cloud, thus saving valuable resources. At the same time, it seems like a bad thing. What if my cloud data is updated and I still want to retrieve it through a REST call? Especially when creating a new WebClient object I think it would be reasonable to assume that a ‘real’ call will be made to my Azure service.

To resolve this potential issue, there is an easy solution. Just decorate the REST call with a unique string. Of course I don’t want to do this always, since that means that I am always physically calling out to the service. By re-using the last decorated REST call until I want to force a refresh of my data, I kind of have the best of both worlds available.

private void GetCachedWithUri(object param)
{
    webClient.DownloadStringAsync(cachedUri);
}
 
private void GetUncached(object param)
{
    cachedUri = new Uri("getdata?ticks=" + Environment.TickCount, UriKind.Relative);
    webClient.DownloadStringAsync(cachedUri);
    HasSavedUri = true;
}

Retrieving the data from the service without caching gives the expected result. Be aware though that the original cached data is still stored, so retrieving cached afterwards again gives us the original (cached) value.

Be aware of this behavior inside your own applications. The following video explains the caching behavior of the WebClient class in more detail:

WebClient caching behavior on Windows Phone 7

This explanation ofthe WebClient caching behavior will hopefully help you creating better Windows Phone 7 applications and save you time trying to understand what is going on behind the scenes.

M	T	W	T	F	S	S
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

Windows Phone 7: Application Architecture

Windows Phone 7 and the Cloud: The Sky is The Limit

Fast starting and State Saving Windows Phone 7 Applications

PlayButton – A very simple derived and restyled Silverlight Button