To enable seamless navigation by limiting the phone to run one application at a time, Windows Phone activates and deactivates applications dynamically, exposing events to developers to respond to when the application state changes. By implementing handlers for these events, developers can save and restore application state as their application transitions between active and inactive states. This behavior creates an experience in which it seems to the user like the application continued to run in the background.

Mobile Crunch pre-reviews Windows Phone 7 →

Who the hell did Microsoft hire to make this keyboard? Because whatever they’re being paid, they deserve a raise.

Engagdet previews Windows Phone 7 →

Let’s just put this up front: the keyboard in Windows Phone 7 is really, really good. We’re talking nearly as good as the iPhone keyboard, and definitely better than the stock Android option. It’s one of the best and most accurate virtual keyboards we’ve used on any platform.

And:

Once you take a shot, something pretty cool happens: it advances to the left, almost as though you’re looking at an actual roll of film, and you can see a dimmed sliver of the shot you just took on the left side of your viewfinder. You can then swipe to the right to see shots you’ve taken in the past, starting with the most recent, and returning to viewfinder (camera mode, as it were) is as simple as swiping all the way to the left again. It’s a neat user experience that we suspect novice users will pick up on very quickly.

Also:

Though it’s not quite as full-featured as the latest renditions of Google Maps on Android have been, Microsoft’s Bing Maps implementation on Windows Phone 7 is pretty great — they’ve done a fantastic job of blending the experience of using a mapping app into their so-called Metro design language.

Windows Phone Application Life Cycle

The Windows Phone execution model introduced in the beta release of the developer tools defines how a Windows Phone application is expected to behave during its life cycle. This model exposes four events in the PhoneApplicationService class that an application must listen to:

Launching is fired when the application is launching, for instance from the Start screen. It is not fired when the application activated.
Activated is fired when the application was in background and is brought to foreground, for instance when coming back from the web browser previously launched with WebBrowserTask.Show(). It is not fired when the application is launching, for instance from the Start screen.
Deactivated is fired when the application is sent to background, for instance when the Start key is pressed or when the web browser is launched with WebBrowserTask.Show(). It is not fired when the application is closing.
Closing is fired when the application is closing, for instance when the Back key is pressed while in the application’s main page. It is not fired when the application is deactivated.

Once it has been deactivated, an application is said to be “tombstoned”: it is not alive anymore and must have saved any transient data that it would like to restore in the event it is activated later on. Transient data include everything that is relevant only to the current instance of the application, such as a value entered in a TextBox or data returned by a web service query. It is different from persistent data which are relevant to all instances of the application and saved to isolated storage, such as account info and user settings.

It is the responsibility of the application to save its transient data using the PhoneApplicationService.State and PhoneApplicationPage.State properties when the Deactivated event is fired.* These properties reference Dictionary objects that will be restored by the framework if the same instance of the application is activated later on; they will be discarded if a new instance of the application is launched. Note that an application has ten seconds to handle the Deactivated event, after which it will be killed by the framework.

* More precisely, an application should save page-level transient data to the PhoneApplicationPage.State property when the page’s OnNavigatedFrom method is called. It should only have to save its instance-level transient data to PhoneApplicationService.State when the Deactivated event is fired. Check the Execution Model Best Practices topic on MSDN for a helpful list of do’s and don’ts related to tombstoning.

Peter Torr's quick tip for keyboard input on the WP7 emulator →

You can “deploy” and “hide” the hardware keyboard with the PageUp and PageDown keys [on the Windows Phone 7 emulator].

Windows Phone Developer Tools Beta →

The Beta release of the Windows Phone developer tools is now available. Check out the release notes and migrate your apps!

How to programmatically dismiss the virtual keyboard →

The Silverlight SDK blog on how to explicitly dismiss the virtual keyboard in your Windows Phone application: give focus to the root PhoneApplicationPage control and don’t forget to set the IsTabStop property of this control to true.

Engadget: Microsoft Kin is dead →

We’re learning this afternoon that Microsoft’s Kin line, for all practical purposes, is riding off into the sunset just a few short weeks after its release. Sources close to Microsoft tell us that Andy Lees has rolled Kin into the Windows Phone 7 team and has canceled the existing product’s launch later this year in Europe on news that sales weren’t as strong as expected.

I feel sad for the people who’ve been working on Pink/Kin. Let’s hope this means good news for Windows Phone 7.

Engadget has a followup story on what they think killed the Kin.

Update: Engadget has another follow up that fills in some blanks.

Why are the ApplicationBar objects not FrameworkElements? →

Because ApplicationBar is not a Silverlight element and because its “buttons plus menu items” approach is not supported by the Silverlight content models. I’ll try to remember that the next time I jump through the hoops needed to disable an app bar button in C#.

Fixing MethodAccessExceptions when deserializing an XML document

If a call to XmlSerializer.Deserialize() ends up throwing a MethodAccessException in your Windows Phone application, ensure that each object being deserialized follows the rules below:

The type of the object being deserialized has a public parameterless constructor.
The fields and properties of the deserialized type that represent XML elements all have public get and set accessors.

This applies to the type specified to the XmlSerializer constructor, and recursively to the type of each field and property of the deserialized type that represents an XML element.