For my Windows Phone 7 app, I have a main panorama page which opens up into a pivot control. The main panorama page correctly calls Activated/Deactivated, and restores correctly.
But after visiting the pivot page, pressing the Windows key doesn't call Deactivated.
When the app is relaunched with the back button, it goes right to how the page looked before tombstoning, but Activated is not called, and the page is not usable, and the back key doesn't work.
Has anyone else experienced this problem before?
If you just go to the Start screen then your application MAY not get tombstoned. This is expected behaviour.
If you open another application or open search from within your application you should experience tombstoning.
Related
I am a little bit confused if I need to really do anything for fast switching. It seems like if I am not using media element, camera and sockets I get this "fast switching" for free.
I am not sure how to test it though. I see a couple videos where
Hit the Windows Icon(Start Icon)
Hit the back button
or
Hold down the back button till you get the screen view
Go to some other app
Come back to your app.
These both seem to load up fast again but how about if.
Load up app
Hit windows icon
click on tile app
Should fast switching happen at this point or does it load a new instance of your app up killing your old one?
There is different concept involved here:
-the first thing is Fast App resume which is a new feature of windows phone 8 that you can enable so that when you press the application tile it don't restart your app but keep the same instance (by default it will just kill the app and just recreate a new instance exactly as if the app was never opened). You can find more information about that here.
-the second concept is Fast App Switch and Tombstoning. You can find more information about the application life-cycle here. Basically what happen is when you press the windows button or navigate to another app your app will go in dormant state. In this state the application is not running but is still in memory. When you go back since everything is still in memory everything should as it was left off. The main case to handle in case of fast app switch is the fact that when your app is deactivated all the network connection are killed so you should make sure that when you go back you don't display any web error message dialog and that you redo any failed web request.
The second possible state of your application is that after the app is in dormant state you open a couple of app and the device don't have enough memory, then it will choose to tombstone your app. In that state your app is removed from memory so anything you have not saved will be lost. When you go back to your app it will go back to the page where the user previously was and recreate it.
That mean that to handle this case before the app deactivate you should have :
save any context specific data that you might not have been passing by navigation parameter.
maybe save what the user have been currently doing (for example if he is currently entering a long text, it might be better to save it so that the user don't have to reenter it from scratch)
saving the current scroll position or thing like selected items could be a plus
Also when the app resume you have to make sure that you re-query all information that you need. An example of something which would break would be if you load some Data (from a web server for example) in OnNavigatedTo of the main page and then just reuse the data on the detail page without re-querying it. If you are on the detail page press the start button and then do some other and the app tombstonne, when you go back to the app than the data will not be available (since the memory has been "cleared" and onNavigatedTo of the main page is not called since it will navigate back directly to the detail page).
You can use the page state and application state to save whatever information you need to handle properly the tombstoning case. Basically there are dictionary to which you can add some object which will be serialize (so you need to make sure that whatever object you try to save is serialisable) automatically when the app is deactivated.
To test the Tombtonning case easily, what you can do is in the project properties, in the Debug Tab check the check box "Tombstone upon deactivation while debugging". Like this it will always tombstonne the app when you debug and press the windows button or go to another app. To check that it is really tombstonning, when you go back you should see your app showing a resuming screen for a few second (while in the tombstonning case it's almost instantaneous.
So this is a bit confusing. It took me forever to figure out what they really mean by this.
What fast switching references is for more complicated apps. Apps that take advantage of something that requires a saved state.
For example if you are creating a navigation app. You are navigating then you leave the app. When you go back to that app it should show the "Resuming..." indicator and then bring your app back to its previous state.
Here is a Channel 9 video on FAS
http://channel9.msdn.com/events/MIX/MIX11/DVC09
Also here is the MSDN article about it
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967547(v=vs.105).aspx
Should fast switching happen at this point or does it load a new instance of your app up killing your old one?
In that case, new instance of your would be launched.
Actually, its a bit confusing, but not that much.
App can be either closed (by Windows key or pressing BAck key for a while) or exited (by pressing Back key in the main menu). Next, app comes to dormant state, it holds everything in memory. ApplicationDeactivated would be risen.
So, if you would just re-activate it (by pressing Back and selecting your app, or by pressing Back only, if you have nothing else in the stack), it would be resumed. ApplicationActivated event would be risen with e.IsApplicationInstancePreserved = true
If you would use lots of other apps (device would run out of memory), your app would go to tombstoned state. Then, you'd be needed to restore all data. e.IsApplicationInstancePreserved would be false.
If you would re-launch your app (by clicking on tile), new instance would be launched, and ApplicationLaunching would be risen.
Fast switching isn't something that really concerns you as a developer. What you need to worry about is "tombstoning" - when someone switches away from your app, you need to save the state: when the user switches back to it, you as the developer have to assume that your app was actually restarted from scratch and needs to reload that saved state. That's the difference between Application_Launching and Application_Activated (user started your app anew from the start screen, vs. app was suspended and is now being resumed, but from scratch).
At some earlier point this was the only way app switching worked. Fast App Switching was added later on and simply changed the contract such that sometimes your app would be resumed where it left off without being tombstoned. It depends on memory, etc, but it is simply a benefit to the user who will, in many cases, no longer need to wait for the app to reload its tombstoned state. You as the developer still have to assume you'll be tombstoned.
I am creating a prototype web app using Oracle Weblogic/ADF. I am using JDeveloper 11.1.1.6.0.
I have a basic application with one entity object and one view object. One of the requirements I is that once data is changed it must be digitally signed. I am using a applet/servlet based solution to get this done.
Once a user decides to edit an entry in the table they are taken to a page that shows a two-column form layout. On this page is a button that, when clicked, brings up an ADF dialog window. On this page there is a button called "Sign". Once the user clicks the "Sign" button some JavaScript executes that communicates with the embedded applet. This embedded applet in turn communicates with a servlet and returns a string representing a signature. This process is task-flow based.
The issue I am having is that for SOME users (IE 8, Win 7 Enterprise) once they click the "Sign" button on the popup they are shown the following popup:
If they click "OK", the page reloads and when they click "Sign" again the process repeats resulting in a loop. Initially I thought the alert was coming from IE, but upon further research it seems that the alert is coming from ADF. I have NO idea WHY they are getting this message as there are NO dependent dialogs. I have tried setting the "uncommitted data warning" to off for the document but I still get the same popup. Also the message ONLY appears for SOME users running IE 8 on top of Windows 7.
Does anyone have any ideas as to how to get this popup to stop and/or WHY it is happening?
ANY help would be greatly appreciated as I am stumped.
Thanks.
disable the uncommitted data warning property on af:document
http://docs.oracle.com/cd/E23943_01/apirefs.1111/e12419/tagdoc/af_document.html
Frank
Is it allowed by Windows Phone application certification rules, to only have users be able to return to a previous screen with the use of a hardware back button?
In my scenario, a user clicks on a setting button and lands at a settings page. He changes settings if he decides to, and all the changes get saved automatically, like in iOS.
But currently, the only way for the user to get out of the settings screen, is to press a hardware Back button on the phone.
Will such implementation of navigation functionality pass the Windows Phone certification?
Yes - leave the back button as the navigation method to get back to your main page after visiting the settings page. Not only is this allowed, but it is the desired method of back navigation, and it is what Windows Phone users expect. Here is a great article on the subject: http://blogs.msdn.com/b/ptorr/archive/2011/10/06/back-means-back-not-forwards-not-sideways-but-back.aspx
As far as I understand the terms of the navigation guideline is your usage the right way to go.
Back button
Pressing the back button from the first screen of an application must exit the application.
Pressing the back button must return the application to the previous page.
If the current page displays a context menu or a dialog, the pressing the Back button must close the menu or dialog and cancel the
backward navigation to the previous page.
You should only implement back button behaviors that navigate back or dismiss context menus or modal dialog boxes. All other
implementations are prohibited.
See this cheat sheet for more informations on the design guidelines.
I'm reading the following sumission requirement:
To maintain a consistent user experience, the Back button must only be used for backwards navigation in the application.
a. Pressing the Back button from the first screen of an application must exit the application.
b. Pressing the Back button must return the application to the previous page.
c. If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and cancel the backward navigation to the previous page.
d. For games, when the Back button is pressed during gameplay, the game can choose to present a pause context menu or dialog or navigate the user to the prior menu screen. Pressing the Back button again while in a paused context menu or dialog closes the menu or dialog.
My application require LogIn the first time, before entering its MainPage.
The login data will not be asked again (the user can change account from the settings).
I would like to avoid user entering again in the login page by using the backstack.
Pressing back from MainPage will exit the application.
In particular I'm worried about:
a. I show as a first screen the login page which will navigate to the mainpage, but I'm exiting the app with a back from the mainpage
b. I'm skipping a page, so pressing back is not strictly going to the previouspage
Do you think it will satisfy the certification requirements ?
Thanks
This scenario is allowed, what you should do is:
upon entering the MainPage (OnNavigatedTo) - remove one page from the back stack:
NavigationService.RemoveBackEntry();
Read this thread on the Windows Phone forum
The most important part appears to be that you should never disable the back button but I do think that according to this thread that it is allowed to skip the login screen.
On the other hand you might want to rethink the flow of the application when you consider thombstoning and re-activating; should the user login again and what would a natural flow be?
I am facing some issues in WP7 tombstoning. My issue is application hangs when i try for a sudden tombstone and come back. ie, After loading the page i press device menu button and with in seconds i pressed back button( Pressed Back button before the actual page disappeared) In that time the page loads but the application hangs / its back key press is not working. and if we try for a slow thombstone it is working perfectly. And the pretty interesting thing is that, while tombstoning the loaded and unloaded events of APP working perfectly. Please any one help me to solve this issue.
It sounds like your App has been deactivated, but not tombstoned. This results in neither the App or Page contrusctor being called, causing your app to act in unexpected ways. I highly recommend reading the Windows Phone Silverlight Application Life Cycle document. The relevant extract for said article:
This case can occur if the user
presses the Start and Back buttons on
the phone in quick succession. In this
case, the application received a
Deactivate event and the system was
starting to save the state of the
application to perform an application
tombstone. Before this operation is
completed, the app Activated event is
received. The system knows that the
application was not removed from
memory, so the flow of execution is
different. Specifically:
• The app constructor is not called.
• The page constructor is not called.
The only way for the application to determine
if this condition has occurred is to
set a flag to indicate if the page
constructor has been called. If you
notice in the above section, this flag
was set in the page constructor, and
cleared in the OnNavigateFrom event.
In this case, we will receive the
OnNavigatedTo event, but we will see
that the page constructor was not
called. This tells us that our
application was not tombstoned.