Ranting and raving about anything I feel like complaining about.

Should You Upgrade Your WP7 App to Mango?

Yes.

Ok, maybe I can’t leave it at that. As Windows Phone 7 users upgrade to Mango, they probably want a Mango (e.g. Windows Phone OS 7.1) version of your application. Don’t disappoint them. This doesn’t mean you should completely retool your application for Mango.  But if I am suggesting that you don’t spend a lot of time on the new app, then why create one to begin with? Fast Task Switching.

Fast Task Switching

Fast Task Switching in Mango allows users to more easily leave and return to your application. What this effectively means is that users will be able to switch away from your app and return to without tombstoning in most situations. If a user leaves your app then wants to return to it, in Windows Phone OS 7.0, you had to save state when the user left and re-hydrate it when they returned – usually resulting in a short delay for the user. In Windows Phone OS 7.1, the operating system will suspend your process when the user leaves your app. You still need to save the tombstoning state, but when your application is restarted, the operating system will tell you whether you need to re-hydrate the tombstone data. This means that in many cases, returning to your application should be almost instantaneous.

So, how do you know? In Windows Phone OS 7.0, you would be given an opportunity to rehydrate your application during the application’s Activate event like so:

private void Application_Activated(object sender, ActivatedEventArgs e)
{
  var state = PhoneApplicationService.Current.State;

  if (state.ContainsKey("SelectedPivotIndex"))
  {
    this.currentPivotIndex = (int)state["SelectedPivotIndex"];
  }
}

By storing the state in the PhoneApplicationState class, this data will be tombstoned for you. This doesn’t’ change in Windows Phone OS 7.1, but you are giving information in the Activated event to tell if you need to load the state from tombstone data:

private void Application_Activated(object sender, ActivatedEventArgs e)
{
  if (!e.IsApplicationInstancePreserved)
  {
    var state = PhoneApplicationService.Current.State;

    if (state.ContainsKey("SelectedPivotIndex"))
    {
      this.currentPivotIndex = (int)state["SelectedPivotIndex"];
    }
  }
}

By using the new IsApplicationInstancePreserved property of the ActivatedEventArgs class you can determine if you need to de-tombstone. If the Application’s process was preserved (which will happen a majority of the time), you can simply ignore tombstoning as all memory was preserved from when it was deactivated.

At a minimum, you should add this simple check and publish a Mango version of your app. It will make your users much happier.

 
 

Comments

Gravatar Shawn great post but the problem of updating apps to Mango would be the Nodo version frozen afterwards.
So unless I know for definitive when Mango will be available for the general public, I don't have any interests in publishing that soon.
Imagine for instance you push a Mango version of your app, but you discover that a bug needs to be fix in the Nodo version? Inmagine if you have to wait 2 solid months to release an update? And when I say 2 months, I am optimistic!
So when Microsoft will officially announce the launch of Mango, then I will reconsider my position.
Gravatar Peter,

I understand your hesitation, I really do. But for a majority of app dev's out there, they don't publish many updates and the benefit of the improved Fast App Switching means that I think a lot of users would benefit from upgrading the app. But I understand and hope that MS will have a good solution for updating both trees.
Gravatar I publish an update about every 3-6 weeks and I am not going to freeze a version until it's been out there (bug-free) for at least 4 weeks.
I have decided to use the following and hope it gets certified (credit: http://www.sharpgis.net/post/2011/08/21/Windows-Phone-Adding-Mango-features-to-a-70-WinPhone-App.aspx):

bool isPreserved = false;
Type type = typeof(ActivatedEventArgs);
System.Reflection.PropertyInfo property = type.GetProperty("IsApplicationInstancePreserved");
if (property != null)
{
isPreserved = (bool)property.GetValue(e, null);
}
Gravatar Apparently Shawn looks like a lot of developers disagree with you,i believe you see the app hub petition to get things sorted out.
Unacceptable for me and others to release an app for Mango if I can't keep the NoDo userbase happy. And I know also people which are still on pre Nodo
Gravatar Peter,

I understand, but since most apps aren't being updated at all, I want to encourage static apps to update themselves. I am hoping MS is working on a dual OS strategy, but unsure.
Gravatar Calum,

I don't see how that is going to help. Does that work in Mango even on NoDo apps? I didn't try it, but i'd be surprised if it does.
Gravatar Shawn, is there anyway to force an app instance to not be preserved? I'm just thinking about testing Application_Activated code
Gravatar Will, not that I know of.
Gravatar Thanks Shawn, just wanted to make sure I wasn't missing a better way!
Gravatar I dont see what this has to do with wpf. If i have a wpf app that runs on multiple platforms, why would this one small feature make a hill of beans in the larger scheme of things?
Gravatar Wade - it has nothing to do with WPF, why would you think it did?
Gravatar I'm facing the same problem, but I think I have a really simple solution. Have a flag that gets set to true in your app's constructor. At the end of Launching and Activated events, set it to false. Then, during the Activated event you can use it just like you would IsApplicationInstancePreserved. This should work in Mango AND 7.0 right?
Gravatar Aranda,

It could but not guaranteed.

Add a Comment

*
*
*