Windows Phone Developer Blog

Using the Accelerometer on Windows Phone 7

Dave Edson — Wed, 08 Sep 2010 16:16:25 GMT

When Windows Phone 7 is released, users will be able to enjoy the fact that the hardware requirements for the phone include an accelerometer. Some applications are naturally inclined to work well with accelerometer input. Imagine a “Labyrinth” style game where you can now just rotate or tilt the device instead of simulating the tilting of the table using some buttons or sliders? Just rotating the device from portrait to landscape can re-flow the screen in the right orientation without the user selecting their preferred orientation.

In this blog post we will talk about the different ways you can use the accelerometer API in Windows Phone 7. We also include a class called AccelerometerHelper that uses the Microsoft supplied managed API and provides a variety of data for you to experiment with and find the right solution for your application. There are two major usages of the accelerometer:

Orientation relative to our planet Earth (assuming the device is being held steady)
Detecting movement of the device relative to the initial point (assuming you know the orientation).

The AccelerometerHelper class adds two high level functions for filtering of the data and calibration of the accelerometer.

Before we jump into the helper class, let’s take a look at the Windows Phone 7 managed accelerometer API. It’s pretty simple. There is a class called Accelerometer that is in the Microsoft.Devices.Sensors namespace. You create a new instance of the Accelerometer and then set up an event handler for the ReadingChanged event. Call the Start() method and you will start getting these events:

private void SetupAccelerometer()

{

_sensor = new Accelerometer();

_sensor.ReadingChanged += OnSensorReadingChanged;

_sensor.Start();

}

private void OnSensorReadingChanged(

object sender,

AccelerometerReadingEventArgs e

)

{

}

The AccelerometerReadingEventArgs contains the X, Y, and Z accelerometer readings from the sensor on the phone and a timestamp. The values are expressed in G-forces (1G = 9.81 m/s²), so a value of 1.0 means that the corresponding axis is being pulled with the same force as the gravity in Paris (the oh-so obvious center of the gravitational universe, hi Greg!). For example, if Z is -1.0, then the device is lying flat, face up, on a perfectly flat surface. If Z is 1.0, then the device is lying flat, faced down. Here is a diagram showing all the corresponding values:

There is something very important to note, however. Getting a value of 1.0 is not going to happen all the time. Earth’s gravity doesn’t roll that way. You may be at the Mystery Spot, you may be on top of a very tall mountain, or your hand may be trembling enough that there are some extra forces on the device. The accelerometer has some error tolerance, so you will want to experiment around with the cumulative margin of errors for the max/min values if your application needs to know these sorts of things. The AccelerometerHelper does not provide this functionality.

Now keep in mind that you will get those events often. Fifty times per second, to be exact. That means you are going to be getting a lot of data. The data you get will be noisy because of the nature of the accelerometer sensor on the device. Even with the device sitting on a table, minding its own business, the numbers coming in will have some variance. Additionally, there will be some calibration problems due to the nature of manufacturing tolerances (and users possibly dropping their phones a few times). Some devices will also come with edges that are not exactly flat. This means setting the device on a table may not result in a “level” reading. For applications using orientation, they need to really know that when the X and Y values are 0, the device is “leveled” (if “leveled” means the device is lying flat. If “leveled” means on edge then Z is 0, and either X or Y is 0). A level application is a perfect example of this.

With this short preamble, let us now look at the AccelerometerHelper class. It provides methods to calibrate the accelerometer and smooth the noisy 50 Hz data stream that the underlying Accelerometer class is generating. The AccelerometerHelper class provides a ReadingChanged event, which uses AccelerometerHelperReadingEventArgs. I think the class speaks for itself. Here is the class’s signature:

/// <summary>

/// Accelerometer Helper Class, providing filtering and local calibration of accelerometer sensor data

/// </summary>

public sealed class AccelerometerHelper: IDisposable

{

/// <summary>

/// New raw and processed accelerometer data available event.

/// Fires every 20ms.

/// </summary>

public event EventHandler<AccelerometerHelperReadingEventArgs> ReadingChanged;

/// <summary>

/// Singleton instance of the Accelerometer Helper class

/// </summary>

public static AccelerometerHelper Instance { get; }

/// <summary>

/// True when the device is "stable" (no movement for about 0.5 sec)

/// </summary>

public bool DeviceStable { get; }

/// <summary>

/// Persistant data (calibration of accelerometer)

/// </summary>

public Simple3DVector ZeroAccelerationCalibrationOffset { get; }

/// <summary>

/// Accelerometer is not present on device

/// </summary>

public bool NoAccelerometer { get; }

/// <summary>

/// Accelerometer is active and reading value when true

/// </summary>

public bool Active { get; set; }

/// <summary>

/// Release sensor resource if not already done

/// </summary>

public void Dispose();

/// <summary>

/// Indicate that the calibration of the sensor would work along a particular set of axis

/// because the device is "stable enough" or not inclined beyond reasonable

/// </summary>

/// <param name="xAxis">check stability on X axis if true</param>

/// <param name="yAxis">check stability on X axis if true</param>

/// <returns>true if all of the axis checked were "stable enough" or not too inclined</returns>

public bool CanCalibrate(bool xAxis, bool yAxis);

/// <summary>

/// Calibrates the accelerometer on X and / or Y axis and save data to isolated storage.

/// </summary>

/// <param name="xAxis">calibrates X axis if true</param>

/// <param name="yAxis">calibrates Y axis if true</param>

/// <returns>true if succeeds</returns>

public bool Calibrate(bool xAxis, bool yAxis);

}

The AccelerometerHelperReadingEventArgs provide the current values (see the next section “A Look at Data Smoothing” for an explanation of these values):

/// <summary>

/// Arguments provided by the Accelerometer Helper data event

/// </summary>

public class AccelerometerHelperReadingEventArgs : EventArgs

{

/// <summary>

/// Raw, unfiltered accelerometer data (acceleration vector in all 3 dimensions) coming directly from sensor.

/// This is required for updating rapidly reacting UI.

/// </summary>

public Simple3DVector RawAcceleration { get; set; }

/// <summary>

/// Filtered accelerometer data using a combination of a low-pass and threshold triggered high-pass on each axis to

/// elimate the majority of the sensor low amplitude noise while trending very quickly to large offsets (not perfectly

/// smooth signal in that case), providing a very low latency. This is ideal for quickly reacting UI updates.

/// </summary>

public Simple3DVector OptimalyFilteredAcceleration { get; set; }

/// <summary>

/// Filtered accelerometer data using a 1 Hz first-order low-pass on each axis to elimate the main sensor noise

/// while providing a medium latency. This can be used for moderatly reacting UI updates requiring a very smooth signal.

/// </summary>

public Simple3DVector LowPassFilteredAcceleration { get; set; }

/// <summary>

/// Filtered and temporally averaged accelerometer data using an arithmetic mean of the last 25 "optimaly filtered"

/// samples (see above), so over 500ms at 50Hz on each axis, to virtually eliminate most sensor noise.

/// This provides a very stable reading but it has also a very high latency and cannot be used for rapidly reacting UI.

/// </summary>

public Simple3DVector AverageAcceleration { get; set; }

}

The Simple3DVector is just a nice class that puts X, Y, and Z into the same object, along with some handy math functions.

A Look at Data Smoothing

Remember that the data from the accelerometer come in fast and furious at 50 times per second. The important thing to understand is how you want your application to react to this data stream. How you want your application to react depends on your application scenario. Some applications will want to have a very “nimble” feel, where small changes in the accelerometer value have immediate results. Games come to mind here. Other applications will want to have a very “steady” feel, where minute changes are ignored unless they trend over time from Value A to Value B. Let’s look at two graphs of raw data that we recorded from a device. The first graph trends from a low number to a high number. The second graph rapidly switches from one range of numbers to another, and then back. In real life, the trending graph is from a device that the user slowly tilts in one direction, and the second graph is from a device where the user rapidly tilts the device and then quickly resets the device. For the sake of simplicity, we show only one axis in the graph. The reader can extrapolate to all 3 axes:

Note how choppy the raw values are. If you have an application that shows the value of the accelerometer as numbers, those numbers will appear to be jumping all over the place. Perhaps this is what you want (highly doubtful, since it’s so noisy). But if you want to add some fluidity to the numbers so they seem to move in a more sequential fashion, then you will need to do some math stuff called signal processing.

Let’s first look at using the running average of the past five samples. By averaging the past five readings, the value is much, much smoother. But you can see in the second graph that the change in reading is now detected much later due to the smoothing. Therefore any application that needs to respond quickly to the change (like a car racing game), the latency will make the game play difficult. For the first graph (which has trending data versus sudden changes), this looks pretty nice.

Averaging is one method to smooth out noisy signals. Another method is to use something called a “Low Pass Filter”. A simple low pass filter is described by the formula below:

O_n = O_n-1+ α(I_n – O_n-1)

O is the output (filtered value) and I is the input (raw value), and α is a “coefficient” with a value between 0 and 1. If the coefficient is 1, the output is exactly the same as the input. If the coefficient is 0, the output is always the initial number. Those are the boring cases, the more interesting cases are when the coefficient is somewhere in between. The lower the coefficient, the more smoothing goes on. This formula gives you a single number to twiddle to get the smoothing effect you want. Let’s now look at the two graphs again, filtered with the low pass filter using a coefficient of 0.5:

And now, let’s use a coefficient of 0.15:

As you can see, the resultant signals are pretty smooth, but there is still latency in the second graph. We need to find a way to smooth the data when it is bound to a range, but take the big changes immediately. We’ll call this the “Optimal” value. There are lots of ways to do this, but the AccelerometerHelper takes the simple approach of checking the delta against a threshold. If the delta between the average value and the raw value is beyond a threshold, then the raw value is used, otherwise the low pass filter value is used. Here are the two graphs using this “Optimal” algorithm:

Just in case you don’t have graph overload, here is a composite graph showing all the different algorithms at once:

If you would like to play around with the coefficients and thresholds, you can find an Excel spreadsheet in the downloadable for this blog post. It has a sample of actual data taken from a device, and you can play around with the coefficients to see the effect on the data.

Calibration

Just what does calibrating the accelerometer mean? As an application, you do not have the ability to write system settings, so any calibrations you make will be only applicable at your application level. The AccelerometerHelper class “calibrates” the accelerometer by actually calibrating itself. You, the user, are expected to lay the device flat on a surface, then press a button whose event handler calls the Calibrate method for the X and Y axis. Calibration on the Z axis is not relevant. The method signature looks like this:

/// <summary>

/// Calibrates the accelerometer on X and / or Y axis and save data to isolated storage.

/// </summary>

/// <param name="xAxis">calibrates X axis if true</param>

/// <param name="yAxis">calibrates Y axis if true</param>

/// <returns>true if succeeds</returns>

public bool Calibrate(bool xAxis, bool yAxis)

You notice that the return value indicates success or failure. That’s because the Calibrate method checks the CanCalibrate method first to see if calibration is possible. If the device is tilted such that the X or Y values are nowhere near 0, then CanCalibrate will return false. Also, if the device is moving around a lot, CanCalibrate will return false. Your application can call CanCalibrate is response to the ReadingChanged event and modify the UI of your application accordingly. For example, a Level application could enable/disable the calibrate button to correlate to the CanCalibrate value.

If the Calibrate method proceeds to actually “calibrate”, then the average X and/or Y values of the accelerometer are used to build a vector. That vector is the negative of the current values. When added together, you get a vector with 0, 0, 0 for the x, y, z values. So the raw values from the Accelerometer class are combined with the compensation vector and the resultant values are run through the filters above. In addition, the calibration vector is saved away in the built-in IsolatedStorageSettings.ApplicationSettings with key names of “AccelerometerCalibrationX” and “AccelerometerCalibrationY”. This is nice because the user will usually only need to calibrate once per app and be done.

Orientation

In addition to the AccelerometerHelper class, there is also an OrientationHelper class we’ve written. It gives you information on all six of the device orientations for the 3 dimensions, as well as “Unknown” in case the device is not close enough to any of the orientations that a true orientation can be determined (or if the device is in motion, and the accelerometer values are rapidly changing). You get an event which tells you the new orientation and the previous orientation.

/// <summary>

/// Possible orientations for the device

/// </summary>

public enum DeviceOrientation

{

Unknown,

ScreenSideUp,

ScreenSideDown,

PortraitRightSideUp,

LandscapeRight,

LandscapeLeft,

PortraitUpSideDown

}

/// <summary>

/// Arguments provided on device orientation change events

/// </summary>

public class DeviceOrientationChangedEventArgs : EventArgs

{

/// <summary>

/// Current (new) orientation of the device

/// </summary>

public DeviceOrientation CurrentOrientation { get; set; }

/// <summary>

/// Previous (before this current update) orientation of the device

/// </summary>

public DeviceOrientation PreviousOrientation { get; set; }

}

Your app just gets itself a reference to the singleton object, and sets up the event handler, it literally cannot be any easier than this code. The Dispatcher.BeginInvoke bit is only required if you need the HandleOrientation method (which you implement) to run on the UI thread. That depends on your application design.

DeviceOrientationHelper.Instance.OrientationChanged +=

orientationHelper_OrientationChanged;

. . .

/// <summary>

/// Called on orientation change from orientation helper

/// </summary>

/// <param name="sender">Event sender</param>

/// <param name="e">Event arguments</param>

private void orientationHelper_OrientationChanged(object sender, DeviceOrientationChangedEventArgs e)

{

Dispatcher.BeginInvoke(() => HandleOrientation(e));

}

Dave Edson and Greg Hogdal (who wrote this post) are both software developers on the Windows Phone 7 Applications Platform team at Microsoft. We are working towards making your Windows Phone 7 development experience as easy and fun as possible!

A Developer’s Roadmap to Windows Phone 7 Launch Timing

Brandon Watson — Mon, 23 Aug 2010 16:25:00 GMT

August marks the six-month anniversary of the public unveiling of our next-generation mobile phone, Windows Phone 7. Six months is an interesting bit of time; it can fly by, or it can feel like it’s dragging on forever. The gating factor tends to be how much fun you are having. For us on the Windows Phone team, it feels like just yesterday that we first introduced Windows Phone 7 to the world. Now, just a blink of the eye and phones will be on shelves.

All of the work of the last six months is certainly paying off, as just about every conversation we have with developers focuses on their strategy for generating more business with Windows Phone 7. It’s amazing to see so many inspired developers looking to create experiences for Windows Phone 7. In fact, to date there have been north of 300,000 downloads of the Windows Phone Developer Tools.

These first six months have affirmed that a rich application platform based on the well understood Silverlight and XNA technologies, combined with great free tools based on Visual Studio 2010 and Expression Blend is the right approach for enabling developers and designers of all skill levels who are looking to capitalize on the opportunities presented by Windows Phone 7. Throughout the process, the developer community has continued to astound us with their creative ideas. Their use of the unique Windows Phone 7 features - like our design system, Live tiles, and location and notifications services - demonstrate that the experiences a developer can build on Windows Phone 7 match their imaginations.

While our developer community has been busy stretching the capabilities of the application platform and developer tools, we have been working very closely with some amazing application and game developers to ensure that Windows Phone 7 customers have the applications they expect, across a wide swath of the categories they value. Here’s a just small sample of the variety of companies with whom we have been working:

Adenclassifieds, Allociné (including sister brands: Screenrush, Filmstarts, Sensacine), APPA Mundi Ltd, Artificial Life, Inc., ebay, Inc., Esurance Insurance Services, Inc, Flixster, Intelligent Touch Solutions Ltd., Jobsite UK (Worldwide), Limited, Kelley Blue Book Co., Inc., Le Figaro group, My Interactive Limited, Open Table, Inc., Pageonce, Inc., Panoramic Software, Inc., photobucket inc., REALTOR.COM® Real Estate Search (Move, Inc.), Red Badger Consulting Limited, rising systems networks GmbH, Seesmic, Sequence Collective Ltd, TBS Field Mobility Solutions, The Associated Press, Touchnote, Trip Mate, Inc., Tx3 Solutions, vente-privée.com, Viadeo S.A

Of course, it’s not just the big names in development who are going to bring great titles to Windows Phone 7 customers. There are many multiples more of lesser known developers who are looking to be in the Windows Phone Marketplace. Large or small, all developers will have equal opportunity to capitalize on the first mover advantage of having their apps or games ready at launch. In order to do that, there are a few things developers will need to do:

Register at the marketplace today
Finish you application or game using the Beta tools
Download the final Windows Phone Developer Tools when they are released on September 16^th
Recompile your app or game using the final tools
Have your XAP ready for ingestion into the marketplace in early October when it opens

The final tools will likely have some minor breaking changes from the Beta tools, so developers may have to fix some bugs that arise. The final tools will also include several highly requested Silverlight controls which will make it even easier for developers to deliver high quality Windows Phone 7 experiences. Also in the September 16^th final release, the panorama, pivot and Bing maps controls will all be available to drop into applications.

The developer tools, controls and application platform are great, but we also recognize the need for smart training. Just last week we released a course called the Windows Phone 7 Jump Start, delivered by two of our MVPs, Andy Wigley and Rob Miles. It includes 12 hours of classroom training and supporting exercises. We have also recently updated the Windows Phone 7 Developer Training Kit. We will be releasing many more hours of training in the coming weeks and months. For the XNA developers, the XNA Creator Club announced today a new set of educational materials.

We’re also taking additional steps to make sure that the developer experience with Windows Phone Marketplace is even more friendly and intuitive. Ask any mobile developers about their biggest headaches and you are likely to hear about an opaque or non-existent app store ingestion process. We’ve shown how we are making the process of building apps and games easier for developers, but that is only part of the journey. The next step is getting apps and games in front of customers. The Windows Phone Marketplace continues our commitment to having a clear and open process for certifying apps and games. To reinforce that, today we have posted an updated set of Windows Phone Marketplace policies. Further, in the coming weeks we will be conducting a limited Beta test cycle of our app submission and certification process. We’re also working on significant changes to our developer portal that reflects feedback from the community. In those changes, you’ll see enhancements meant to simplify and streamline the path for developers to get the information they need.

So what does this all mean? We’ve demonstrated that you can build a phone that doesn’t just allow developers to build apps, but rather one that enhances apps with unique features like Live tiles and a design system not available anywhere else. We’ve shown that a phone isn’t there to just run apps, but rather to understand the full context of what customers are trying to do; integrating functions like maps and search and saving the state of apps so that customers can move between them without losing content or negatively impacting battery life. Lastly, we aren’t just building a marketplace to deliver apps and games, but rather testing and certifying every one for quality and performance - all the while maintaining a fully open and transparent process to support the developer and their Marketplace success. Our rich developer ecosystem is creating a variety of quality apps and games that take advantage of the phone’s unique features and design.

How will you spend the next couple of weeks? For the developers telling us how much fun they are having with our productive set of tools and APIs, launch day will be here before they know it. Developers now know when they will receive the final Windows Phone Developer Tools (September 16^th!) and when they should have their XAPs ready for Marketplace ingestion. 300,000 tools downloads means quite a bit of imagination is going to be pouring into the apps and games that customers see on Windows Phone 7 this holiday season. The clock is ticking. Will you be ready?

Windows Phone 7 Jump Start Training

Brandon Watson — Tue, 17 Aug 2010 22:54:00 GMT

Today we are publishing the first in our training content led by our MVPs. Rob Miles and Andy Wigley led an incredibly well received live training course about a month ago, focused on getting developers trained up on building amazing applications and games for Windows Phone 7.

We recognize that providing as much technical content as we can for the full range of developers is what developers deserve. While we plan on having more live training sessions in the coming weeks and months, we are also committed to making that content available as quickly as possible to as many developers as possible. Since this round of content is based on Beta Windows Phone Developer Tools, we will not be localizing it. For our non-English speaking developers, we will be providing localized training once we have released the final developer tools.

Andy and Rob provide a good bit of humor along with their incredible depth of knowledge on the topic of building apps and games for Windows Phone 7. We think they have covered a fair amount ground, but if there are topics you feel we need to cover more in depth, don't hesitate to let us know.

There are 12 sessions in total, each about :50 minutes in length. Think of this as a semester's worth of class time to help you in your quest to be an awesome Windows Phone 7 developer. It's self-paced, and both Rob and Andy are pretty approachable. Head on over to their blogs if you want to get more plugged into what they are doing.

Here are the sessions, and a link to their course material. UPDATED: Here's a link to the Zune subscription link. Also a link to the iTunes subscription.

Windows Phone 7 Jump Start (Session 1 of 12): Introduction

A quick tour of Windows Phone 7 and how you write programs for it. We take a look at the platform capabilities and the software development options. We also offer you a chance to win a prize that is almost certainly not a private jet.

Windows Phone 7 Jump Start (Session 2 of 12): Building a Silverlight Application, Part 1

Building an application from scratch. How you can take a simple idea for a program and build the user interface, followed by the program behaviors that sit behind it. We take a look at databinding on Windows Phone and how best to structure your application to make best use of it.

Windows Phone 7 Jump Start (Session 3 of 12): Building a Silverlight Application, Part 2

Making more complex applications. You also get an overview of how the built in controls work, and how to tailor the user input to match your requirements. We also take a look at page navigation within a multi-form Silverlight application on the phone and how to use the navigation inputs for best effect.

Windows Phone 7 Jump Start (Session 4 of 12): Building Games for the Windows Phone 7 Platform

Using Silverlight as a platform for game creation. We show how to get a draw/update behavior into your Silverlight games and give you a fully worked game to chew on. We also illustrate how a Silverlight game can leverage the XNA libraries to add sound effects to a game.

Windows Phone 7 Jump Start (Session 5 of 12): Building XNA Games for the Windows Phone 7 Platform, Part 1

Getting Started with XNA on Windows Phone. We talk about what makes the Windows Phone such a good platform for XNA development and how you create XNA games for it. We take a look at how games can manage the orientation of a phone and give you some tips on getting the best performance. Then we move on to take a look at the accelerometer input and how to make games that use this.

Windows Phone 7 Jump Start (Session 6 of 12): Building XNA Games for the Windows Phone 7 Platform, Part 2

Using the Windows Phone platform features in your XNA games. We continue with our look at Windows Phone features that make the platform so interesting to game developers. We cover the use of the touch screen, sound creation and finally give you some coverage of how to access the Zune media content in the device. Then we round off with a little look at how you can get text input from users by means of the Guide support in XNA.

Windows Phone 7 Jump Start (Session 7 of 12): Advanced Application Development, Part 1

Application Lifecycle. A look at the execution model on the phone, and how to create solutions that give a great user experience in the face of phone calls, termination and even total shutdown of the device itself. We show how to respond to messages to make your application give the appearance of being "always on" and the data persistence facilities that you will need to make this work.

Windows Phone 7 Jump Start (Session 8 of 12): Advanced Application Development, Part 2

Launchers and Choosers plus Using Isolated Storage. In this session we take a look at "Launchers and Choosers", how your application can use the built in phone behaviors to place calls, take pictures and select contacts, making it part of how the phone works. We also show how your application can store data in its own isolated storage on the phone device.

Windows Phone 7 Jump Start (Session 9 of 12): Advanced Application Development, Part 3

Storing Data and Using the Network. In this session we look at the connectedness of Windows Phone and how you can make this work for you. We demonstrate connected applications and how the notification service is used to allow external systems to give your application a wake-up call.

Windows Phone 7 Jump Start (Session 10 of 12): Marketing Your Windows Phone 7 Application

Using Windows Marketplace. In this session we explain how to join the Marketplace and get your applications out there. We take a look at how your solutions are packaged and deployed and how you go about registering a device for development and then using that with Visual Studio 2010 to test your applications.

Windows Phone 7 Jump Start (Session 11 of 12): Working with Media

Using XNA in 3D and with Media. In this session we take a quick look at how the Windows Phone works as an excellent platform for 3D games in XNA. We also explore how an XNA game can make use of the media stored in the phone, including photographs taken by the user and media loaded onto it from Zune.

Windows Phone 7 Jump Start (Session 12 of 12): Final Silverlight Topics and Wrap-Up

Taking Silverlight to the max. We start with a look at the Application bar, a crucial component in Windows Phone applications. We then move on to the Expression Blend tool, and how to create compelling user experiences with it. Finally we round off the session by showing how easy it is to use the map services in your phone and demonstrate some of the really cool navigation tools that are coming.

Here are the bios for our fearless session leaders.

Rob Miles

Rob Miles is a lecturer and Microsoft MVP based at Hull University in the UK. He teaches Programming, Software Engineering, Embedded Development and students. He has been working with XNA since before it was released and has been a big fan of Windows Phone 7 ever since he found out he could run his XNA and Silverlight programs on it. He writes a regular blog on programming and other forms of wit at www.robmiles.com and can be found on twitter with the unsurprising name of RobMiles.

Andy Wigley

Andy Wigley is a device application development MVP and co-founder of UK-based mobile consultancy firm, Appa Mundi. He is the co-author of a number of Microsoft Press books, including the Mobile Development Handbook and the .NET Compact Framework Core Reference and is a regular speaker at major conferences such as Tech Ed. He lives in the mountains of Snowdonia, North Wales where a strong mobile phone signal is a total luxury which has helped him to hone his skills developing offline mobile apps. You can read his blog, and those of his Appamundi colleagues at http://mobileworld.appamundi.com/blogs.

Xbox LIVE Games for Windows Phone 7 Unleashed at Gamescom

Michael Klucher — Tue, 17 Aug 2010 04:20:09 GMT

I've been lucky enough this week to find myself in Köln Germany at Gamescom 2010. It's also a pretty exciting day as we announced a number of Xbox LIVE games that will launch with Windows Phone 7 this holiday season. You'll find several familiar names in our first wave of titles from companies like Gameloft, Konami, Namco, Popcap and THQ. Microsoft Game Studios is also publishing several titles for Windows Phone 7 and partnering with many independent studios like Press Start to bring innovative indie content to Windows Phone 7. This is really cool to me, because it shows another step forward Microsoft is taking with the small and independent developer community.

One particular game that we announced that's interesting to me is CarneyVale: Showtime. It's because its story is intertwined with so many significant milestones through XNA Game Studios' history and really shows the growth from a great idea from a few folks to having a game available as a launch title for a platform. If you're unfamiliar with the game, CarneyVale: Showtime is an acrobatic puzzle game where players are asked to complete various circus stunts. CarneyVale was developed by Team GAMBIT, a small indie studio in Singapore backed by MIT (yep, that one!).

CarneyVale first showed up on my radar when it was submitted for an entry in our second annual Dream.Build.Play contest circa 2008. As a member of the judging team that year, I was simply blown away at how polished the game was and how fun it was to play. Using XNA Game Studio, Team GAMBIT was able to build the game in four months and the game ended up winning the Grand Prize and $40,000. CarneyVale went on to accumulate other accolades such as the PAX 10 award and being chosen as a finalist in the Independent Games Festival. The game was included as part of our launch of Xbox LIVE Community games (now called Xbox LIVE Indie Games), which allows indies to publish their games on Xbox LIVE. In March of this year Team GAMBIT announced that they plan to bring CarneyVale: Showtime to the PC thanks to a distribution contract with Games for Windows – LIVE. They are taking full advantage of the portability that XNA Game Studio provides.

For the Windows Phone 7 port of CarneyVale: Showtime, Team GAMBIT partnered with Microsoft Game Studios to integrate Xbox LIVE services available on the platform. In order for us to succeed, we want all types of content on Windows Phone 7, including games that are innovative and introduce concepts that are new to players. CarneyVale: Showtime is just that type of game.

Because the game was already written in XNA Game Studio, the developers were able to bring their game across the Xbox 360 platform to Windows Phone 7 quickly. Instead of spending a lot of time re-coding the game, they were able to really focus on the differences between the platforms such as user input and screen resolution, while having the core game experience easily translate.

CarneyVale: Showtime is just one example of a game that's built by indies who were able to utilize XNA Game Studio to bring their game to Xbox 360 and Windows Phone 7. Another great example of this is also included in our launch wave lineup; Rocket Riot from Codeglue, a game that's currently available on Xbox LIVE Arcade. We're looking to everyone, bigger studios, indie studios, or just a single person with a bright idea to create games for Windows Phone 7.

If there's one piece of information that can really get you started it's that all the titles used the same toolset that's available to you today at http://developers.windowsphone.com. If you're part of an indie group like Team GAMBIT, or a developer with a bright idea you can get everything you need from the site above. If you're just starting out with game development, we're here to help along the way at the same site you download the tools, or at our XNA Game Studio site at http://creators.xna.com.

I hope you get started today and will be looking forward to playing your next game on Windows Phone 7!

Windows Phone 7 Design Resources – UI Guide and Design Templates

chriskil — Tue, 27 Jul 2010 17:18:00 GMT

With the Windows Phone Developer Tools in Beta and Windows Phone 7 in Technical Preview, now is the time for you to build Windows Phone 7 apps in earnest. We have refreshed our developer documentation to help you build those apps, and we have two, new design-focused documents to help you make them look beautiful.

First up, the UI Design and Interaction Guide for Windows Phone 7 v2.0 has been updated from the ground up for beta. With additional information and a new layout we hope you will find more readable, this guide provides detailed information about UI elements and controls, UI system behaviors, and the interaction model for the touch interface based on the design system internally named Metro. Designers and developers should read this guide to learn about the dos and don’ts of UI implementations for their Windows Phone apps. We've made it easier to find specific guidance by putting it in bold in the right-hand column of each page.

Also available are the Design Templates for Windows Phone 7. These are a collection of 28 layered Photoshop template files and the Segoe WP font family that can be used to create pixel-perfect application layouts, to help guide UI development, or to pitch an idea. These design templates showcase many controls that are a part of the Windows Phone Developer Tools Beta. They also include examples of controls that are a part of Windows Phone, but are not available as a part of the Windows Phone Developer Tools.

Let us know what you think. If you have suggestions or feedback about these design resources, please email us at wp7des@microsoft.com and help spread the word – if you find these resources helpful, please tweet about them.

Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and more… – Part 3.

Yochay — Tue, 20 Jul 2010 22:44:08 GMT

In the first two Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and… Few More Things on the Way posts (part 1, and part 2) you learned about the different application lifecycle events – Launching, Deactivated, Closing, and Activated, and how they differ from one another. Based on that knowledge and this code, we’ll move forward.

Saving the transient state and navigating to the right page

As you will recall, the second page of our simple application includes two textboxes, one for allowing the user to enter a phone number that will be used to save new contact information, and a second textbox for allowing the user to enter an SMS message to be sent. This will become useful when we start playing with Launchers and Choosers in the context of tombstoning applications.

Let’s start by defining the problem. The easiest way is simply to run a small experiment:

From Visual Studio, start your application.
Navigate to the second page and enter some text in either or both textboxes.
Press the Windows button; this will deactivate your application (see part 2 of this series).
Press Back (once) to return to your application. This will result in a black screen on your emulator.
Press F5, or use any other method to restart the Visual Studio debugging session to reactivate your application. (Again, if you are missing some context, please read part 2 of this series)
At this stage, your application should be running and you should see the second page of the application. However, both textboxes are empty… the text that you entered before you deactivated your application is no longer there. It is gone!

From this little experiment you have learned that data entered into your application is not automatically saved when your application deactivates (remember, your application gets terminated). And since reactivating an application really means starting a new instance of the application with some tombstoned information, the page that you land on – in our case page 2, the DetailsPage, is a brand new instance of that page. This indicates that by default all the controls have no data, unless you load data into them.

The most important thing to remember about tombstoned applications is the simple fact that the user may NOT return to your application, and therefore your application may not be reactivated. If you anticipate this happening, you need to save to disk any data that you wish to restore at a later time. It is completely up to you and your responsibility as a developer to handle the saving and retrieving of data in your application

We identified two sets of data types that we want to store (copied from MSDN):

Persistent data - Data that is shared by all instances of an application. Persistent data is saved and loaded from isolated storage. Application settings are an example of persistent data that should be preserved between application executions.
Transient data –Data that describes the state of a single instance of an application. Transient data is stored in the State dictionary provided by the PhoneApplicationService class. A tombstoned application restores its transient state when it is activated.

We will address the persistent data and working with isolated storage in a future post. For now, let’s focus on managing the transient data and using the State dictionary.

One of the new classes in the SDK is PhoneApplicationService. The PhoneApplicationService class provides access to various conditions of the application’s lifetime. This includes management of the application’s idle behavior and management of the application’s state when it becomes active or inactive. This class plays a major role in the tombstoning game, since it exposes the Launching, Deactivate, Activated, and Closing events that have the corresponding methods (which you already saw) in the App.xaml.cs file. This class also includes a read-only State property of type IDictionary<string, object>. The importance of this dictionary is that it is persisted on your application’s behalf by the Windows Phone operating system when your application gets tombstoned. When the application reactivates, the objects that placed in the dictionary are returned. You don’t need to save these transient objects to disk as long as you expect your application to return from the tombstoned state. Therefore, if you intend to use the State dictionary, make sure you save only transient data in it– information that you don’t mind losing and that is local to the current application instance. In our example, we’ll save the phone number and SMS text message.

Please note that the objects you store in this dictionary have to be serializable, or else you will get an exception during the deactivating event about the inability of the operating system to sterilize or desterilize your object.

MSDN best practices recommend that you store transient page data in the State dictionary during the OnNavigatedFrom event, and load data during the NavigatedTo event.

I’ve update the application to save the phone number and the SMS message in the Store dictionary, and load it each time the page get navigated to. If a “completely” new instance (indicated by the “Lunching” event) of the application is started, the State dictionary is empty.

   1: protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)

   2: {

   3:   Util.Trace("***** in DetailsPage: OnNavigatedFrom ( " + DateTime.Now.Ticks + " *****)");

4:

   5:   //try to locate the phone number from previous save and simply override it

   6:   if (true == PhoneApplicationService.Current.State.ContainsKey(PhoneNumberKey))

   7:   {

   8:     //clear prev value

   9:     PhoneApplicationService.Current.State.Remove(PhoneNumberKey);

  10:   }

  11:   PhoneApplicationService.Current.State.Add(PhoneNumberKey, this.PhoneNumberTxt.Text);

12:

  13:   //try to locate the SMS Messagefrom previous save and simply override it

  14:   if (true == PhoneApplicationService.Current.State.ContainsKey(SmsMessageKey))

  15:   {

  16:     //clear prev value

  17:     PhoneApplicationService.Current.State.Remove(SmsMessageKey);

  18:   }

  19:   PhoneApplicationService.Current.State.Add(SmsMessageKey, this.MessageTxt.Text);

  20: }

21:

  22: // Step 2

  23: protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)

  24: {

  25:   Util.Trace("***** in DetailsPage: OnNavigatedFrom ( " + DateTime.Now.Ticks + " *****)");

26:

  27:   //try to locate the phone number from previous run

  28:   if (true == PhoneApplicationService.Current.State.ContainsKey(PhoneNumberKey))

  29:   {

  30:     string s = PhoneApplicationService.Current.State[PhoneNumberKey] as string;

  31:     if (!String.IsNullOrEmpty(s))

  32:     {

  33:       Util.Trace("***** in DetailsPage: OnNavigatedTo: Found phone number ( " +

  34:                                                     DateTime.Now.Ticks + " *****)");

35:

  36:       this.PhoneNumberTxt.Text = s;

  37:     }

  38:   }

39:

  40:   // Step 2

  41:   //try to locate the phone SMS MSG from previous run

  42:   if (true == PhoneApplicationService.Current.State.ContainsKey(SmsMessageKey))

  43:   {

  44:     Util.Trace("***** in DetailsPage: OnNavigatedTo: Found Sms Msg ( " + DateTime.Now.Ticks + " *****)");

45:

  46:     string s = PhoneApplicationService.Current.State[SmsMessageKey] as string;

  47:     if (!String.IsNullOrEmpty(s))

  48:     {

  49:       this.MessageTxt.Text = s;

  50:     }

  51:   }

  52: }

Note that with the following changes, the information in page 2 is stored between page navigation. That is when you press the Back button in page 2, the application navigates back to page 1. If you click the “Navigate to next page” from page 1, your application navigates to page 2. The OnNavigateTo (on page 2) event is raised, and with the above code the control will be loaded with data. This is important because if you take a closer look at the trace in the Output windows in Visual Studio you will find that the each time you navigate to page 2, its constructor is executed. This indicates that each time you press the Back button from page 2, that page is destroyed, and therefore each time you navigate back from page 1 to page 2, the page is recreated. To observe this behavior for yourself, simply navigate back and forth between the two pages, and note that the page 2 CTOR is called each time you navigate from page 1 to page 2. If you comment out the OnNavigatedFrom method in your application, and navigate between the two pages, you will see that the information on the second page is not saved.

Now tombstone the application to see for yourself that the phone number and SMS message are being stored, not just between page navigations, but also after leaving the application and returning to it. Simply navigate to page 2, enter a phone number and some text, and press the Windows button to tombstone the application. You should see the deactivated trace and then the application terminated. Press the Back button and don’t forget to press F5 in Visual Studio to restart the debugging session. Your application will return from its tombstoned state and you will see the launching event, and then the DetailsPage (page 2) constructor. Next you will see the OnNavigatedTo trace and, if everything works, you will see the "Found phone number" and "Found Sms Msg" lines in the trace (and in the emulator), as shown in the next image.

All this is nice, and I hope it explains the way things work with tombstoning Windows Phone applications. But, now it is time to step up our game and show some cool things in action.

First, I’ve added a helper Logger class that logs all the traces and displays them in the MainPage (first page) textbox. The goal of the Logger is to prove to you without a doubt that your application gets terminated and that the State dictionary really works. The logger will also allow you to run your application from the emulator, not in debug mode, and still get some information back through the traces shown in the log textbox.

Logger class

The Logger class includes a very simple (and most probably not that thread-safe) implementation of a Singleton. The main reason this class is a singleton is to show that even a singleton class is removed from memory when your application is terminated, as well as the order of events and the loading of data between the different events. This class has a string member, which is the log, and a DateTime member that saves the creation time of the Logger object. With the Logger class you can add new lines to the log, and get the entire log. This is good for debugging, which is exactly what the Logger is for. Each time you use the Util Class to add a trace, you also add it to the Logger.

Usually a singleton implementation doesn’t have a public constructor. However, you are going to save this class in the State dictionary, which means that the Logger class must be serializable and therefore must have a public default (empty) constructor. Otherwise you will get an exception when trying to deactivate or activate your application.

To “view” the log, I’ve added the OnNavigatedTo method to the MainPage.xaml.cl and loaded text in the log to the logTextBox control on the main page. Therefore each time you navigate to the main page of the application you will see the log file printed. Doing this enables you to view the trace in your application without the need to debug your application in VS (and thanks to Jaime Rodriguez for the tip). Let’s try it.

First you need to deploy you application to the emulator. You can do this by right clicking on your project in the Visual Studio Solution Explorer panel, or from the Build menu. Simply click Deploy.
In the emulator, navigate to the applications list by clicking on the white arrow on the top right corner of the phone.
You should see the applications list, which is rather short. From the applications list pick your application. If you are using the code from this post, the application name is LWP.AppLifeCycle
The application launches, and you see the trace in the MainPage textbox. You may want to change the phone setting (by clicking the wrench button) to set the zoom level of the emulator to 100%. The text in the log textbox is small to be able to show as much log history as possible without scrolling.
In the log textbox you should see the trace from creating the application and the constructor of the main page.
Click the Next Page button.
On the second page, enter a phone number or some text to the SMS textbox.
Then deactivate your application simply by clicking the Windows button. In the emulator, you should see the Start screen.
Click the Back button to return to your application. This will reactivate your application and restore your application to the last page you viewed, that is the second page, and, if all goes well, you should also see the information you entered in step 7.
On the second page, click the Back button to return to the first page. Take a look at the trace found in the log textbox. You should see something that looks the following image:

The interesting segment of this trace is the information between the dashed lines, and the following code snippet for which the Application Activated method is responsible.

   1: if (true == PhoneApplicationService.Current.State.ContainsKey(LoggerKey))

   2: {

   3:     Logger logger = (PhoneApplicationService.Current.State[LoggerKey] as Logger);

   4:     long timeDef = Logger.Instance.CreationTime.Ticks - logger.CreationTime.Ticks;

   5:     Util.Trace("-------------------------------------\n--> Time difference between Loggers = "

   6:                 + timeDef

   7:                 + "\n" + logger.GetLog()

   8:                 + "\n-------------------------------------");

   9:     }

In this code, you can see that we are looking for the Logger object in the State dictionary. The object was put into the State dictionary in the deactivated event. Assuming the logger object is found, we are creating a temporary object called logger (note this is not the actual logger object that we are using in the current application). Next we compare the creation time of the Logger from the State to the singleton Logger instance of the “new” application that we just activated. As you can see in the trace, there is a difference in time; the logger from the State dictionary that we saved when we last deactivated the application is older than the new logger. From the code you can see that we can’t really initiate the older logger; its creation time and log are restored and printed to the textbox. So everything between the dashed lines is actually the previous run of the application up to the deactivated event.

The first line after the dashed line is shows the constructor of the second page, as expected, and it shows the “new” application that got reactivated and returned to the second page, from which we had deactivated the application.

To summarize

Now you have seen all four events in action: Launching, Deactivated, Activated, and Closing. I hope you understand that when your application is not running, it is terminated, and any data you didn’t saved is gone. Then when you are return to the application, with either an Activated event or a Launching event, you get a NEW instance of the application (our little singleton experience proved that).

The State dictionary can save transient data between Deactivated and Activated events and will turn out to be a very useful tool in the next post where we’ll talk about choosers and launchers.

Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 2

Yochay — Fri, 16 Jul 2010 19:36:47 GMT

In the previous post, you learned about the basics of the Windows Phone execution model. You saw three out of four events. We covered Application Launching, Application Closing, and Application Deactivated. Now it is time to cover the last event, Application Activated. If you want to follow the code shown in this post , you can download the code for the code sample.

How to resume the debugging session of a tombstoned application – Handling the Activated Event?

Remember my promise about the Back button functionality? I'm finally going to come through. However, please read through all 7 of these steps and the following Note before actually trying this yourself.

From Visual Studio, start a new debugging session of the simple application we created in the last post.
Press the Next button to navigate to the application’s second page.
Press the Windows button.
The emulator returns to WP Start screen, and in the Visual Studio output window, you should see the following image:

As you can see, we started a new instance, and therefore the application launching event was raised. Next the application's first page was called (by default) and therefore you see the MainPage trace. When you pressed the Next button, your application navigated to the second page, as you can see from the DetailsPage trace. And finally, when you pressed the Windows key your application was deactivated, again as shown by the trace. The emulator shows the Start screen

Note: Do not close the emulator or make any code change, or else you will start a new instance of your “updated” application, and we don’t want that to happen.

In the WP emulator, you should see the Start screen, press the Back button (once).
At this point your emulator screen will go black as if it is waiting for something to happen. Guess what? It is. This is the designed behavior for the current Beta version tools. The screen goes black and the application does not restart as it waits for you to re-attach the debugger so you can continue debugging the application.
To re-attach the debugger and continue the debug session, switch to Visual Studio and press F5 (or use any other method to start your debugger). The debugger attaches to the correct instance, the emulator continues to activate the application, and the Activated event is raised, as you can see in the following image of the Output window of Visual Studio:

Note: There is a time limit for this process to be successful, as the emulator terminates the application if it takes longer than 10 seconds to reload. Therefore you need to be quick. Also, you should NOT place any breaking points in the Activated event, as Visual Studio will break at the right place, but if you spend too long debugging your code, the emulator thinks that there is something wrong with your application and will terminate it (even if Visual Studio debug session is still active). According to the guidance, your application UI should load within 10 seconds, and since the Activated event is handled before your main page constructor, no UI is shown if you debug and step into the Activated event.

Now that you know what to expect, go ahead and reactivate your application to bring it back to life from its tombstone state by following the steps described above. You will notice that Visual Studio starts a “new session” (because the first instance of the application was terminated). But this time the first trace line is Activated and not Launching, after the Activated event, the next line of debug output shows the DetailsPage CTOR and not the application default first page, MainPage. And if you look at the emulator you will see that your application returned to the correct page, which is the last page you viewed in your application (the second page) before pressing the Windows button.

So there you go, you just experienced firsthand how your application gets tombstoned and then is resurrected.

Note that when your application returns from its tombstone state, it is a new instance of your application, and even so, you will not see the launching event, and therefore you don’t see the Launching trace in the Output window. The Launching and Activated events are mutually exclusive. You should never see both events in the same run of your application’s instance.

A few important things to remember

Launching, Deactivated, Activated, and Closing events are all application level events. They will always get called (unless you remove them from the code – which you MUST NOT DO). If there is any generic workload that your application needs to handle, like loading data from disk or saving data to disk, these events are the right tools for that work (we’ll get to that later).

As you just saw, the application can return from its tombstone state to any one your application’s pages, and therefore you can’t guarantee that one page will load before the other.

The most important thing to remember about tombstoning is that the user may opt NOT to return to your application, and therefore your application may not be reactivated. The user could launch the application again from the Start page (instead of via the Back button), thereby invoking a new instance of the application – Launching event Vs. Activated. Or, the user could launch several other applications, knocking the tombstoned application off of the back of the application stack where it cannot be reached with the Back button. In such a cases, you need to save any data that you wish to restore at a later time. It is completely up to you and your responsibility as a developer to handle the saving and retrieving of data in your application. And that is the subject of our next post. But for now review the following diagram, from the Windows Phone documentation; it should help you understand the relationship between the different events.

By now, you should understand the meaning and functionality of Windows Phone application lifecycle events – Launching, Deactivated, Closing, and Activated. But that is only the beginning as there are additional topics to cover in order to fully understand the execution model and how make the most of it in your application. In the next post, you will learn how to save your page state into a temporary store and when and where in the application to save and load such data.

You can download the code for the sample shown in this blog.

Windows Phone 7 Training Kit for Developers includes a full lab dedicated to the Windows Phone Application Lifecycle.

MSDN documentation includes a topic - Execution Model Overview for Windows Phone

Blog edited by Barbara E. Alban

Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 1

Yochay — Thu, 15 Jul 2010 20:30:32 GMT

With such a long and promising title, this series of posts better be a good one – you’ll be the judge of it. However, the real reason for this long title is rather simple. All these “big” words simply represent different aspects of the execution model. There are a few things that you need to know if you want to maximize your user’s experience. This post explains the Windows Phone (WP) application execution model by taking you step-by-step through the different aspects of launching, running, and closing a Silverlight application. Note that for XNA games the terms and ideas remain the same with some minor implementation differences. In following posts we’ll cover deactivation, reactivation, and how launchers and choosers work with tombstoning.

With the latest Beta release of the Windows Phone developer tools, applications running on WP employ an updated execution model. Now, when your application is removed from the phone foreground (a different application occupies the phone foreground like incoming phone call, or the lock screen being activated), it is actually being terminated (more on this later). In earlier version of the WP tools, you could get into all kinds of strange scenarios if you went from one application to another. That is because in the previous version of the tools, the WP operating system didn’t terminate your application, it “parked” it. However that led to some issues regarding launching a new instance of your application vs. navigating back to the instance on the back stack. Adding to the confusion, the events and API were less than perfect. I guess that is one of the reasons we have technical previews—to test and fix such “issues.”

A Few Ground Rules

Just to make sure we are all on the same page, by now you probably already know that the WP operating system doesn’t allow any 3rd party applications to run in the background. To be more specific, there can be only one application running in the foreground at any given time, and if your application is not running in the foreground, it means that your application is NOT RUNNING. The main reasons for not allowing 3rd party applications to run in the background are to preserve battery life (see Push Notification post) and to ensure a responsive and consistent user experience.

All WP devices feature a hardware Back button. This button allows the user to navigate back in a given application and even between applications. This is a rather cool feature, mainly because unlike other phones, you can navigate from your application to the browser or to another application, and then press Back to seamlessly return to your application. This yields a much more consistent user experience across different applications, whether they are 3rd party applications or part of the phone's built-in application suite. This also implies that WP operating system is maintaining a journal of you navigation actions to support the Back button functionality. This is also known as the back-stack.

The Basics – Launching, Running, and Closing Applications

It is time to jump into the Windows Phone execution model, and the best way to do this is to start looking at some code. Simply start a new Windows Phone application and look at the auto-generated code of a new WP Silverlight application template, and you will find four new methods in the App.xaml.cs file that are directly related to the execution model:

Application_Launching
Application_Activated
Application_Deactivated
Application_Closing

As a side note, all these events (the functions are the event handlers) are members of the PhoneApplicationService class in the Microsoft.Phone.Shell namespace.

I think the names of these methods are rather self-explanatory, but just to be on the safe side, let’s review them. We’ll address the Activated and Deactivated methods later; for now, let’s focus on the simple events: Launching and Closing. I’ve added a single line of code to each method:

// Step 1 - Util is helper class for logging
Util.Trace("***** in MainPage CTOR\t\t ( " + DateTime.Now.Ticks + " *****)");

Util is a simple helper class that we’ll use to help us with debugging. The text in each method changes according to the event but you get the idea. I log the time of each event in order to prove a point later when we talk about Activated and Deactivated events.

Running the application in its current state yields the expected result. Upon launching your application the “Launching” method is called. As expected, after that event, your application runs. Press the Back button (not the Windows button) and your application terminates and the “Closing” event is raised, as you can see in the following image (copy of the output window from Visual Studio).

As we said, by pressing the hardware Back button, the navigation model allows the user to “step back,” or navigate backwards through the application pages, and even across applications. However once you reach to the application’s first page (the first page, and its first instance) pressing the Back button raises the Closing event and terminates your application. You can see that from the above image, where it clearly states that the “program” exited. If you are following this post while coding in Visual Studio you will also note that the emulator exits your application and returns to the Start window.

Understanding Activated and Deactivated Events and Tombstone

So far so good, I mean there is nothing new here. However, let’s try the following trick. From Visual Studio, start your application in debug mode (so we can see the traces). As expected, your application starts and you should see the Application Launching trace in the log. Now, instead of pressing the Back button (which if you do, will terminate your application), press the Windows button (the middle button).

You should notice the following:

The emulator returned to the Start screen and your application doesn’t occupy the phone’s foreground, which means it is no longer running!
The debugging session in Visual Studio was terminated. This means that Visual Studio is not debugging your application, which makes sense since the application is no longer running.

Note: At the end, your application gets terminated. That is super easy to see in the Visual Studio Output window, as the last line in the Output windows states, “The program '[220921918] taskhost.exe: Managed' has exited with code 0 (0x0).” No worries, this is by design. However, unlike our previous example, this time the event that followed the Launching event is “Deactivated,” and NOT Closing. But in both cases your application gets terminated (at the end). So what is going here? What is the difference between Closing and Deactivated and more important, why?

Application Closing is simply the outcome of the user pressing the hardware Back button enough times to navigate backwards through the pages of your application, past the application’s first page. Currently, this is the ONLY way for a user to exit your application. Once your application is closed, its process is terminated, and the operating system removes any trace of that application from its memory (RAM).
Application Deactivated occurs when a different application takes control of the foreground - for example, an incoming phone call, launching a chooser, or the user pressing the Windows button. In both cases, your application will be deactivated (not closed). Before we step into the subtleties of the Deactivated event, let’s make sure we all understand that upon Deactivation, your application gets terminated (at the end). It's that simple; your code can’t run in the background, therefore your application gets terminated. However, unlike an application that is closed, a deactivated application gets tombstoned. Don’t get confused, a tombstoned application’s process still gets terminated. But unlike a closed application, where the WP operating system removes any trace of the application, when an application is deactivated, the WP operating system stores a record (a tombstone) of the application's state. Basically, the WP operating system keeps a tombstone of the application that becomes part of the phone’s application back-stack, which is a journal that enables the use of the hardware Back button to enhance navigation functionality.

There are several ways in which applications can become tombstoned. An application will be tombstoned and deactivated if:

The user presses the Windows button (as you just did)
The device timeout causes the lock screen to be engaged (again, a different application takes control of the foreground)
The user invokes a Launcher or a Chooser – which we will cover later

In any of these cases, the running application will be deactivated, the Deactivated event is raised, and your application gets terminated shortly afterwards.

At this point in the application life cycle (while your application is tombstoned), a few things can happen. The user might return to a tombstoned application. This can happen if the user completes the chooser or launcher activity and returns to the application, or if the user presses the Back button enough times to return to the tombstoned application. Regardless of how users return to the tombstone application, the application will be reactivated (raising the Activated event) and magically show the last page viewed by the user before the deactivation.

You don’t believe me, let’s try it together. I’ve added a second page to the basic WP Silverlight application, and added a trace to both constructor pages. Next, I added a button to the first page that navigates to the second page.

In Visual Studio, start debugging your application and click the button to navigate to the second page. From the second page, press the Windows button. As expected, your application is deactivated and then terminated, as you can see from the following screen capture of the Visual Studio Output window.

Note the sequence of the trace (and the corresponding time-code). First your application launches, then the main page constructor is called, and after pressing the button on page one, the application navigates to the second page (DetailsPage), after which you press the Windows button raising the Deactivated event, which indicates that your application is tombstoned.

In the next post you’ll learn about returning to a tombstoned application and managing your state between tombstoning.

You can download the code for the code samples.

Windows Phone 7 Training Kit for Developers includes a full lab dedicated to the Windows Phone Application Lifecycle.

MSDN documentation includes a topic - Execution Model Overview for Windows Phone

Blog edited by Barbara E. Alban

Windows Phone Developer Training Kit – Beta Refresh

Yochay — Wed, 14 Jul 2010 00:33:53 GMT

Beta is here! This means we are getting closer to release, which means it is time you start building your Windows Phone applications ASAP. Just in case you are asking, here is a great resource to help you get started building great Windows Phone applications.

As part of our efforts to help developers jumpstart their development of Windows Phone applications, we released a refresh of the Windows Phone Training to meet the changes in the Windows Phone Beta tools release. You can download a local copy of the training kit, or you can go to the online version on Channel 9.

More information about the new tools can be found here

This release of the WP training kit includes all the labs from the previous release (updated to the Beta tools) and all the videos from the previous release. In addition we added two new labs:

Using Windows Phone Launcher and Choosers In Your Applications
Understanding the Windows Phone Application Lifecycle (handling Tombstone)

A new functionality in this Beta release tool is the exposure of APIs for using Windows Choosers and Launchers. The launchers and choosers framework enables Windows Phone applications to provide a set of common tasks for users, such as placing phone calls, sending email, and taking pictures. The “Using Windows Phone Launcher and Choosers In Your Applications” lab covers some of these new launchers and choosers. The emulator doesn’t provide the full Windows Phone user experience, and therefore we don’t cover all the available choosers and launchers in the API. But there is more than enough for you to learn about this topic.

Understanding the Windows Phone Application Lifecycle (handling Tombstone)

As you probably already know, Windows Phone allows only one application to run at any given time in the foreground, and no 3rd party applications are allowed to run in the background. Therefore when a user navigates away from your application, either to a chooser like picture chooser, or to a launcher like phone call, Windows Phone operating system terminates your application.

Tombstoning is the procedure in which the operating system terminates an application’s process when the user navigates away from the application. The operating system maintains state information about the application. If the user navigates back to the application, the operating system restarts the application process and passes the state data back to the application. This lab explain in great detail what tombstoning is, how it works, and what you should be handling in your application

Another area of improvement in the API is Push Notification Services. We’ve upgraded the lab to work with the updated Beta API and while doing so gave it a nice facelift. This lab features an end-to-end scenario for a simple weather application that registers to receive Push Notifications as well as a WPF client application that mimics the 3rd party backend server.

On top of that, the training kit includes four additional labs (all refreshed and up-to-date with the latest Beta tools):
Hello Phone - This lab aims to be the classic “Hello World” application, introducing you to the tools and procedures required to build and test Silverlight for Windows Phone applications. During the lab, you will see how to use Microsoft Visual Studio 2010 Express for Windows Phones, Expression Blend to build and design your Windows Phone applications, and how to deploy and debug your Windows Phone application on the Windows Phone Emulator

Building Your First Windows Phone Application – This lab introduces you to the basic building blocks of any Windows Phone Silverlight application. During the course of this lab you will create a simple puzzle game. The lab takes you through the different stages of starting a new project, adding controls and code behind, and testing and debugging. Unlike the Hello World lab, this lab focuses more on phone-related topics like navigation, using pages, frame and navigation services, multi-touch, and isolated storage.

Windows Phone Navigation and Controls – This lab introduces you to the Windows Phone layout system, the phone’s chrome, and few new controls. The lab explains the basics of navigating between different screens (pages) in a Windows Phone Silverlight application. During the lab you will build a navigation application that switches between various screens, with each screen displaying different phone functionality, such as playing an audio or video file.

Game Development with XNA Framework for Windows Phone – This lab introduces you to XNA game development on Windows Phones, as well as to the basics of XNA game development. During the lab you will build a simple XNA game application that introduces key concepts in XNA game development and learn how to use Microsoft Visual 2010 Express for Windows Phone to build and design your XNA games for Windows Phones

This post is an update to an earlier post - Windows Phone Developer Training Kit April Refresh.

Intuit Partner Platform Delivers Windows Phone 7 SDK

Walid Abu-Hadba — Tue, 13 Jul 2010 11:57:44 GMT

I am pleased to announce that Intuit is developing an SDK for Windows Phone 7, making it easier for developers to write Windows Phone 7 applications that interface with the Intuit Partner Platform's cloud services for businesses, including QuickBooks. This enables business professionals to access key data from a variety of Windows Phone 7 devices and easily view their cloud data hosted in Windows Azure.

Our work with Intuit further demonstrates the industry momentum for Windows Phone 7. Today’s announcement also extends the relationship we began with Intuit in January, when we announced that we were joining forces to deliver Web applications to millions of small businesses through the Intuit App Center via integration between the two companies cloud services platforms: the Intuit Partner Platform and Windows Azure platform.

Both Microsoft and Intuit Partner Platform remain committed to providing developers from both companies additional opportunities for revenue and by enabling them to develop for the cloud and for Windows Phone 7 devices, while also reaching Intuit’s vast network of businesses, we are certainly meeting this goal. I look forward to this continued relationship with Intuit and am excited about future opportunities.

Windows Phone Developer Tools Beta Released

Brandon Watson — Mon, 12 Jul 2010 18:28:00 GMT

First things first: go get the Windows Phone Developer Tools Beta. It has arrived!

The term “Beta” is understood to mean that things are close to being finished. Well, that’s what we mean anyway. This Beta release represents the near final version of the tools for building applications and games for Windows Phone 7.

Since the initial CTP release of the tools just this March, the Windows Phone Developer Tool CTP has been widely embraced by the community, and they have shown what’s possible on our new development platform.

It’s time to get serious about building the actual apps and games for Windows Phone 7 that consumers will be looking for starting this holiday season.

One of the things I really want to do is just take a step back and congratulate the entire Windows Phone 7 team. They have done an amazing job of delivering code month after month on our path to releasing later this year. Check out this timeline:

Feb 2010 – Windows Phone 7 was unveiled at Mobile World Congress in Barcelona
Mar 2010 – The application platform was unveiled at MIX 10 in Las Vegas. With that, we had the first CTP of the Windows Phone Developer Tools.
Apr 2010 – The tools received an updated, and the CTP Refresh shipped.
Jun 2010 – Windows Phone Marketplace details unveiled at TechEd 2010. Get the Windows Phone 7 Application Certification Requirements.
July 2010 – Beta release of Windows Phone Developer Tools, and the preview developer phones start shipping to ISVs

Whew! The Windows Phone engineering team has been crushing it.

Here’s a link to the release notes for the beta, but I wanted to talk about a few top level items:

Microsoft Expression Blend for Windows Phone – Blend is now integrated completely into the Windows Phone Developer Tools Beta.
Developer Registration Utility – Now you can unlock you Windows Phone 7 device for development purposes.
XAP Deployment Tool – if you want to deploy XAP files directly to an unlocked device, now you can.
The Windows Phone 7 API – we’re getting close to completion. Many namespaces that were previously distributed over several different DLLs have now been consolidated into one. In addition, there have been realignments and changes in several other namespaces as well. Push Notifications, Accelerometer and App Bar APIs have all been updated.
Additional Controls – There are some additional controls coming in the next few weeks (i.e. Panorama and Pivot) which didn’t make the beta release. They are coming soon.
Control Templates – Silverlight for Windows Phone control templates have been updated to match evolutions in the overall OS.

Get Trained – Windows Phone 7 Jump Start

Windows Phone 7 JumpStart is a FREE virtual live class for developers interested in developing applications and games for Windows Phone 7. We’re providing this in partnership with our MS Learning team. The course is organized into four virtual instructor-led sessions that are of 3-hour duration. They will be presented by forthcoming MS Press authors and MVP's, Andy Wigley and Rob Miles. It will provide developers a jump start for developing Windows Phone 7 applications. The Labs will be completed offline with office hours access to the instructors.

The dates for these course sessions are:

July 20 – 8am: Session One: Getting Started with Microsoft Windows Phone and Silverlight
July 20 – 1pm: Session Two: Programming Game Applications with XNA
July 22 – 8am: Session Three: Programming Applications with Silverlight
July 22 – 1pm: Session Four: Review and Wrap Up

Go register for the course now!

Devices for Developers

We made a promise last month that we would be getting pre-production preview devices to developers this month. We are keeping that promise. In fact, the very first preview devices were awarded last week to a pair of pretty amazing high-school students who won the Windows Phone “Rockstar” contest as part of the Imagine Cup. When we saw what they had done, we knew we had to get them preview phones.

Starting next Monday (July 19th), we start shipping the devices more broadly. Sadly, we will not be able to meet all of that demand. We are planning to set up deploy and test labs in major cities to make it a little easier for everyone who wants to have access to a preview phone to have it. More on that soon.

Lastly, to get your name in the queue, assuming you haven’t already sent in an email, you can now send an email to wp7req@microsoft.com. A field representative will get back to you as soon as possible. Again, these are preview phones, so they are limited in quantity. When you send email, please include the following information:

Your name
Company name, if applicable
What city/state/country you are located in
App(s) you plan on developing (category and brief description)

Twitter

At some point, we had to mention Twitter, right? We strongly encourage developers establish a connection with their local field evangelist, since they will be the ones ultimately putting phones into the hands of developers, but they can also point you in the right direction for solving problems, get you connected to other partners, and generally help out. To make it easier to get to know your local evangelist, we’ve set up this list - wp7dev/champs (http://twitter.com/wp7dev/champs).

You can also follow other members of the team based on their area of coverage:

@ckindel – WP7 Dev Platform
@ai – Mobile Social Media
@brandonwatson – Marketplace & Platform
@cschormann – Silverlight & Blend (UPDATED: Fixed incorrect spelling/link)
@mklucher – Gaming & XNA
@ozymandias – Gaming
@shawnhargreaves – Game Design

In Closing

This is a big milestone for everyone involved in Windows Phone 7 – inside and outside of Microsoft - and we hope you share in our excitement. With the Beta release of the tools, developers can build apps with a “ship it” mentality. There have already been so many amazing apps shown running on the emulator, and a lucky few who have been able to deploy to the phones at our developer events. We’re blown away by the early look at the apps, all of the sharing in the community, the blogging, and the screenshots. There’s a huge team of people here in Redmond who are all watching for new content tagged with “wp7dev” or “Windows Phone 7 Development.” It’s not uncommon for links to get passed around with a “wow, check out what these guys did!” Keep it up, and keep the faith.

Meet the Windows Phone 7 Rockstar team - Beastware

Anand Iyer — Thu, 08 Jul 2010 16:57:15 GMT

Anand Iyer here, and I’m onsite in Warsaw, Poland for the Imagine Cup 2010 finals. Last month, we announced the winners for the Windows Phone “Rockstar” contest – a team named Beastware who had created a game called “Droid Assault” a 2D XNA Framework based game for Windows Phone 7.

Today, the Polish Minster for Science and Higher Education, Barbara Kudrycka, awarded Beastware with their prize winning check. And to much of the team’s surprise, they were also awarded Windows Phone 7 devices – this team is one of the first set of non-Microsoft developers to get Windows Phone 7 preview devices!

We got to catch up with the Christian Hood, 17, and Eric Lo, 16, from the Beastware team. They are high school students at the Advanced Technologies Academy in Las Vegas, NV. One of the questions I had for them was how they emulated the accelerometer sensor and I was especially blown away about how the team had built a Windows version of their app using the XNA framework and used a library called WiimoteLib. They then ported the app to Windows Phone 7 and trusted that the accelerometer on the device would “just work” – and it did!

Here’s a short video interview with them:

Beastware Intro from Anand Iyer on Vimeo.

Also, here is a demo of the app:

Beastware Droid Assault Demo from Anand Iyer on Vimeo.

I’m really proud of what the Beastware team has accomplished I can’t wait for Droid Assault to hit the Windows Phone Marketplace!

@ai

Hey, You, Get Off of My Cloud

Charlie Kindel — Tue, 08 Jun 2010 17:01:23 GMT

Microsoft is making several announcements at TechEd this week that developers should be sure to catch, like the introduction of our new Windows Phone Marketplace policies. We’re also providing more details about some developer features, one of which I think is worth exploring more closely; private beta distribution through Windows Phone Marketplace. This is noteworthy not only as a cool new Marketplace feature, but also as a prime example of Microsoft embracing the concept of the public and private cloud.

At MIX in March we talked about the Windows Phone Marketplace and the public distribution aspects of that infrastructure. We also stated our intent to deliver a system whereby developers will be able to distribute applications to beta testers prior to marketplace certification. This week we are able to talk about this capability in more detail.

The public model enables developers to market and distribute applications to all phone users globally or based on a particular geography. In contrast the private model enables developers to use the same Marketplace service to distribute applications to a defined set of people that they select for beta-testing. Developers will identify their beta-testers and then upload their application to the developer portal. The Windows Phone application deployment system will then ensure that the application is available on the beta-tester’s phones via a “deep link” the tester will receive in email. We’ll be rolling this mechanism out as we finalize the developer portal this fall.

This private distribution for beta-testing represents an important first step for Windows Phone. Those of you who have heard me present on Windows Phone 7 know that I frequently speak of the importance that cloud services play in creating user experiences. Microsoft is a leading proponent of the “cloud” services that compliment local software, be that software on a server, desktop or phone. Cloud services are increasingly providing both public and private functions, whereby an organization can tap into a public service’s extensive storage, bandwidth and infrastructure for private projects. Windows Phone Marketplace is one such cloud service and our long term strategy is to adopt the public and private cloud model with Marketplace as well. Initially, we are enabling private distribution of applications for registered developers in a way that is optimized for beta-testers. This will enable developers to more easily distribute test applications in a secure way. We also appreciate that as phones come to market and people begin bringing them into corporate environments, IT will look for a similar private distribution solution. We are working with our corporate customers to understand the full scope of their distribution needs. We anticipate that our eventual corporate distribution solution will be an extension of the private cloud model we’re introducing for developers in Windows Phone Marketplace.

So we’re starting by implementing a feature to help developers test applications, but over time we’re going to build on this public and private cloud philosophy to make the Marketplace infrastructure accessible to corporate and business customers as well. This will create an even richer marketplace for the games and applications that already live there by attracting an even broader base of customers who will no doubt want more than line of business applications on their new Windows Phone 7.

And the Windows Phone 7 “Rockstar” is…

Anand Iyer — Tue, 08 Jun 2010 11:00:00 GMT

Back in March 2010, we announced the Windows Phone 7 “Rockstar” Award – an award that would be presented to the student team that developed the most compelling Windows Phone 7 application for the Imagine Cup 2010. Over the past few months, several hundred student teams from around the world were building Windows Phone 7 applications using the Community Technology Preview (CTP) of the developer tools. These teams were building applications using either the Silverlight or the XNA framework, and developed some really outstanding applications. The teams were asked to submit the XAP file, which we then used to judge the applications. The applications were tested both on an emulator as well as on a Windows Phone 7 device.

Today I’m pleased to announce that off the 131 teams that submitted their applications, a Windows Phone 7 “Rockstar” has been crowned.

Beastware – This team of 2 from the Advanced Technology Academy in the United States have built a game using the XNA framework called “Droid”. This game leveraged the use of the accelerometer on the device unlike any other app we’ve seen. The Beastware team is our “Rockstar”. The team members are invited to Poland where the team will be awarded USD8000 and each team member will receive a Windows Phone. Below, you’ll find a couple of snapshots of the app running on the phone (apologies for the blurriness – these pictures were taken of the app running on an actual device). We hope to get some video and in depth information about how this team went about building their app as they prepare to head to Poland.

And our runner up teams…

1^st runner up, Tselina – This team of 4 from Indonesia built a very slick looking comic book reader in Silverlight. The rich graphics and navigation built into this app made this app very appealing. The Tselina team will be awarded USD4000 and each team member will receive a Windows Phone.

2^nd runner up, Hypo Team – This team of 4 from TAR college in Malaysia have built an awesome game in XNA. This game has great graphics and a very clean interface. The Hypo Team will be awarded USD3000 and each team member will receive a Windows Phone.

This was a challenging contest for us to judge as there were a lot of apps that blew us away. Here are some other very interesting apps that received very high scores from our judges:

· Scavenger app

· A simple task manager app

· A PriceCheck app

· A travel trails app

· A restaurant/food finder app

· An on-the-go project management app

· A health/fitness monitoring app

· A simple study schedule manager app

· A cool looking weather app

· A Trivia Quiz App

Once again, we’re thrilled by the amount of excitement and innovation these students have exhibited in developing these applications. On behalf of the Windows Phone 7 team, I’d like to congratulate the Rockstar team, Beastware, as well as the runner up teams, Tselina and Hypo Team. We hope to catch up with each of these teams more leading up to the Imagine Cup awards in Poland.

@ai

New Policies for Next Gen Windows Phone Marketplace

Brandon Watson — Mon, 07 Jun 2010 19:44:00 GMT

Today we’re introducing the new set of Windows Phone Marketplace policies that will govern the application submission and certification process as Windows Phone 7 comes to market. We’re taking the next step with Marketplace to attract a much wider range of developers, from large software companies down to students and hobbyists.

We introduced our first Marketplace eight months ago and have already shown that there is demand for an app store that is both customer-centric AND developer friendly. Marketplace is evolving to give people a great selection of beautiful apps for Windows Phone 7 that we will take steps to ensure are high-quality and don’t introduce security or reliability issues. At the same time, we’re giving developers the respect they deserve in our use of transparent and uniform policies that still give developers the necessary information and flexibility to explore creative sales and marketing models. For Windows Phone 7, we’re keeping the basic tenets of our existing Marketplace philosophy and making a few enhancements for developers.

Specifically, the new Windows Phone Marketplace policies offer:

Annual registration fee of $99
No limit to the number of paid apps submitted 5 free apps per registration, $19.99 each after that
Free registration to DreamSpark students (same unlimited paid and 5 free apps applies)
A new optional push notification service to help developers stay engaged with customers
A new optional Trial API - trials mean more customers try your app, and less likelihood that they return it. The length or type of trial is fully controlled by the developer
The ability to publish to all available Marketplace markets through a new “worldwide distribution” option, allowing developers to pay once and distribute broadly
Wider range of business models; free, paid, freemium and ad-funded
Equally important to many developers is what isn’t changing:
A revenue share of 70/30
Developers manage their business with Marketplace via the self service portal http://developer.windowsphone.com
Payout takes place monthly for developers that have earned more than USD$200 worldwide
Developers can make ad funded applications
All applications go through a process of technical and content certification
Marketplace offers support for credit card commerce, and where available mobile operator billing.
Microsoft continues its practice of publishing policies, guidelines, and submission process details to developers so they understand exactly how marketplace works.

The full list of Windows Phone Marketplace policies is now available here.

Bottom line – we have listened to developers and responded to changing customer behavior to make Marketplace an even better experience for all. We’re adding many of the new features you’ve asked for. For those considering developing for Windows Phone for the first time, we hope you see a fresh opportunity to create truly unique and exciting apps and games. For those who have already published apps to the Marketplace, we hope you find this new direction exciting. Be sure to download the Windows Phone Developer Tools preview, check out what Marketplace has to offer and tell us what you think.

If you’re also interested in what Windows Phone 7 means for business, see Paul Bryan’s report from TechEd on the Windows Phone Blog.

If you have app ideas or want to talk Windows Phone development, find me on Twitter. Also, read this if you want to find out about Windows Phone developer devices.