What is a reliable (and immediately) way to detect if a user has closed the app with ALT-F4 or the close-gesture?
相关问题
- Inheritance impossible in Windows Runtime Componen
- Programmatically read target platform during run t
- Replacing or recreating a file in Windows 8 RT kee
- Draw waveform from MP3 stream in C# on WinRT
- how to disable caching HTTP GET in metro app, I am
相关文章
- Windows 8.1 How to fix this obsolete code?
- Show flyout using BottomAppBar
- Get English exception message instead of local lan
- How to remove an element from an IGrouping
- Exception when reading text from the file using Fi
- HttpUtility.HtmlDecode in WinRT
- Building Windows 8 Metro App on Windows 7 with Vis
- Loading Loose Xaml with custom controls on WinRT f
According to the Application Lifecycle documentation there is no way to detect this event (See the section under "App close"). This type of state can be managed best using the ApplicationData class.
Not really an exact answer to my specific question, but a way which solved my concrete problem for which I posted my question. Maybe it helps someone else:
Register to
Window.CoreWindow.VisibilityChanged
:If the visibility has changed to false, this may be due to the closing of the app. Take care, the event will also fire for many other reasons, such as window changes via ALT-Tab:
Please note: I suspect that MS has explicitely not provided an event which I was looking for, because heavy operations exactly at the moment the user closes the app will result in a less fluid user experience. However I think there are eligible cases where such an event makes sense and therefore people will use workarounds such as the one I provide here. If you use this or another workaround, take care to not create heavy load to the system.
There are no doubt scenarios where you don't want to save state all the time in case the app is suspended. Wouldn't this be called "polling" (which is kinda bad and wasteful in other ways)? In my scenario, I have a timer that tracks time remaining, which is part of the state of the app, but I don't want to store this on every tick.
So, to do this properly, you'll need to:
To elaborate more on #3 above - I found that if I navigated forward from A -> B, then back to A, then to B again, I would end up with another cached page B hanging around. Then when the user left the app, I would get multiple VisibilityChanged events fired, some of these including old cached pages that I thought would have been destroyed but were not.
Here's the code that worked for me: