I want to test out whether fast application switching is working in Mango. I start the app from the IDE, it kicks off the emulator. I then move away from the application (by clicking the Windows button on the emulator). Then I go back into the application from the phone.
However, the IDE loses connection to the emulator and I can't debug what happens when the app is reactivated.
Is there a way to do it?
My debug session seems to continue working. I started debugging an app, tap the start button on the emulator, which took me back to the start screen, then I hit the back button on the emulator, my app came back, and I hit a button where a break point was inserted, and I hit the break point. Is this the order you're doing things in with the emulator?
Just to be sure, I just did the same with using tap/hold on the back button, and it worked as well.
Related
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.
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.
I am developing a GUI application in Qt 4.8.4 with Visual Studio 2010. I need to perform some cleanup work before my application closes so I have reimplemented the QWidget closeEvent in my MainWindow class to capture when the user either clicks X or when they select File->Exit from the menu. That works fine. The problem however is when I am running the application in the VS debugger and I use the debugger to shut down the application the close event doesn't get triggered. I can always just shutdown my application by clicking File->Exit or clicking X but sometimes I forget and shut down the debugger instead so it's really more of an annoyance. Is there a way to capture when the debugger shuts down my application?
Not that I know of.
The logic of it: the debugger is running a sandbox, and when it shuts down, the sandbox gets freed. Your application is running inside that sandbox - so when that sandbox gets freed/closed/destroyed, your app simply vanishes without any cleanup.
I have a simple Windows Phone 7 application which is working perfectly when started from Visual Studio. However, if I deactivate the app (press Windows button or back button from the application's MainPage) and then click the app's icon to relaunch, the screen will flash and return to the list/home screen. I assumed this was an issue with the emulator but when I got a developer device I have the same issue.
Note that reactivating without a complete tombstone works (pressing Windows button from the app and then back).
I have no idea what causes this or how to proceed with debugging. Hopefully someone else has experienced this and knows a fix.
Turns out there is a bug, i found the solution here http://forums.create.msdn.com/forums/p/67522/416995.aspx
In short, it turns out that the Microsoft.Xna.Framework.Media.MediaLibrary class (which I am using to display pictures on applications main page) is not properly initialized when the user has not opened a media hub prior to you calling it. So picture collection properties are null or empty. The solution is to add a call to MediaPlayer.Queue.ToString(), it will force the initialization of the native media library allowing you to invoke the MediaLibrary later on.
Sounds like an unhandled error on startup is causing the app to crash.
Trap/log/handle/display any unhandled exceptions. Also check what you're doing on startup.
IF you are saving something (to Isolated Storage) after first run and then opening it on subsequent launches then that's where I'd look first.
If it works when launched from Visual Studio then this will probably be due to the way you are rebuilding/redeploying the app before launching it in that case.
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).