There is a huge amount of interest in the new Windows Phone platform. This new platform is new and cool and provides a great platform for applications. The new Windows Phone programming model uses a custom built Silverlight runtime to execute 3rd party applications. Native code access to the system is limited to Microsoft and OEM / Cell Carriers that have access to the proper certificates.
While managed application development is quite limiting to those of us who have had the freedom of the system for over 10 years of Mobile devices, it’s clearly easier to develop a good looking Silverlight application than it is to write the same application using the basic Win32 API.
So, unless you work for a device manufacturer or cellular carrier, you’re left with writing Silverlight apps that not only can’t access the system and, according to Microsoft, can’t even run in the background. To quote SNL’s Seth Myers; “Really!?!” Fortunately, applications aren’t quite that limited.
First, a caveat. This post is based on some investigations of the current emulator image provided in the April refresh of the Windows Phone tools. There may be changes by the time the OS reaches “real” hardware or simply due to changes due to tuning as the OS comes close to release. Now, with the lawyers satisfied, let’s look at what is “really” going on.
Basic Application Start up and Termination
Let’s do some basic stuff first. The user can switch from a running Windows Phone application essentially two ways. First, the user could hit the Back button while the application is running. If this occurs, the OS closes the application. If the user later starts the application, a new instance of the application is launched. It’s the responsibility of the application developer to restore any state to the application to reproduce where the application was when the user hit the back button.
Applications can be notified of startup and shut down by adding the appropriately named Application_Startup and Application_Exit events fired by the System.Windows.Application class. You can add handlers for these events two places. The first way is to add the event by adding attributes to the Application class element in App.xaml.
The other way to hook these events is to do it programmatically in the Application class constructor. This is the way the default Windows Phone template code hooks the third Application class event, UnhandledException.
When the application is started, the class constructor is first called then the Application_Startup event handler is called. When the application terminates, the Application_Exit event handler is called.
Suspending and Resuming an Application
If the application is running and the user hits the Windows or Search buttons, the application is not (normally) terminated. Instead the OS places the app in a “suspended” state in memory. If the user later returns to the application either by restarting it or simply hitting the back button to dismiss the newer screens, the application resumes.
In these cases, the Application_Exit event isn’t fired since the application never terminated and since it was never restarted the Application_Startup event isn’t fired on resume. However, there are two events that are: WindowsPhoneEvents.Pause and WindowsPhoneEvents.Resume. These events are in the Microsoft.Phone.Execution namespace. They can be hooked in either the Application class constructor in App.xaml.cs or the MainPage constructor in MainPage.xaml.cs. These events fire as expected, when the application goes into the background and then when it returns to the foreground.
If the application terminates, the Pause event fires before the Application_Exit event, so you can use the Pause event has an indication of both suspending and exiting. In general, this is also true if the application is running in the background. The Pause event will fire on going to the background and then when the application is terminated, the Application_Exit typically event fires. I say typically because I’ve seen places where the Application_Exit event doesn’t fire if the application is in the background. This may be a bug in the current implementation, but it is something you should know.
Background operation
The Windows Phone team made waves when the platform was introduced by indicating that, at least initially, Window Phone would not multitask 3rd party applications. The answer sounded pretty absolute. The actual implementation isn’t.
This isn’t the place for a treatise on multithreaded managed applications. But briefly, very briefly, Windows Phone applications can be multithreaded. The main thread of the application calls the appropriate methods to create the main application form and is the “user interface thread”. Other threads created by the application can’t directly interact with the user interface. These threads are called “worker threads” or “background threads”.
When an application is sent to the background, the foreground thread is suspended. However, any worker threads currently running in the suspended application continue to run. These worker threads can call base class library methods such as querying the file system, reading and writing files, and such even while the application is “suspended”.
When a worker thread tries to invoke a method on the foreground thread, that request is queued but not executed. When the application is resumed, the queued calls are invoked.
Of course, “suspended” applications live on borrowed time. If the system needs the memory used by the application it will be terminated. At that point, the Application_Exit event should (but sometimes doesn’t) fire.
A Feature and a Consequence
So, while true multitasking doesn’t exist on the Windows Phone, applications can ‘borrow’ some background processing time as long as the system is lightly loaded. This sounds great and can be used to the advantage of the application. However, developers should understand this “feature” and if their applications have worker threads that don’t need to run while the application is suspended, they need to ensure that those “worker” threads block while the application is suspended.
It should go without saying that all threads should block (almost) all the time. Threads that poll or simply run too long will quickly drain the battery of any mobile device. A poorly written worker thread combined with the system’s ability to run these worker threads while suspended could easily ruin the battery life on a phone.
The new Windows Phone platform has attracted interest from a vast array of .NET developers who are quite familiar with desktop and server development. However, phones, PDAs, and other battery powered devices are very different animals.
Remember, you’re developing on a phone, not a desktop, things are different down here!
