Window phone 8 introduction

Windows Phone 8
Architecture
App Model and Navigation

http://www.paxcel.net

Contributors : -

Pallavi Vasishta - pallavi.vasishta@paxcel.net
Ranjan Baryal - ranjan.baryal@paxcel.net

Paxcel technologies. www.paxcel.net
This is the exclusive property of Paxcel Technologies. This may not be reproduced or given to third parties without their consent.

Windows Phone Architecture

Note : Although Win32/COM APIs are only shown in the Core Application box , they are
actually callable by managed apps, as well, as long as they are wrapped in a custom
WinPRT component.


App Types


App’s Lifetime Management Events


Transitions from Foreground App to Back stack
The Closing case This is when an app terminates and receives the Closing
event. This is unambiguous and simple to handle: it happens when a user
presses the hardware Back button from the first page in the app, which kills the
app instance and the process itself.

The Deactivated case This is when an app is moved to the background and
receives the Deactivated event. It happens when the user leaves your app in
the back stack. The app must save sufficient transient state to recreate its
current UI in case the user returns to the app instance, even if the process has
been terminated in the meantime.

– Tombstoning The app is deactivated and the process is killed,
but the app instance is maintained. There’s nothing actively
running or even sitting in memory, but the system remembers the
app’s critical details and can bring it back to life if needed.

– Fast app resume The app is deactivated and then immediately
reactivated, without being tombstoned in between.


Normal Termination


Fast Resume State


Tombstone State


Some Fact About Deactivating App

• In the fast app resume scenario, the IsApplicationInstancePreserved
property is true on Application.Activated, whereas in the tombstone
scenario, the IsApplicationInstancePreserved property is false on
Application.Activated.

• The system retains only five apps on the backstack, including the
one that is currently active. As soon the user launches the sixth app,
the app at the beginning of the backstack (that is, the one that was
used least recently) is discarded completely.

• If memory pressure increases to the point at which the system
needs to reclaim memory from deactivated apps, it will first start
tombstoning apps from the end of the back-stack.


Resource Management During Deactivation of Apps
• When App is Deactivate especially hardware resources such as sensors, and camera etc. ,
which can only be used by one app at a time can be deactivated using standard
OnNavigatedFrom and Deactivated events. However, if you do not proactively release
resources, the framework will do the job for you. It’s best to keep control of this yourself so
that you can track which resources you were used and reinstate them as needed, if the app
is later reactivated.


Resuming The App
• When an app is reactivated from the deactivated state, the framework resumes
timers and threads, and reattaches some (but not all) resources that it previously
detached. The developer is responsible for reconnecting/resuming media playback,
HTTP requests, sockets, and the camera.


Obscured And Cancelling Navigation Events
• Some external operations Lock Button Pressed merely result in the app becoming temporarily
obscured. In this scenario, there is no NavigatedFrom or Deactivated event. Instead, the system
raises an Obscured event.

• The system’s normal assumption is that if an app is running and the lock screen engages, it is
reasonable to deactivate the app.

• By disabling ApplicationIdleDetectionMode, the app can continue to run under screen lock. Then if
you want to reduce battery consumption you will have to removes un necessary Resources
yourself.

• The Obscured event does not imply that the entire app UI is obscured. In many cases like for an
incoming phone call, the UI is only partially obscured (at least until the call is accepted). the app
does actually continue running, executing whatever operations it was performing when it was
interrupted.

• If you want to handle the Obscured and Unobscured events, you attach event handlers to the
RootFrame object.

• Cancelling Navigation Event - Navigations that are initiated by the user by interacting with your
app UI can generally be cancelled,whereas navigations initiated by the user interacting with
hardware buttons or initiated by the system generally cannot be cancelled. This can be accessed
from NavigatingCancelEventArgs in NavigatedFrom Event.


The Page Model

• All the inter-app and intra-app instances are stored in a back stack as a
collection of pages.

• The inter-app backstack of app instances is limited to five apps but there is
no hard limit to the number of intra-app pages that can be kept in the page
backstack.

• The app platform keeps track of which page (in a multipage app) the user
was on when he navigated away.

• The Creation order of pages might not be same as in original App.

• One consequence of this is that the app should not rely on a hierarchical
relationship between pages in terms of object lifetime.

• Instead, all pages should be responsible for maintaining their own private
state, and any state that is used across multiple pages should be held in the
Viewmodel


Thank You !


Window phone 8 introduction

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Window phone 8 introduction

Ähnlich wie Window phone 8 introduction (20)

Mehr von Paxcel Technologies

Mehr von Paxcel Technologies (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Window phone 8 introduction