I am trying to understand the application life cycle.
Scenario: I am launching a blank application; after that I am intentionally coming out of that app and opening a separate app. After some time I look at the Task Manager. The blank app appears to be suspended. Then I launch the blank app again (which was in a suspended state). At that moment, it has to hit the resuming event, right?
1) Why is the resuming event not firing? (Resuming event should be fired because the app is coming from the suspended state into the running state.)
2) Why is the OnLaunched event fired?
3) Is the OnLaunched event fired only when the application starts for first time, or also when being activated after termination?
Thanks in advance.
I don't have much experience with Metro apps yet, but I'll try to answer:
Ad 1) If your application went from the Suspended to Running state (as in diagram in this MSDN article on Metro Application Lifecycle), resuming event should actually fire. I made a few tests in similar scenario and it did. And btw, here's the best description of this event I found:
When an app is resumed from the Suspended state, it enters the Running state and continues from where it was when it was suspended. No application data is lost, as it was stored in memory. Therefore, most apps don't need to do anything when they are resumed. However, the app could have been suspended for hours or even days. So if your app has content or network connections that may have gone stale, these should be refreshed when the app resumes.
Ad 3) Launch for what I understand is just a special kind of Activation (one of the possible entry points to application), which corresponds to transition from Not running->Running. Some quotes:
When an app is activated, for any reason, the system sends the
Activated event.
and
When the user switches to your terminated app, the system sends the
Activated event, with Kind set to Launch and PreviousExecutionState
set to Terminated or ClosedByUser. The app should load its saved
application data and refresh its displayed content.
Ad 2) If OnLaunched was executed and Resuming event wasn't fired, my guess is your app was in 'Not Running state', e.g. it was terminated by the system (Suspended->Not Running) before you re-launched it. I don't know why task manager might have not refreshed this information.
I can answer this one:
1) but why the resuming event is not firing ? (resuming event needs to fired because the app is coming from suspended state to running state )
There is a debug button available for you to force your app into suspended state. In the quick-search of visual studio search for "debug location". This is a debug toolbar that you tap on the "suspend" button when you are debugging. Once you go back into your app (give it acouple seconds before you go back in) then you should get the resuming event fired.
ResumeEvent is not firing because you opened the app from the start screen or from its pinned tile. In that scenario, the app is treated as having been launched again. That's why the OnLaunched event was executed and not ResumeEvent.
To make sure ResumeEvent is fired, wait for 10 seconds after switching to other app, and then go to the top-left corner and bring the app back to the foreground. Make sure to wait the 10 seconds, before then Windows treats the app as running.
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.
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).
I am having a few problems getting my Windows Phone 7 app-specific Reminders to work properly - the app re-closes after a fraction of a second after starting to show the splash-screen.
In order to debug this, I'd like to know how a Reminder launches an app, which events are fired and so on.
For what it might be worth - here is what I found out.
A Reminder restarts the app, triggering the Launching-event in App.xaml.cs. That is - you need to re-load anything you need to make the app work from Isolated Storage or the web
When the Launching event is done with, the app goes straight to the requested view - skipping any loading-page you might have made for your app. Again, remember to load whatever resources you need from Isolated Storage.
Then the app fires the view's constructor, before OnNavigatedTo and Loaded goes off.
Is it possible to run multiple instances of same application on Windows Phone 7.5 ? When I deactivate current instance and try to run a new instance via Start menu, the backround app disappears, and the new one starts in foreground with initial screen.
Is Application State preserved between such "restart" ?
No, it’s not possible to run multiple instances of an application in WP. When you start the application as you describe it counts as a restart of the application and no state is saved. Have a look at http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92).aspx for detailed information.
When you start an instance of your app and then deactivate it (by using the Start button), you have the chance to save the app state (there are Deactivated events you can you for this)
So, when a new instance is launched from the menu, the previous instance of the app gets killed and you can at this point just reload the previous saved state (if any!)
Each app can only have one instance as far as I know (from my experience so far).
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.