For almost two years our company has been developing iPhone applications. As a Silverlight MVP, seeing Windows Phone 7 support Silverlight as a development platform, is like a dream come true. So naturally the first thing to look at is what is different? In this post I’ll look at multitasking.
There hasn’t been a lot of talk about multitasking but as I understand, it is quite similar to the iPhone. Applications are in one of two states hydrated (active) or dehydrated (inactive). Developers are encouraged to save and restore application state between different events – closing, deactivationg and activating.
The application will go to the closing state when the user presses the hardware back button beyond the front page of your application. In here data that is persistent throughout app instances should be saved to isolated storage. You should not save data that is specific to current instance because this instance will never be resumed.
Closing on the iPhone
On the iPhone applications are closed (applicationWillTerminate:) when the user explicitly closes them from the multitasking UI or when the app is running on older systems that don’t support multitasking. Application may also be closed when the state saving is taking too long (> 5 sec).
Windows Phone application will go to deactivated state when the user presses the start-button, the app is killed for saving persistent data too long (10 secs is the max) and when the user is using a Launcher or a Chooser. Application may but might not be resumed after this state.
Application will not be resumed when the user starts a new instance by picking the same app from the app list again, or when many apps are opened in a row and your app could no longer be reached using the hardware back button.
So you are assumed to be saving app state before launching a chooser or launcher.
Deactivating on the iPhone
Apple also has a time-limit for saving application state – 5 seconds. What is different is that Windows Phone deactivates your application when you initialize e-mail sending (use Launchers or Choosers). On the iPhone sending an e-mail is part of your application and only way away from the e-mail app initialized from your app MFMailComposeViewController is through your app. You get an event that the e-mail composing was finished. The same applies with image and video pickers on the iPhone, but on Windows Phone, you send your user to pick an image, send an e-mail and might never see the user again.
Another difference is that on Windows Phone you can always “restart” an application by starting a new instance of it by choosing it from the application list. On the iPhone when you tap on the icon of a running app you get the running instance of that app not a new one.
Your Windows Phone app enters the activating state when:
- the user finished using a Chooser or Launcher.
- user launched a new app and now pressed the hardware back button enough times to reach your app.
Now your app should restore saved state from PhoneApplication.State and the user should never know that the application stopped running.
Activating on the iPhone
On the iPhone there really isn’t a built in mechanism for state saving, you get the events applicationWillResignActive:, applicationDidEnterBackground: and applicationDidBecomeActive: but within those it is really your task to somehow save the state.