Hopefully every Windows Phone 7 developer has heard about Tombstoning by now. To avoid writing the same code to persist and retrieve data again and again, there have been quite some efforts in the past to create generic methods of handling this process of application deactivation/termination by various people. James Ashley for example uses the ApplicationSettings and State classes for this (improved by rschiefer here). I personally like implementations that use the data contract serializer (here is an example by Joost van Schaik), because I can selectively choose what values should be serialized by applying the data member attribute only to those properties I want to be persisted.

Lately, I found myself confronted with an additional requirement more than once: I wanted to have my application persist some values only to the transient application state, but not permanently to isolated storage. The scenario for that is that an application might have temporary selections made by the user that should be preserved when the user moves away and returns to your application (e.g. when you're using launchers or choosers), but those values should not be restored when the user starts a new instance of your application. In fact, Microsoft's own recommendations for the user experience are (best practices document):

Ensure that when your application is launched by the user from Start or the installed applications list, the user is taken to a consistent, root experience. It should be evident to the user that they are experiencing a new application instance.

And:

When the user launches a new instance of your application, it is acceptable to present the user with some information about a previous instance, for example, a list of recently opened documents, but the user should not feel like they are continuing a previous session.

This means that you should decide carefully about what values should be only stored temporary when your application is deactivated ("session-dependent values"), and which ones you want to persist to isolated storage for the next launch.

Of course this can be done easily with some code, but being used to the attribute-driven approach of the data contract serializing, I decided to try something similar for the transient storage of temporary values. Here is the result. More...

After having worked with the Windows Phone 7 emulator for a while, I finally received my real device today (a shiny Samsung Omnia 7). I first played with it for an hour or so and then wanted to unlock it immediately to give it a spin in Visual Studio. As it turns out, this is easy, but not as obvious as it should be, and I found it hard to find appropriate help when I searched the web, so I decided to give a quick summary here.

As a developer, you can manage your already registered Windows Phone 7 devices on your dash board in the App Hub. But you cannot add new devices there. Instead, it says that

Adding additional devices must be accomplished through Visual Studio

So naturally, I fired up Visual Studio 2010 and looked for an option to do so. I didn't find one. More...

This is a post about a particular behavior of the built-in ASP.NET development server that can turn your debugging experience as a Silverlight developer into an unpleasant experience.

Prolog

It all started when I wanted to do some tests around bindings. I had created a small Silverlight project, and basically switched back and forth between the browser and Visual Studio to check what effects my code changes would produce.

Quickly I ran into a problem where a binding expression I was trying to use didn't work as intended. I spent some minutes double-checking that it was syntactically correct and then started to "google that with Bing" (thanks Scott, I'll never get this out of my head). After 20 minutes, when I had already started to doubt my mind, I finally realized that it was simply the browser that had not picked up the latest version of my Xap file. I had used hundreds of those small sample projects and never run into something similar. WTF? More...