Welcome to Jeff Fansler's Blog

As promised, here’s my post on launchers and choosers.  There is a lot of information out there on this topic. I’m adding to it for my own benefit. The two sources that I pulled most of my information from were the 3 part post from Yochay located here: Part 1, Part 2, Part 3, and the WP7 Training Kit Launchers and Choosers Lab.

What are Launchers and Choosers

A pretty common scenario for a phone application is to utilize the functionality that exists on the phone.  I’m talking about features like accessing contact data, sending emails and texts, dialing a phone number, and searching the web.  All of these features are part of the phone and it’s nice to be able to access these features within your own applications.  As a 3rd party application developer you do not have access to these features directly. You have to use Microsots API’s to access them.  These API’s are called launchers and choosers. The difference between a launcher and a chooser is simply that choosers return data. The launchers and choosers are covered under the Windows.Phone.Tasks Namespace. You can see the list from the API docs.

Using Launchers

Launchers are pretty simple.  You create a new instance of the launcher you want to use, set any properties, and call the Show() method. Here’s an example:

var task = new WebBrowserTask() {URL = "http://www.ThisIsFanzoo.com"};
task.Show();

That’s really all there is to launchers.

Using Choosers

Choosers are similar but a little more difficult.  You have to create a new instance of the chooser and set any properties just like the launcher.  Unlike the launcher, you have to give your chooser a way to return data.  This is done using the choosers Completed event. I found this to be interesting.  If you remember my last post, I said that no matter what, if your application is not on the screen then it is terminated.  Well, when you show a chooser, your app isn’t on the screen.  If your app is terminated, how is the event going to fire when the chooser is done?  This is a gotcha that I encountered.  When I started writing my first sample, I created the chooser and wired up to the completed event all in my button click event handler.  It took me a while to figure out why the completed event wouldn’t fire when control returned to my application.  After playing for a while, I realized that when my application was terminated, so was the event handler. To get around this, I created my choosers in the class scope and initialized them in the page constructor.  This way, when my app is activated the constructor runs, wires up to the completed event and then WP7 magically fires that event. Here’s what the code looks like:

private PhoneNumberChooserTask _choosePhoneNumberTask;

public Choosers()
{
    InitializeComponent();
    _choosePhoneNumberTask = new PhoneNumberChooserTask();
    _choosePhoneNumberTask.Completed += new EventHandler<PhoneNumberResult>(ChoosePhoneNumberTaskCompleted);
}

Let’s also take a look at the completed event handler. In this example I am taking the chosen phone number and sending a text message with it:

private void ChoosePhoneNumberTaskCompleted(object sender, PhoneNumberResult e)
{
    new SmsComposeTask() {Body = "I Like Windows Phone 7", To = e.PhoneNumber}.Show();            
}

I hope you found this post helpful.  If you’d like to see the source code, you can get it here.

How’s that for a title.  At least it’s descriptive. As it says, this post was going to be on Launchers and Choosers in Windows Phone 7.  After struggling a bit I realized that before I could understand exactly how the Choosers were working, I needed to understand the application execution model.  So here we are, the WP7 application execution model.

Every post I’ve read about the WP7 execution model starts out talking about the lack of multi-tasking and this post will be no different.  WP7 does not support multi-tasking.   This point has caused some controversy. Old versions of the Windows phone supported multi-tasking.  So does Android and iPhone (with iOS4). The rest of this paragraph is my opinion on the multi-tasking issue. Unless MS can get multi-tasking down perfect, I’m glad it is not included. So why doesn’t MS just copy Android’s model?  Because it sucks.  If my Mom has an Android phone and I have to explain to her how to kill an application because it’s draining her battery, then the model is broken.  I believe Steve Jobs said something like, “If you have to manually kill an application, you are doing it wrong.” As soon as I see some flavor of a task manager on a phone I cringe. I don’t want WP7 to be a geek only phone.  I want it in as many hands as possible, and I want it to just work. So why not follow Apples model.  They have done a better job.  It’s simple.  As a user I don’t have to worry about closing an app.  That said, since I’ve upgraded my iPhone 3gs to iOS4, it’s been much more buggy then it used to be.  In my naive mind, I blame this on the multi-tasking. I have seen the phone become more responsive by going through my app history and clearing it out.  If I have to do that, it’s the same as a task manager, it just looks nicer. I may be the only one, but until MS can get mutli-tasking perfected, I don’t want to see it on the phone. That’s my opinion, take it for what it’s worth.  Let’s get into the details of what this means.

Without multi-tasking this means that any time your app is not on the screen, it is terminated. There are lots of reasons for your application to leave the screen.  A few examples include the user hitting the back button beyond the start of your application, hitting the windows, using a chooser to select a phone number from a list of contacts, etc.  All of these examples will terminate your application.  There are four important methods that fire as your application loads and is terminated.  Each of these methods are defined in the App.xaml.cs class of your application. Let’s look at each one and understand what they do.

Application_Launching - The launching method fires when you application loads a new instance.  This is the method that would fire the first time you run your app.  Also, if you hit the Windows button, go to the application list and launch your application this method will fire.  This method indicates that you are launching a brand new instance of your application.

Application_Activated - Activated and launching are mutually exclusive. Both will not execute, only one.  Activated is run whenyour application is loaded, but it’s not a new instance.  This was confusing to me, because instance isn’t really the correct word. The applications are always a new “instance” because there is no multi-tasking. The difference is how your application is launched.  If activated is called, it means that your app was running, then was terminated to do something else, and then was launched again.  An example of this would be using the Windows key, launching a different application, then using the back button until your application is on the screen again.  A better example is when you use a chooser to select a phone number.  When the chooser returns with a result, application activated will be called.

Application_Deactivated – The opposite of  Activated, Deactivated is called when you might come back to the application. If a phone call comes in or if you launch a chooser to select an email address deactivated would be called.

Application_Closing - Closing happens when you aren’t going to come back to your application.  Mainly this occurs when you use the back button to go past the start of your application.

I can’t stress enough that any time your application is not on the screen, it is terminated.  You can use these events to handle the storage and loading of data when this happens. There are several ways to store data but two very common ones.  One is in IsolatedStorage.  You should use IsolatedStorage any time you need to store data more permanently.  The other common option is in the PhoneApplicationService.Current.State dictionary.  Use the dictionary when it’s nice if the data was stored, but not critical.  A common use here is to save the values from a form that the user entered so that when they come back, they don’t have to start over with a blank screen.  Keep in mind that your data is not guaranteed to remain in the State dictionary.

If you want to learn more about the execution model there is a great three part post from  Yochay.  Here are the links: Part 1, Part 2, Part 3.

My next blog post will be on Launchers and Choosers.  Before I get to that, here’s a quick tip if you are getting started with them.  When you launch your chooser and then see a blank screen after you pick something, hit F5 in Visual Studio.  This is a feature.  Notice that the VS debugger detaches when you launch the chooser.  The blank screen is your opening to re-attach the debugger so you can continue debugging your app.  It took me a while to figure this out so hopefully this helps.