Welcome to Jeff Fansler's Blog

I've spent many years in the computer industry. I've worked in labs installing software, building computers, setting up networks, and teaching people how to use a mouse. I've worked as a developer building business applications and products. I've worked as a manager building teams and processes. In the end I've ventured on building a company which allows me to do a little of everything. This blog is where I talk about what I've learned during my journey

 

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.


This is going to be a short post.  If you search the interwebs for information on navigation in WP7 you will find plenty of information.  I’m adding to that information mainly for my own good.  Hopefully you will get some use out of it as well.

The first point to make here is that navigating in WP7 uses the System.Windows.Navigation API.  This is not a new API.  I believe it was introduced with Silverlight 3. If you are already comfortable using this API then you are all set. If you are like me and haven’t worked with a lot of Silverlight then it’s new.

Navigation is simply the act of going from one xaml page to another.  I’m a web developer and this is very much the same as moving from one html page to another. In fact if you are comfortable with how navigation works in the web world, you will be comfortable here. In order to navigate from one xaml page to another, all you need to do is call the Navigate method off of the NavigationService class with the URI of the page you want to go to.  Here’s the code:

private void BtnNextPageClick(object sender, EventArgs e)
{
    NavigationService.Navigate(new Uri("/Page3.xaml", UriKind.Relative));            
}

That’s the meat of navigation. As I said, this is going to be a short post. 

Ok, well, I guess there are a few other items to cover. Let’s cover the rest in a Q&A style:

How do you go back to the previous page?

Good question, I’m glad you asked.  All Windows Phone 7 devices will have a hardware back button.  If the user clicks it, they go to the previous page.  If there isn’t a previous page, your app closes and it goes to whatever was running before your app launched. Some of you may be tempted to add a button to your screen to give your users another way to go back.  I honestly can see no good reason to do this.  I remember when some web pages would add back buttons to them and it’s just pointless.  It serves to confuse the user.  Let them use the back button on the device.  Any time they ever want to go back, they know where to go.

How do you pass data from one page to another?

Oh, another great question.  As I mentioned earlier, if you are comfortable with navigation on the web, you’ll be comfortable here.  To pass data you use a query string.  A simple name/value pair string.  It starts with a “?” and each value is separated by an “&”. Here’s an example:

private void BtnNextPageClick(object sender, EventArgs e)
{
    NavigationService.Navigate(new Uri("/Page2.xaml?Message=Main Page Says Hi!", UriKind.Relative));
}

In this call to Navigate I am passing in a property called “Message” that has a value of “Main Page Says Hi”.

Hmm, that’s cool, but how do you consume that data?

Boy, you guys are on a roll with the great questions. Let me start by showing you a potential gotcha. You may be tempted to use Loaded event off of the page to read in the value from the query string and then consume it.  Don’t do this.  The Loaded event isn’t guaranteed to run every time your page shows on the screen.  It only runs when your page is loaded, and it could already be loaded.  Instead, override the OnNavigatedTo method.  Reading the actual value is pretty simple.  The QueryString dictionary is  part of the NavigationContext class. To read it you should use the TryGetValue method off of the QueryString dictionary.  The code looks like this:

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
    var message = string.Empty;

    if (NavigationContext.QueryString.TryGetValue("Message", out message))
    {
        MessageBox.Show(message);
    }
}

So what about passing complex data types? What if I want to pass a person?

Well, I’m open to other ideas here, but I will give my opinion.  Don’t do it.  Each page or view should only know about the data that it needs to render. When navigating to a new page, it’s because you want to see different data.  That means the new page should only care about the data it needs which will be different then the page you are navigating from.  Normally I pass ID’s around.  As an example,let’s say I want to have a page that displays summary information about a player on the Detroit Red Wings.  I then want to be able to navigate to a page that shows me the history of teams the player has played for.  I would create a hyperlink or button on the summary page to navigate to the summary page.  I would pass along with that the ID of the player.  On the summary page I would lookup the history information only for that player and display it.  This question could turn into a much larger topic on Model-View-ViewModel and such so I will leave it at that. If you are interested in me covering that topic at some point, leave me a comment.

Thanks for all the great questions and have a great day!