Month: January 2011

The Why and How’s of Windows Phone 7

If you want to learn a lot about mobile computing and if you can be in Barcelona, Spain on February 16, 2011, here is a unique opportunity for you. During the Mobile World Congress, you have the possibility to attend Windows Phone Wednesday, a great guided tour around the Windows Phone 7 Platform, hosted by Microsoft for application developers.

In one single day you will learn a lot about developing applications for Windows Phone 7. All aspects of application development for the phone are covered, including building apps and games, marketplace monetization, tips and tricks for certification and an open panel discussion where you can get answers to your burning questions.

The day is packed with a very exciting list of sessions and speakers with the following highlights:

Time	Session Title	Speaker
09.30 – 10.00	State of the Union	Brandon Watson
10.00 – 10.30	Windows Phone 7 Platform Overview	Larry Lieberman
10.30 – 11.30	UX / Metro Design Review	Bryan Agnetta
11.45 – 12.45	Mobile Web Platform Futures	Joe Marini
13.45 – 14.45	Panel Discussion
15.00 – 16.00	Business of your App	Todd Biggs
16.00 – 17.00	Silverlight / XNA Overview	Rob Cameron

Make sure to sign up immediately, because seats are limited. To register, please send an email to creators@microsoft.com with the following details: First and last name, email address for the invite and company name. Your conference pass gets you into the ADC as well as into the Expo Hall at Mobile World Congress.

The Windows Phone 7 team is looking forward to seeing you in Barcelona.

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.

Splash Screens

If you start developing a new Windows Phone 7 application, you usually start by creating a new Visual Studio 2010 project. As part of the initial project, Visual Studio creates a default splash screen for you, consisting of a waiting clock.

A Windows Phone splash screen is simply a jpg file with a resolution of 800 * 480 pixels. This means that it is very simple to replace the default splash screen (which is conveniently stored in your Visual Studio project under the name SplashScreenImage.jpg). Just make sure you have a jpg file with the right resolution and also make sure that it is placed in the root of your Visual Studio project. The name must be SplashScreenImage.jpg and its Build Action must be set to Content in the Properties window. Leaving the original splash screen unchanged in your own application gives end users a somewhat boring experience. After all, a splash screen is used to give users the impression that your application starts fast, and it also occupies users while your application is loading. If all applications use the same default splash screen, it will not help giving users a fast starting impression about those applications. So it is important to provide your own splash screen. If an application does not spent much time initializing, the actual amount of time that a splash screen is displayed is very short. For one of my applications, I did create a reasonably nice splash screen, to find out that the splash screen often is displayed for less then a second. My initial thought was to delay application start to allow end users to admire my splash screen. Of course this is a very bad idea, something you should not even consider doing.

This splash screen is used in a little game that is available on Marketplace. Typically the game starts up in under a second, meaning the user hardly has time to see the splash screen. The good news is that it is at least not the default splash screen. I have to admit that I considered adding a delay in my application for users to see the splash screen. Of course, and end user might like it once to take a look at this splash screen, but after starting an application several times, the splash screen will become boring since it is just a static image.

On a side note, if you are curious about this game, you can find it 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.

Back to the story about splash screens though. If you are developing a Silverlight application for Windows Phone 7, take the following idea into consideration. By far the best experience you can give end users for fast starting applications, is to take a screen shot from your application’s main page. If your application starts with some animation, make sure to take the screen shot from the initial situation (before the animation starts running).

Also, leave the application title / page title out of the splash screen. What I did for my latest application was taking the following shot from the main screen. Once the application is initialized, the application and page title animate in from the top, nice and gently. This gives a very nice experience for end users, and you don’t have to worry that your splash screen is only visible for a very short time, after all, your splash screen partly is your main page.

To have some nice page transitions on your main page, you can make use of functionality that is available in the November release of the Silverlight for Windows Phone Toolkit. An in-depth explanation of how to use these page transitions can be found in this MSDN blog entry by Will Faught.

This is the code that I am using to bring in the application title and page title in an override version of the OnNavigatedTo method:

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
 
    if (Settings.Instance.ApplicationLaunching)
    {
        SlideTransition slideTransitionFadeIn = new SlideTransition { Mode = SlideTransitionMode.SlideDownFadeIn };
        ITransition transitionTitle = slideTransitionFadeIn.GetTransition(this.TitlePanel);
        transitionTitle.Completed += delegate { transitionTitle.Stop(); };
        transitionTitle.Begin();
        Settings.Instance.ApplicationLaunching = false;
    }
}

Only when my application is launching (a new instance of the application is started, or the application returns from being tombstoned), the animation will run. In all other situations ‘normal’ page transitions will be executed. I keep track of the application being launched in the app.xaml.cs source file like this:

// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
    Settings.Instance.IsTrialMode = RunningMode.CheckIsTrial();
    Settings.Instance.ApplicationLaunching = true;
}
 
// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
    Settings.Instance.IsTrialMode = RunningMode.CheckIsTrial();
    Settings.Instance.ApplicationLaunching = true;
}

As you can see, a little bit of code and an additional screen capture from of your application gives you a simple splash screen that is effective for fast loading applications, yet giving the end users a very nice starting experience of your application.

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.

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
31

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