I want to know what, how, and the limitations of the work that can be done whilst an app is suspended.
I'm not talking about Background Tasks, since those run whether the app is suspended or not, but what you can do while the app is in the background, suspended.
What I noticed so far is that if I have a BackgroundTask with the Completed event attached in the MainApp, that trigger is fired whilst the app is suspended, meaning that I can in fact do work in the MainApp, with the app suspended. So far I only have two ways of doing that, one is by using a BackgroundTask Completed event, and the other is by having a timer that forces something to happen.
However, what, how and the limitations of what I can do with the suspended app are not clear to me.
So, is there another way of working with a suspended app? And how much CPU time do I have, if limited, to work with?
I have played around a bit and found out that MessageWebSocket, if not disposed on app suspension, can still receive messages.
You could use the open socket connection to send messages, based on which you can execute code in the background.
A problem is when your app gets terminated by the OS (when the device does not have enough memory), then the socket connection will be closed too.
For more info on how to implement sockets see here.
You should check this link.
Understanding the App’s Lifecycle and Managing State - By Bob Tabor
Here its shown how you can manage to save the state of the app if your app is being suspended using suspension manager and also how to save data if the app is terminated from the suspension state.
Bob Tabor has clearly explained this in detail.
It was helpful to me, hope this helps you.
Related
I decided to run a test on the XCode iOS simulator to see if an observer to a location in the Firebase database would continue to fire even when the app is in the background. Turns out it does, but I am wondering if this is indefinite until the app terminates or if it will actually stop after some time. It's been a very long time and the observers still fires whenever I manually update the value in the database that the observer is looking at. Also note that I don't have any background modes enabled in my app's capabilities, so it seems that the observer can persist in background mode despite no explicit background modes of any kind.
On the one hand I am very glad that the observer stays on in background as this is helpful to me, but I am a bit anxious to know why this is allowed to happen as iPhone is generally quite conservative by default when it comes to doing stuff in the background.
While the listener may stay active in your single test case, you should not rely on Firebase Database listeners for background data delivery.
The listener stays active as long as the connection stays open. It is up to the operating system to determine when it closes the connection. There is a good chance that the iOS emulator has different behavior in this case than a physical device would have.
I have a UWP app that needs to check for new data (from network) every x seconds. I do this by starting a new async thread. The app can be minimized or even navigated from in Windows Phone, and this suspends the app.
How do I restore the loop when the user goes back to the app again (it appears to be still open, at the same Page)? This can be done either by re-navigating to the Page in question on relaunch or by restoring the loop. What's the easiest way to do so?
Generally when your app is suspended, if you don't cancel your tasks, the OS will do it. Therefore it's recommended that you will send a suitable signal to your tasks along with saving some progress for resuming operation.
However, in UWP there is something like ExtendedExecution - it should allow your app to run in background up to 10 minutes (as far as I know this is the limit for battery powered devices - not 100% sure about this, and it of course may change on various scenarios).
Nevertheless, I think that checking for changes in few seconds interval may be a bad idea. Maybe you can change the design little and use BackgroundTasks which are designed for background processing.
Most of information about app states you will find at MSDN.
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've posted previously about synchronisation issues with my background scheduled task having to access a SQLite DB and IsolatedStorge that the foreground app uses.
To simplify the process I thought about just preventing my background task from running altogther, it isn't imperative that it runs, especially when the foreground app is active.
Is there a way to do this?
I thought about using IsolatedStorage to set a flag when the app launches then remove it when it exits, then have the background task check the setting, protected by mutex.
I think the idea is fine in principle, but I guess there will be times when the flag isn't unset, for example if the battery dies... Which means potentially, after turning the phone on, if the user never uses the app and exits properly, the background task will never run. This might not be too much of an issue.
Is using some kind of flag like this the only way to achieve such functionality?
Thanks
There is an inter process communication mechanism to achieve this functionality.
As both the foreground app and scheduletask run as different processes, IPC could be used for it.
Please refer to Named Events.
In your OnInvoke Method subscribe for a named event which will be fired by your foreground app as soon as it is launched/resumed.
As soon as you get a signal via this event in background agent, just call NotifyComplete and you are done.
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