What does event OnSuspending in App.xaml.cs mean? I suppose this event is fired when we change Metro to Desktop or change metro application but what is done with app memory? Is it freed, saved somewhere or it is kept until OS exhausted memory? What steps I have to do as a programmer to keep application working after resuming? What do I need to save?
From your applications point of view, the suspend is somewhat like the 'pause' option of the debugger. Execution is completely stopped and the OS has the option to either resume the app at a later point or shut it down for good.
In the first scenario, your app will not have a clue about the meantime. In case it is shut down by the OS, on the next start the previous execution state will be set to 'terminated' so you should restore the app as it was when you received the 'suspend' event.
Related
I've been dealing with a fault found during testing that I can't seem to get to the bottom of. I have a Windows 8.1 application running on a laptop on Windows 10. The user was using the application, left the laptop for a couple of hours, when they came back the application had disappeared and had lost the data that hadn't yet been saved. This has happened twice on the same machine.
Digging through the Event Viewer on the machine, it appears the following scenario happened:
Application was started
Device went into suspend
Device resumed
During the resume process, the following event appeared in the Event Log:
Package XXX+App was terminated because it took too long to suspend.
Running through the suspend mode using the Visual Studio tools it seems to take around 300ms to run the code that saves the current state.
I don't understand why the application would be suspending while the device itself was resuming. Could this be a case of the app suspend started before the device suspended, and when the device resumed it decided it'd had long enough? In which case what is the correct way to handle this?
Or is this something completely different? I'm not certain where to go with this and can't seem to find any documentation that covers the app suspend/resume in conjunction with a device suspend/resume.
Thanks
I am developing a WP8.1 app in which I need to get the time when app terminated so that when it's launched again I can take decisions according to my requirements. But for this I'm unable to find the any kind of termination event for app where I can store the time of app termination. I have searched and have found Windows Phone 8.1 App Life Cycle which shows there is no event for termination. So my question is how can I record the time of app termination?
You can handle the suspension of the application, when it is brought to the background, and record that time. It is the time when the user last used your app, so when it is started again, you can check how much time has elapsed since last use.
For the actual termination you do not receive an event, nor it is a way to handle such event, because all processing in the application is stopped when suspended and no code can execute.
I have a personal WinRT app I'm working on, and when the app is suspended, I would like to have it relaunch itself with different launch parameters.
I know you can kind of already do this with toast notifications, but I would like to know if it's possible to do without any user interactions.
Thanks!
Wow. I never thought of this before. Your only hope would have been to re-launch your application during the suspending event using protocol activation. But what happens is it is not re-launched, it is reactivated while in the suspending state and the activation is denied. You can't delay the re-activation either because all thread schedules are suspended once the app is terminated, too. I tried this in a test app just now and I'm right.
There's also no option with somehow triggering a background task. Though the ApplicationTrigger is coming with Windows 10, the rule still remains that a background task cannot invoke any UI. So, you can't use a background task.
Then I thought about file activation. Then I realized that file activation is identical to protocol activation and the result would be the same, too.
Yes, the idea of using a timed toast or scheduled reminder would sort of work. It would certainly require the user to tap the toast, and if toast were disabled, or the user didn't tap them (they are transient), you are left not running and nothing going to start you.
There is one more thing you can do. Since there isn't a WinRT solution here, remember there's almost always a Win32 solution. There is nothing wrong with a Win32 in-memory app listening for your app to be terminated and starting it again (like by using protocol activation). Your problem is solved unless you are running this on an ARM device - hopefully not.
I talk about protocol activation here:
http://blog.jerrynixon.com/2012/10/walkthrough-using-windows-8-custom.html
Best of luck!
I'm working on an app using SharpDX to render DirectX content to a DrawingSurfaceBackgroundGrid in Windows Phone 8.
I've found that, if the app goes out to the photo picker or suspends/resumes through Fast Application Resume, memory utilization will increase by about ~2mb and prior resources will not be reclaimed. This means a DirectX-based app using DrawingSurfaceBackgroundGrid will eventually run out of memory on user-initiated actions.
The leak starts once DrawingSurfaceBackgroundGrid.SetBackgroundContentProvider is invoked with a SurfaceBackgroundContentProvider. I'm using a DrawingSurfaceBackgroundContentProviderNativeBase implementation that has empty method bodies for all abstract members.
An isolated repro can be found here. Repro steps are: build and run the app, click "choose photo", hit the hardware back button, observe memory spike.
Anyone else seeing similar?
This was a bug in SharpDX, which has been resolved in this commit.
In WP8, if we set
ApplicationIdleDetectionMode = IdleDetectionMode.Disabled
the app continues to run even when the screen is locked.
If, for instance, we have a WebBrowser in an app (which is actually active only when the app is in the foreground), and the above property is set as disabled:
Will the WebBrowser continue its execution even when the screen is locked (for example, playing an audio file).
Will the WebBrowser continue its execution even when the app is switched to the background.
Thanks.
As for running under lock screen - yes it should run, you can get more information from MSDN.
As I have tested once, WebBrowser is using BackgroundAudio to play (audio element), so it should also play under lock screen and probably in background (thought you should test it).
When the App goes to dormant state - all its processes are stopped MSDN:
When the user navigates forward, away from an app, after the Deactivated event is raised, the operating system will attempt to put the app 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.
You should also watch out for Certification requirements, when usind AppIdleDetection - point 6.3 – Apps running under a locked screen.