Lifecycle Constraints in Windows Phone 7

When working with the execution model in Mango there is some key constraints that you should take into account. If you’re familiar with the Phone 7 OS you may be aware of these points.

Deactivation -> Dormant -> Tombstoned -> Closed

When you’re application is deactivated, it immediately goes into Dormant mode it later maybe go into Tombstoned and even later it may get Closed.

So when handling the deactivated event it’s important that you save any states that should span application instances such as user settings, disk storage as well as transient dictionaries so that state can be later restored even if the application gets closed by the OS.

In the launching event handler you should perform as little work as possible as long running test can delay the application startup. Likewise, the activation handler executes the four execution startup, so any work perform in it should complete quickly otherwise you should upload it to a separate thread. Just like in WP7 all event handlers and navigation methods should complete within 10 seconds or else the OS will terminate the application. Likewise, codes that runs in deactivation or closing should only complete within 10 seconds. Running code on a separate thread does not help in these cases since these applications are being stopped anyway.

So, if large data writes are necessary it’s best to save data incrementally throughout application execution instead of saving them all in deactivation.

Launchers and choosers will deactivate app and this is a change from WP7

When a launcher or chooser is open by the user the application will go into dormant mode, this behavior is a departure in WP7 where the application actually continued to execute code although this behavior was undocumented. Similarly, when the phone lock screen is engaged the application also goes in Dormant mode.

Unless the application is allowed to run under lock screen. If that’s the case the application will continue running and will not be deactivated which makes sense. Now to allow for an application to continue to run when the lock screen is engaged you need to set the ApplicationIdleDetectionMode property of the PhoneApplicationService object to devalue disabled. You can also handle the obscured and unobscured events that are exposed by the root frame to minimize CPU and battery consumption while the application is locked.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s