I want to get event when windows store app is closing or page is closing same way as we get "Closing" event in Desktop application.
Can anybody suggest me?
Try this:- https://msdn.microsoft.com/en-us/library/windows/apps/hh986968.aspx
refer:- How to save data on Windows Store App Close?
If you look at the very first figure, you can see that there are only 3 events related to application lifecycle:
Activated - Raised when program first starts
Suspended - Raised when program is suspended (i.e. the user returns to the Start Screen or another app)
Resuming - Raised when the program is awakened from its suspended state.
The fourth transition - the one to the "Not Running" state - has no such notification event. The reason is: you don't really know when the app will fully close. Nor should you - Microsoft wants you to perform all of your state-saving logic in the transition from "Running" to "Suspended." In this way, they can free up resources when they deem necessary.
Even if the user forces the program to terminate (by right-clicking it and selecting "Close" from the task menu), you will enter the "Suspended" state for exactly 10 seconds before the program is terminated. So you can rest easy that your state-saving logic will always be executed.
Related
I'm writing a program that monitors state. It launches main window (LoginForm) to ask for user credentials, then hides the form. After that LoginForm inits NotifyIcon and all the remaining work is being done with LoginForm hidden. I've implemented all the clean-up work in FormClosing event of LoginForm. During normal exit process everything works perfectly.
The problem is that the program sits in tray all the time and I tend to forget to exit it before shutting down windows - program doesn't save the state on shutdown event.
I've read through many forums and docs, and from what I've read events FormClosing/FormClosed + SessionEnding/SessionEnded must fire anyway. But it looks like they just don't fire. Can't even cancel shutdown in SessionEnding (with stupid e.Cancel=true) - program disappears without reaching the place.
I've made myself a small debugging library to write out debug information into a file with instant flashing of cache. I've added debug messages to all the events. When I try to log off user in Windows (same as shutting down) for a test - I see no events being triggered usually, just the program vanishes. No exceptions I could catch, no events, etc. When exitting program manually or through "taskkill /IM " - I see all the expected debug printout. What's even more interesting - sometimes the program does reach closing events and does proper clean-up job during Windows shutdown.
Wasted a few days on this already. Overriden WndProc as suggested in MS article - program doesn't reach WndProc as well (to ensure it comes first before closing the form). Tried instead of FormClosing event to override OnClosing of LoginForm - no luck. Added UnhandledException handler, Microsoft.Win32.SessionEnding, Microsoft.Win32.SessionEnded, Form.FormClosing, Form.FormClosed event handlers - no luck.
I suspect this is either a problem of hidden forms or that some kind of exception is happening during shutdown only (resources disposed?). How can I find why that's happening? Is there some simple way to simulate Windows shutdown for single application to make debugging in VS possible? I've tried RMTool - for some reason it fails to simulate shutdown and program just ignores it.
Update: Program uses System.Timers.Timer to regularly poll server for any changes.
I've done some research into this, basically, after Windows XP they altered the way that shutdowns were handled.
You cannot block or capture the shutdown event reliably using the form_closing events etc.
You must use a new API to do so. There is a complete example here: http://bartdesmet.net/blogs/bart/archive/2006/10/25/Windows-Vista-2D00-ShutdownBlockReasonCreate-in-C_2300_.aspx
You should be able to call the function to block shutting down (display a message such as 'saving changes...') and then save and exit your application in the background. Once your program quits, it should allow windows to continue shutting down.
I think windows is simply configured to automatically shutdown all applications regardless and hence the application has no chance to catch SessionEnding events and so on : have a look at http://www.addictivetips.com/windows-tips/disable-automatic-termination-of-applications-during-shutdown-in-windows-7/ or check your configuration at Computer Configurations > Administrative Templates > System > Shutdown Options.
I'm working with background tasks.
If I press the home button once the app will call DidEnterBackground and I can run anything here - Ok
If I press the home button twice and swipe the application out of the screen, finalizing it, WillTerminate will be called and after that, the app DIED, I can't do anything more.
On the Android I can do it and keep the app running, without show it on the android's app switcher.
There's a way to do it?
And how I re-open the app every time I kill the app (Every time WillTerminate is called).
You cannot avoid the kill by the user. Apple philosophy is that the user is the "commander-in-chief" and he can decide to kill your app when he wants (and the kill must be real, no hidden processes).
All background tasks of the app will terminate with it and you cannot reverse the user decision (i.e. restarting automatically).
I don't see simple solution for your problem. The only thing that I can think is to put a big alert message to the user, when a specific task begins, saying:
"don't kill this app from the switcher while this operation is running ..."
or, save the state of the background process and restart it at the next run of the app.
My WP 8.1 store app behaves very strangely. App Resuming event fires as expected when I quickly navigate away and then come back. But If I keep the app in background for some time and when comes back, the app fires the Constructor and OnNavigatedTo events instead of the Resuming event and has the black "Resuming..." screen for a couple of seconds(about 4 seconds).This is an app with a BackgroundAudio task. Even the sample BackgroundAudio app from MS behaves like this. Anyone knows what's wrong here?
I'm in the process of building a WP 8.1 app which uses a background audio task as well. Everything you explained happens to me also.
If you see "Resuming..." for a few seconds, then it probably means your app was terminated by the OS after being suspended first. In this case, the Resuming event won't fire because your app was completely killed and must start again. "Resuming" usually means when a suspended (not terminated) app resumes execution.
When your app is terminated and then "resumed" from the app switcher, your Application.OnLaunched() method override will be invoked with e.PreviousExecutionState == ApplicationExecutionState.Terminated. In this method, you should check if the previous execution state was Terminated, and if so, restore the app to the state it was in prior to suspension. This gives the illusion to the user that the app was never terminated and they can resume what they were doing at the time.
If you create a new Pivot App Windows Phone 8.1 project (for example), you'll see that the application lifecycle events are taken care of correctly in App.xaml.cs.
App Resuming event fires as expected when I quickly navigate away and then come back.
This is correct behavior. It takes a few seconds once the app has been backgrounded before it is suspended by the OS, so if you resume the app before the OS has suspended it, then it will simply resume from memory.
I'm not sure why background audio apps are more susceptible to termination. I even find that the Xbox Music app behaves similarly. Hopefully in the next version of Windows Phone, this issue will be addressed.
FYI here's a diagram of the application lifecycle from MSDN (I recommend you read this page for more information about the application lifecycle):
"Resuming" only occurs from the suspended to running states.
Whenever the app resumes from the background. there are two states it can be in:
Suspended: it resumes successfully, navigating directly to OnNavigatedTo; the constructor will not be called
Terminated: the app will not start from the previous state of the page you left, but instead, it will load that page anew; at this point of time you need to have saved the state while the app was suspending, so as to restore it now
i have the following problem. When the user closes the Windows store app, i want a text file with data to be saved.
What method should i write so that when closing the app a file gets saved ?
This article describes the application lifecycle of a Windows Store App.
If you look at the very first figure, you can see that there are only 3 events related to application lifecycle:
Activated - Raised when program first starts
Suspended - Raised when program is suspended (i.e. the user returns to the Start Screen or another app)
Resuming - Raised when the program is awakened from its suspended state.
The fourth transition - the one to the "Not Running" state - has no such notification event. The reason is: you don't really know when the app will fully close. Nor should you - Microsoft wants you to perform all of your state-saving logic in the transition from "Running" to "Suspended." In this way, they can free up resources when they deem necessary.
Even if the user forces the program to terminate (by right-clicking it and selecting "Close" from the task menu), you will enter the "Suspended" state for exactly 10 seconds before the program is terminated. So you can rest easy that your state-saving logic will always be executed.
you don't really know when the app will fully close. Nor should you...
I don't agree with this - Microsoft are copying this from Apple, and I don't know why, I never liked Apple's implementation either.
If your user makes changes to your App, then closes it using the keyboard or gesture, then restarts it say after 6 seconds, all changes are lost.
I don't see any way as a developer to get around this. Whoever decided that closed events (and exit buttons for that matter) are evil is an idiot.
I have a WP7 app that sometimes has to make a long (5-25 sec) processing.
With Mango, when the app is set to Dormant state while it was processing (ex: the user presses the Windows button or locks the screen), when the user comes back, the app crashes.
I tried on the emulator and on my device, same behavior.
If I reproduce it in debug mode on Visual Studio, it doesn't crash so it's hard to find what is really happening.
To reproduce it, start a new Windows Phone project, add a button on MainPage.xaml & add an event handler on the click event that executes an infinite loop:
while (true)
{
System.Threading.Thread.Sleep(100);
}
My question is: What is really happening? Why does it crash? Isn't fast app switching supposed to just pause the app process and resume it?
EDIT:
Another thing I noticed is that when running the heavy process, the deactivated & activated events do not seem to be raised when I get out/in the app.
Found the answer on the official Windows Phone forum (link). Here it is:
Why it crashes:
From the time the app is deactivated, it has exactly ten seconds to
finish up what it is doing. If the code takes more than ten seconds,
the OS will terminate the app.
Why the deactivated & activated events are not raised when I get out/in the app:
If the process is blocking the UI thread this also blocks the message
dispatch loop so I suspect that this is the reason why your app never
gets a chance to detect and handle the events.
Your problem is simple. WP7 cant really put your threads in a dormant state when you are under heavy processing in this fast time and will save a corrupt state. This state will crash when its reactivated.
It works in the debugger because the debugger makes everything slower and then WP7 has more time.
From Documentation:
When the user navigates forward, away from an application, after the Deactivated event is raised, the operating system will attempt to put the application into a dormant state. In this state, all of the application’s threads are stopped and no processing takes place, but the application remains intact in memory. If the application is reactivated from this state, the application does not need to re-create any state, because it has been preserved.
Source: http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92).aspx