Tag: Visual Studio 2010

EvenTiles from Start to Finish–Part 7

In the previous episode of this series about how to develop a Windows Phone application from scratch we used the Isolated Storage Explorer Tool to take a look at the contents of the ApplicationSettings, stored in IsolatedStorage on the device or emulator. This time we continue dealing with our application settings, because we are going to talk about Fast Application Switching and Tombstoning.

As you probably know, only one application can be running in the foreground on a Windows Phone. That application can use as much resources as it needs and should be as responsive as possible to give end users a great experience. Typically, users switch often between applications. They might not even think about different applications, because they are most likely very task oriented. To give end users the best experience, our applications share a responsibility with other applications and with the operating system.

If our application is currently running in the foreground, there are two important reasons for our application to stop running in the foreground:

The user terminates our application by pressing the Back Key on the phone until the entire back stack of pages for our application is empty.
Our application is interrupted because some sort of an event occurred.

The first situation is simple. When our application is terminating, it is our responsibility to store information that we want to persist until the next time our application is running. This is what we did for EvenTiles in part 5 of the series, using the Application_Launching and Application_Closing methods that are defined in the App.xaml.cs file.

NOTE: The description of Fast Application Switching and Tombstoning in this article is valid for Windows Phone Mango, not for previous versions of the operating system.

The following picture shows our application running over time. The user navigated to the SettingsPage on EvenTiles, modified the string value and decided to use the Start Key on the phone to start another application. After a while, the user returns to our application by pressing the Back Key until our SettingsPage is visible again.

For the user, this experience is great, because when they come back to our application, it shows up exactly as it was when they moved our application to the background. The operating system simply keeps our application in memory. There are some restrictions with regards to applications using certain resources like the camera. To keep our story lean and mean we will omit those. When the user starts many applications (thus putting more and more applications in the background), at some time the amount of available memory gets so low that another application can no longer be started. In this situation, the operating system decides to remove the oldest application in the background from memory, saving just minimal state information for that application. In this situation, the application that was just removed from memory is said to be Tombstoned. To restore our application from being tombstoned, we not only need to reload our application settings (as we did on the Application_Launching event), but most likely we also need to restore additional data. The Operating System ‘remembers’ the page in our application the user had visible when we were tombstoned. It is our responsibility to restore data that the user entered on that page (for instance the contents of a Textbox).

When our application is send to the background, several things happen. On the page that is currently visible, an OnNavigatedFrom event will occur. Also, the Application_Deactivated method in the App.xaml.cs file will be called. When an application is switched to the background, basically three things can happen to it:

The application will become the foreground application again without having entered the tombstone state. In this situation the application can benefit from Fast Application Switching.
The application got tombstoned, but it will become the foreground application after a while. In this situation the application must restore more state information.
The user starts the application again by clicking its icon or tile on the start screen. In this situation, the previous instance of the application is removed and the user should see the application in its initial state.

When you are debugging your application in Visual Studio, the default behavior when the application is moved to the background is for it to remain in memory. However, by modifying one of the project properties (as shown in the screen dump on the left), you can force the application to become tombstoned, regardless from the amount of free memory on the device (emulator). In this way, we as developers have the possibility to test our applications in either state they enter when being moved to the background. You should make sure that you test the tombstone scenario for your application. For instance, if EvenTiles with its current functionality is tested for tombstoning it will crash. This currently has to do with the way that data is initialized. In EvenTiles, we have a string property defined in App.xaml.cs that will later be used to write information to the back side of our Secondary Tile. The SettingsPage already makes use of this property. However, we are initializing this property, named ActualBackSecContent when the application is started in the Application_Launching method.

Activating and Terminating

// 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)
{
    if (!appSettings.Contains(keyActSecBackContent))
    {
        appSettings[keyActSecBackContent] = DefaultSecBackContent;
    }
    ActualSecBackContent = (string)appSettings[keyActSecBackContent];
}
 
// 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)
{
}
 
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
}
 
// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
    appSettings[keyActSecBackContent] = ActualSecBackContent;
}

Even though our application is removed from memory when it is tombstoned, if the user navigates through the back stack using the back key on the phone, eventually they will return back to a page of our application. In order to make this happen in case our application was tombstoned, it has to be reloaded again to memory to become active. In this situation, minimal state information was stored by the operating system (for instance which page was the last page the user saw when our application got tombstoned). On returning from tombstoning we will return to that page, but since the application needs to be started completely, classes have to be newly created and code in constructors of those classes will therefor be executed. To distinguish between starting a fresh copy of the application or returning from the background, Application_Launching (fresh restart) or Application_Activated (tombstoning or fast application switching) is called in our App.xaml.cs file. If our application was still in memory, there is no problem, after all, the property ActualSecBackContent still holds its value. If we are returning from a tombstoning situation we do have a problem, since Application_Activated will be called instead of Application_Launching. That is why the exception that is shown in the screen dump above was thrown.

You might think that this problem could easily be solved by initializing the ActualSecBackContent property in the constructor of our App class, but that would mean that we don’t benefit from fast application switching (the situation where our application remains in memory, even though it is in the background). A better solution is to make use of the Application_Activated event as follows:

Switching between BG and FG

// 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)
{
    if (!e.IsApplicationInstancePreserved)
    {
        // The application was not preserved in memory, so we were tombstoned
        // Only in this case we need to re-initialize ActualSecBackContent
        ActualSecBackContent = (string)appSettings[keyActSecBackContent];
    }
}
 
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
    appSettings[keyActSecBackContent] = ActualSecBackContent;
}

If the application is becoming the foreground application, we check if we were still available in memory. If so (e.IsApplicationInstancePreserved == true) we don’t do anything, otherwise we just initialize the ActualSecBackContent property. There is nothing else to do, because we know that a value with that particular Settings key already is available, since the application was launched at some time before Application_Activated was called. If an application is moved to the background you want to make sure to save everything in such a way that you assume that your application will never return to the background. After all, the application can stay in memory, it might be tombstoned but there is also a possibility that the user starts a brand new instance of the application from the start menu. In the latter case, the existing instance of the application in the background will be removed by the operating system.

NOTE: If you are upgrading an existing application for Mango, at the very least (after converting your project in Visual Studio) you need to only retrieve stored data in the Application_Activated method when e.IsApplicationInstancePreserved is false. In that way your application will immediately benefit from fast application switching.

The following video shows the actions we took to prevent the EvenTiles application from crashing after being reactivated from a tombstoned state:

Fast Application Switching and Tombstoning (1)

With the changes that were described so far added to our application, it no longer crashes if we are returning from a tombstone state. There are however more things that need to be considered when the application is brought back from background to foreground. In the next Episode of EvenTiles we will take a look at restoring Focus on an input control when returning from the background.

If you want to see EvenTiles already in action on your Windows Phone, you can install the latest release from Marketplace. Remember that this application is not meant to be extremely useful, although it contains similar functionality that “serious” applications have. All functionality that you can find in the released version of EvenTiles will be covered in the upcoming episodes of this blog series, together with all source code. Just go ahead and get your free copy of EvenTiles from Marketplace at this location: http://www.windowsphone.com/en-US/search?q=EvenTiles (or search on your phone for EvenTiles in the Marketplace application).

EvenTiles from Start to Finish–Part 5

In episode number four of this series about how to develop a Windows Phone application from scratch we created the SettingsPage using a combination of Expression Blend and Visual Studio 2010. The SettingsPage has limited functionality, but it can modify a string that will eventually be displayed on the backside of a Secondary Tile. In this episode we will take a look at how to store data in IsolatedStorage.

If you watched the video of episode 4 you have noticed that the string containing the text to be eventually displayed on the Secondary Tile’s backside was not saved when the application was closed, because a default string showed up when the application was started again. In order to store the string so it will be available when the application starts again, we are going to store it into a specific part of the our IsolatedStorage. IsolatedStorage can be used to store files and system settings. It just acts as a hard drive with one little but important difference. IsolatedStorage is …. isolated. Everything that is stored in IsolatedStorage is exclusively available for the application that owns it, so other applications can not access it.

When a Windows Phone application starts, it will be running in the foreground, with its MainPage visible. As long as the user is working with the application, it remains n the foreground. An application can be terminated by the user by pressing the Back key on the phone until the last page of the application will be closed. An application can also be moved to the background. This happens when the user activates another application, or for instance when the user answers a phone call. On starting, a Launching event is raised. The App.xaml.cs file already has event handlers defined for the Launching and Closing events. These are the events that we are going to use to store / retrieve our string containing the backside text for our Secondary Tile.

NOTE: The sample code, retrieving and storing data in the Launching / Closing event works fine. However, all code executing upon firing those events has a time limit of 10 seconds. If an event handler takes longer to execute, the application will be immediately terminated. If you have much data to store / retrieve, you should take an alternative approach. You can for instance make use of a separate thread in those situations to retrieve / store information. To keep our sample lean and mean, we will directly retrieve / store data into IsolatedStorage from within the Launching / Closing event handlers.

Since all functionality is already available inside the SettingsPage to store the backside text of the Secondary Tile, we are only adding some functionality to the App.xaml.cs file. First thing to do is get access to the IsolatedStorageSettings for our application, which is in fact a dictionary in which values can be stored / retrieved through a key. The IsolatedStorageSettings are implemented as a singleton and are created the first time we try to access them. IsoloatedStorageSettings can be accessed from inside our entire application, although right now we will only use IsolatedStorageSettings inside the App.xaml.cs file.

IsolatedStorageSettings

public const string DefaultSecBackContent = "Having an even # of tiles on my StartScreen";
public const string keyActSecBackContent = "K_ASBC";
 
public static string ActualSecBackContent { get; set; }
 
private IsolatedStorageSettings appSettings = IsolatedStorageSettings.ApplicationSettings;

In the code snippet you can see a declaration of a key (just a string variable) that is used to store / retrieve the string containing content for the back side of a Secondary Tile. You can also see how a private variable is declared that is initialized with the one and only instance of our application’s settings in IsolatedStorage.

Application_Launching

// 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)
{
    if (!appSettings.Contains(keyActSecBackContent))
    {
        appSettings[keyActSecBackContent] = DefaultSecBackContent;
    }
    ActualSecBackContent = (string)appSettings[keyActSecBackContent];
}

Each time the application is started, the Application_Launching method will be executed. In this method we check if an object is stored under the key keyActSecBackContent. If this is not the case, we create a new entry in the dictionary of application settings and assign it with a default text that can be written to the back side of the Secondary Tile. If an entry already exists (which is basically always after creating one during the very first time), we retrieve the actual string from that entry. Since an application settings dictionary stores objects, we need to cast the actual value to a string.

When the application is terminated, the contents of the string that contains the text for the back side of the Secondary Tile might have been changed in the SettingsPage. That is the reason why we store that string always when the application ends.

Application_Closing

// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
    appSettings[keyActSecBackContent] = ActualSecBackContent;
}

It looks like we now have stored our application settings properly. However, that is not entirely the case, since our application might be temporarily interrupted because the user can start other applications without terminating our application. In those situations we have to take a look at the life cycle of an application. That will be topic of another episode of EvenTiles. It is also interesting to take a look at exactly what information is stored in IsolatedStorage. In order to do that, you can make use of the Isolated Storage Explorer Tool, a handy little tool that will be covered in episode six of EvenTiles.

In the following video you can see all the steps that you need to make application settings persistent and to retrieve them each time the application starts again.

Using IsolatedStorage to store ApplicationSettings

Note: Every now and then I will make sure that you can download all source code that we created so far. I strongly recommend you to do so and to start experimenting with that code. After all, looking at real code, modifying it and understanding your modifications will hopefully help you to become a great Windows Phone developer fast.

If you want to keep up with the code of EvenTiles that is available until now, you can download it as a Zip file from this location. After downloading and unzipping it, you can open the EvenTiles solution in Visual Studio 2010 Express for Windows Phone. You must have the Windows Phone SDK 7.1 installed on your development system to do so. If you have a developer unlocked phone you can deploy the application to your phone, if you don’t have a developer unlocked phone you can still experiment with this application inside the emulator.

Running for the first time

This time I cannot be objective, because today I created an Android application for the very first time and I created a Windows Phone application (definitely not for the first time). So what I am really doing is comparing my first Android experience with my first Windows Phone experience, way over a year ago already. At that time, even with the beta tools installation was a simple one click operation, after which I could create a typical hello world application and immediately execute it on the emulator. The whole process took less than 30 minutes. Even though Silverlight was new for me, I was of course familiar with Visual Studio, C# and the .NET (Compact) Framework.

Today I did something similar. I already described my experience installing the Android development tools. Now it is time to try my first application on Android. I have to admit that I have no experience at all with Java or with Eclipse, so my comparison is a bit unfair. That is also the reason to chose a very simple Hello World application to get going. Of course this is a good idea in general, since such a simple application can quickly be used to verify if the development environment is installed correctly and to see if things simply work.

Before I could get to work, I first needed to add an Android Platform in my Eclipse environment. This additional step is necessary because Eclipse is a versatile development environment and because there are different Android versions. The other thing that needs to be done is to actually create an Android Virtual Device, which is the emulator that can be used as target to run / test applications. Building an AVD takes some time, but is not really a bad thing. At least you know that you will have a target for a specific Android version.

Creating a new project differs slightly between Windows Phone and Android. The same is true for the functionality of the application. The two differ because they are using different development environments and programming languages, but they are of similar complexity.

My Windows Phone application looks like this, created in Visual Studio 2010 Express for Windows Phone:

Deliberately I created all functionality in code to better compare this application to the Android application. A corresponding Android application looks like this:

Compiling and deploying the Windows Phone application to the emulator was no problem at all. The emulator booted within 30 seconds after which the application was deployed and automatically started. It was a bit harder to get my Android application up an running in an emulator though. The first problem I ran into was a cryptic error I got when trying to deploy my Android application. The error was shown in the Eclipse console window:

It turns out that this error is caused by spaces in directory paths. I am not sure if this is an Eclipse issue or an Android SDK issue, but a solution to this problem was to create a logical link to the folder where the Android SDK was installed using a Command Prompt. This did the trick (of course after making sure inside Eclipse that the IDE now pointed to the newly created logical link).

MKLINK /J C:\Android "C:\Program Files (x86)\Android\android-sdk\"

Adding this link assured that the AVD did start. However, I still could not deploy the application to the virtual machine, this time because of another error:

It seems that this was simply a timeout error, because it takes quite some time to boot the AVD. Once it was entirely booted I tried running the application again and this time it was successful.

The scores for this exercise are clear. I needed to solve two (more or less cryptic) problems before I was able to run my application on the Android emulator. Deploying to the Windows Phone emulator caused no problems at all. Booting time for the Windows Phone emulator was around 30 seconds, the Android (3.2) emulator needed several minutes.

After installing the tools, my score was:

Windows Phone vs. Android: 1 – 0

After developing and creating a Hello World application, the scores are now:

Windows Phone vs. Android: 4 – 1

The reason why Windows Phone is a clear winner for me is the fact that deploying to the emulator just works and that the emulator boots relatively fast. The point I gave to Android might in fact belong to Eclipse. I really love maximize icon in the edit window, great for demos and something that I would not mind having in Visual Studio as well.

Over the upcoming weeks I will continue to compare Windows Phone with Android application development. So far there is a clear winner for me, but I want to really and honestly compare several aspects of developing applications on different platforms. Oh, just to be complete: My winner today is without any doubt

Windows Phone.

Ease of installation

Of course I am a bit biased, even though I am trying to be objective, independent and open minded. Over the last hour or so I have been busy setting up an Android development environment. If you are wondering why, it is not just out of curiosity, I am also preparing for a training I am taking next week. Over time it is going to be cool to find and understand differences between developing for Windows Phone and for other mobile platforms. I am planning to share my experiences in one way or another.

When I started developing Windows Phone applications, I just went to the App Hub, clicked on the link to download the free tools, and waited for Visual Studio 2010 Express for Windows Phone and Expression Blend 4 for Windows Phone to download and install. The development / design environment comes with a great emulator and within 30 minutes I was up and running (yes, I was using a slow Internet connection).

Today the story was slightly different. In order to start developing my first Android application, I had to download and install a Java SDK for which I went to Oracle. The next step was to download and install the Eclipse IDE for Java EE. Everything so far installed without any problem, but there is more to install. The next thing to install is the Android SDK, which has a nice Windows Installer. But wait …. what is installed is the SDK Starter Package, with which you can download the SDK’s you need for your particular target. It looks like the SDK Starter Package is a specific download manager for multiple Android SDK’s. The challenge now is to find out which SDK I need. I decided to just install the latest version, being SDK Android Plaform 3.2, API 13, revision 1. Hopefully this is the right SDK to get started. Finally, the ADT plugin for Eclipse is needed. Installing the plugin is done from inside Eclipse. In order to get the plugin, you have to run through 8 different, but easy steps. Once Eclipse is restarted, it now should be possible to develop my first Android application. Now, instead of 30 minutes to install a development environment, it took me over 2 hours. However, remember, this is the very first time that I am going to work with Eclipse, a Java SDK and Android. I can imagine that experienced Android developers install the tools way faster than I did. However, so far my conclusion for the day:

Windows Phone vs. Android: 1 – 0.

Where did my ads go?

Since a few weeks, Windows Phone developers can retrieve data on crash counts and stack traces for each published application through the App Hub. Because two of my applications indeed showed a few crash counts, it was of course time to fix the issues and to update the applications. One of those applications, ClickerLite, uses the AdControl to display advertisements inside the application. Besides fixing bugs, I also built the application against the latest version of the Windows Phone SDK. Instead of having to download and use a separate assembly to enable (Microsoft Advertising pubCenter) ads, the Microsoft Advertising SDK for Windows Phone is now part of the Windows Phone SDK. Of course this makes it easier to use the AdControl with full designer support in both Visual Studio 2010 and in Expression Blend 4.0. However, when I started to test my application, the AdControl was not visible, even though I did set the control up to receive test ads.

As often, the solution to the problem was easy, although it took me some time to find it. I simply needed to add the ID_CAP_MEDIALIB capability to my application’s manifest file. In the previous version of the Advertising SDK, this capability was not required and therefore not included in the manifest file. The end result was test advertisements showing up in the Visual Studio 2010 designer. However, when running the application (both in the emulator and on a real device), the test advertisements did not show up. This of course was also a clear indication that real advertisements would not show up in a released version of the application.

Adding ID_CAP_MEDIALIB solved the problem, the test ad showed up during testing, and the application was ready to be updated.

On a side note, if you are curious about ClickerLite, 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.

A new Windows Phone 7 Device (Emulator)?

Just a few hours ago, the Windows Phone Developer Tools Update was released by Microsoft. This update is specifically for Windows Phone application developers to allow them to build apps that are ready for the upcoming Windows Phone OS update. After installation of the tools update, you can test copy and paste functionality on the (also updated) emulator.

In order to start working with the updated tools, you will need to download the Windows Phone Developer Tool update and a separate Visual Studio 2010 update. Also make sure to read the Release Notes for the update. The order of installation for the separate tools is not important but you have to install them both. A little more background information about the latest WPDT update can be found on the Windows Phone Developer Blog.

It is expected that all existing apps that are already published in Marketplace will continue to work, both on phones that will be updated to the new version of the OS that will be available later, but also on phones that are not updated. To show the new copy and paste feature of Windows Phone 7 in action I have created a small application that takes a URL and allows that URL to be copied in Internet Explorer on the Windows Phone Emulator. To see this little application in action, just take a look at this video.

Windows Phone 7 Copy and Paste with the WPDT January Update.

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.

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.

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.

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