I have a Xamarin Forms app running in AVAudioSessionCategory = Playback mode and it works very nice, background audio is playing and even my timers keep running in the background, which is fine during playback.
How can I ensure that after a user has decided to stop playing audio (either by pressing a button inside of the app or by pressing the pause button on the lock screen) my app will go into a Suspended state and it won't drain the battery?
Is there a way to either force my app to go suspended or a way to verify whether it has?
As a side-note: Hooking the OnSleep method in App.xaml.cs is NOT sufficient because it is being called every time the app goes to the background even if it's playing audio, my timers are running, HTTP calls working, etc.
UPDATE:
Made an interesting discovery today:
Timers keep running running in the background when the app is started from Visual Studio in debug mode (over WiFi).
Timers seem to get suspended automatically by the OS (iOS) when the app enters background in Release mode.
My conclusion is: maybe the entire problem lies somewhere in the 'framework' that is added to the app by Xamarin to ensure communication between Visual Studio and the app? (Console, breakpoints, etc.) It would be a logical explanation.
Related
Our android app saves state before it is killed via (Activity::OnSaveInstanceState).
The works well if the app is back grounded before being killed. (which one has to do before explicitly closing an app android)
However on ChromeOS, android apps can be killed without back grounding them.
Apps have an 'x' in the top right corner, which closes the app without back grounding it.
If the app is ended this way, OnSaveInstanceState doesn't appear to run (or perhaps it doesn't have enough time to finish?), and so the app state isn't saved.
Q: Is there away to either:
Disable/hide this 'x' for the android app?
Save state even if the app is ended this way.
Note: android apps on chrome also have 'back arrow' (not shown in this screen shot - top left on the toolbar), which closes the app. State is saved as expected, when app is closed that way.
Don't save state in Activity::OnSaveInstanceState use Activity::OnPause instead.
After setting up debugging from Visual Studio for the ChromeBook, I confirmed that Activity::OnSaveInstanceState is not being called, when clicking on the 'x', (like it is when one backgrounds an android app, then explicitly close it
However Activity::OnPause and Activity::OnDestroy are called.
Despite its name and contrary to lots of advice, it seems that it's not safe to save state in Activity::OnSaveInstanceState
Moved state saving to Activity::OnPause works for me.
Is there a way to know if the app is sent to background or brought to foreground. I don't mean Suspended and Resuming events.
For example, user leaves the app to check something on Facebook app for a min. And then return to back to my app. So suspention doesn't take effect on this scenario. Then how to know user is back to the app on app.cs level?
As stated in the MSDN documentation:
Your app doesn't receive an activation event when app visibility changes, because the app is still running. Windows simply switches to and from the app as necessary. If your app needs to do something when the user switches away and back, it can handle the visibilitychange event (for HTML) or Window.VisibilityChanged event (for XAML).
My Windows Phone XNA game calls Guide.BeginShowKeyboardInput to get the user's name. While the Guide's input screen is shown, if the user presses the Home or Search (hardware) buttons, the game is deactivated as usual - but if the user then presses the Back (hardware) button, the game should resume but it doesn't. Instead it shows the "Resuming..." message until Windows Phone gives up trying to resume the game and kills the process.
Please note:
My app is failing Microsoft certification because of this problem - I really need to fix it!
This only happens in my game when the Guide input screen is shown - when it's not shown, the game
resumes properly after being deactivated.
This problem only occurs when the game is run on WP7.x (verified problem on WP7.5 and
WP7.8) - although the game seems to resume properly on WP8 devices.
I've created a blank XNA game project, called Guide.BeginShowKeyboardInput and tested it using WP7.x devices, and this problem-behavior doesn't occur.
I've tested the game without enabling Music & my Trial License manager (they use timers) and it still does this.
Exact same behavior occurs in the emulator (resume-failure on WP7.x emulators, works fine on WP8
emulator)
I used threads to asynchronously download content during the loading screen - but they already completed and exited.
I don't believe other threads are running, although this seems like
it could be a thread-blocking issue.
Any other ideas on what could be blocking the game from resuming when the Guide.IsVisible or how to debug/resolve this problem?
The solution to this issue was simply to NOT use SuppressDraw when dealing with any operation that passes control outside of the app, e.g. Launchers, Choosers and the Guide.
Have you tried calling "Guide.EndShowKeyboardInput" in either the Deactivating or closing events?
So that the guide is closed before the app suspends, you do get 10 seconds to suspend so this might be worth looking into.
If you want the guide to re-show on resume, then in your state saving code just have a flag and open the guide if it's set.
I have this issue when debugging mobile apps on the emulator. When I press F5, the build starts, then the deploy, then the app pops up in the emulator.
Because this takes a minute or 2, I am checking my SO score and maybe ask a question while I wait, and the emulator is in the background. When I finally switch back to the emulator, it shows the start page, not my app.
I figured out that by pressing the back button I can bring the debugged application to the foreground, but still, I don't know what is pushing it into the background to begin with. Has anybody noticed this, and found a way to prevent it?
The default behavior in WinMo is that if the device has no activity for a certain period of time (set in Settings->Today->Items->Today Timeout), the Today screen will come to the fore. Check to see if that's what's happening (though I think the smallest interval is still larger than a couple minutes).
Is it possible to emulate a device sleeping and waking using the Microsoft-supplied device emulators?
Yes, but you have to generate your own emulator image with a modified kernel (changing OEMPowerOff). Bruce Eitman blogged about it here. You didn't detail your needs, so it's hard to say, but you might be able to provide some form of simulation by manually setting the named power management events.
This is an old thread, but in case anyone else stumbles across it, you can make the Windows Mobile emulators 'sleep' and wake up, though not with the debugger attached.
Close the emulator window while your application is running and save the state. Or, configure power management to sleep the emulator at the desired time; the emulator will close and save its state automatically. If the debugger is attached, it will lose its connection and stop debugging.
Open Device Emulator Manager and click Refresh until the emulator shows up as disconnected (no icon next to it). Right-click on the emulator name and select Connect.
Emulator wakes up and reappears. If your application is listening for the wake-up notification, it will be signaled at this point.
You can also wake up the emulator using Debug > Attach to Process, though this does not always succeed. Either way, by the time the debugger attaches, the wake up sequence will already have executed. If you can get by with debug statements, though, this is easier than modding the emulator image.