My understanding for Windows 10 Apps Application life-cycle is that when you switch from one App to another, OS puts first App in suspended mode.
I am running several Apps but none of these is in suspended mode (see image below). I was expecting to see few of Apps in Status column here as Suspended. Can someone help me understand what I may be missing here?
Suspended mode means that the application will have very low memory usage, but not zero memory usage. It does not mean they become background tasks either.
Suspension allows developers to save the state of their app. For example, a user switches between 1 UWP (app1) to another (app2). App1 then has 5 seconds to save state of the application.
For a game that might be score and player position. When the user switches back, the app will show the same position of the game instead of restarting or going back to the beginning of the level. However if the user never goes back and opens 50 more applications most machines (especially phones) will terminate longer running tasks to free up memory aka your application. Now when your application is terminated and the user goes back to restart, it will bring back the same state.
This Channel 9 video explains more about it - https://channel9.msdn.com/Series/A-Developers-Guide-to-Windows-10/13
Actually turned out when I minimize the App, it shown as Suspended in the task manager after few seconds.
Related
I'm writing a UAP C#/XAML application, for the time being I'm interested in case when user runs my app in desktop environment (case when keyobard and mouse are available, the machine is running some version of Windows 10 not Windows 10 Mobile).
I want to intercept ALT+F4 in order to ask user a few important questions before they quit, like in for example notepad - when you have unsaved file and the notepad notifies you about this fact and asks if you want to save your work, quit without saving or go back to working with your file.
Is such a behaviour possible in Windows 10 UAP? I tried to play with Application.Suspending event and ExtendedExecutionSession, but it seems like before this event is fired the GUI thread is dead, and all I can do in this event's handler are operations not requiring user interaction.
There is no way to intercept and stop events like this.
By the time your app is told it is suspending following a close event (alt+f4, cross clicked) you have 10 seconds (on desktop) to clear up and save state before you are completely terminated.
With universal apps, you shouldn't need a dialog asking them to save or not, just save state so next time they reopen you refresh the view to how it was before, or, think mail client, save their typings as a draft. The guidance on Microsoft is, however, that if the user closes your app, assume they want you gone so don't restore state.
The only thing you can do for some extra processing is ask the OS for extended execution, though this isn't guaranteed and even if granted can be revoked with 1s notice to termination. It's important to note that, even with extended execution granted, you app is not allowed any UI.
For more information on Windows 10 universal application lifecycle, I'd recommend watching the Application Lifecycle session on Microsoft Virtual Academy.
We know about relation between Process and Thread.
Thread comes under Process, we can say Process is a container and Thread is an element of a container.
But what about Service ?
I can say Process and Thread having same genre.
Can we say the same thing for Services?
I found Window Services and Android Services having similarity, say in Android if we want to play Media then we have to get getSystemService(Context.AUDIO_SERVICE) likewise in Windows (8) if you stop Windows Audio (audiosrv.dll) services from services.msc then Media will not play.
What is Service?
Windows
A service is an application type that runs in the system background without a user interface and is similar to a UNIX daemon process.
Android A service is a component which runs in the background, without direct interaction with the user.
A service runs by default in the same process in the main thread as the application.
Services which run in the process of the application are sometimes called local services.
With above definition we can say apparently that Service is also a Process (i am not sure, please make me correct)
Let me start with the statement - Service is not a process. It is an activity without GUI
If you start a thread, it runs parallel with your main activity thread. But a Service is not guaranteed to always run in a new thread. So, you cannot call a service similar to Thread.
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
So When to use of a service in your application ?
If your application tells the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it.
Reason - Your application together with all its global variables will not be wiped out as long as there is a Service still running. So if the user is not interacting with your application and some other application in foreground needs more memory and if the OS triggers a low memory warning and your activity is destroyed, still your application is not completely lost as the service is running.
A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it.
How the Application priority is defined based on service ?
If the service is currently executing code in its onCreate(), onStartCommand(), or onDestroy() methods, then the hosting process will be a foreground process to ensure this code can execute without being killed.
If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible.
If there are clients bound to the service, then the service's hosting process is never less important than the most important client.
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory.
Just need to know what to handle for this situation:
Case(1) When user is not doing anything on the screen for a period of time
The system will suspend the app? Is this what causes suspension? This means nothing will be processed in the background?
How to handle this case that I want the process continues when app is left unattended (example : Using GPS )
----- Update
Need some confirmations for the following scenarios:
1) App is launched and user navigates from mainPage to other Page AND left the Tablet alone for a period of time and user did not interact with the Screen.
In this case, this will cause the Physical screen turn to black color screen. Is this means app Suspension or something else?
2) How Lock Screen or Screen Lock work or when it will happen. how different is screenLock from above question(1)? or they are the same thing?
Screen Lock will cause App Suspension?
3) When user presses the home button (Hardware button) on the tablet, this will cause App Suspension or termination?
4) In Windows Phone, there are these to detect and prevent Screen Lock and run the app :
a.The UserIdleDetectionMode property
b.The ApplicationIdleDetectionMode property
Can these be used in WinRT App? or how to handle this like WP in WinRT
If the app is the foreground app and the screen is active, it won't be suspended. Apps get suspended primarily for moving to the background. This wouldn't be just idle time, but could be if something like a lockscreen/screensaver comes on and the window is no longer active.
You could know this immediately by looking at Window.Activated events, but in this case a de-activated window (assuming it was the only and primary one for the app) would likely mean it went to he background and thus in queue for suspend.
And yes, once suspended, no code is running from the app -- if you wanted background code to run you'd need to use a background task (see MSDN samples for an example).
I've read the Apple's documentation about application lifecycle and made some tests to figure out what is the applications life cycle on different devices. (All running iOS 4.x except the 2G)
I've tested "multitasking" capable devices vs some that do not support this feature :
iPhone 2G/3G app lifecycle :
(START)
- didFinishLunchingWithOptions
- applicationDidBecomeActive
(HOME PRESSED)
- applicationDidEnterBackground
- appWillTerminate
iPad / iPhone 4 app lifecycle:
(START)
- didFinishLunchingWithOptions
- applicationDidBecomeActive
(HOME PRESSED)
- appWillResignActive
- appDidEnterBackGround
(RESART app in the "Taskbar")
- appWillEnterForeGround
- appDidBecomeActive
I've tried to kill the App from the "taskbar" but the debugger received a SIGKILL ! What happens when you kill and app in that way ?
When is appWillTerminate called on the "multitasking" capable device ? Are my results correct ?
EDIT:
Quote from apple's doc about appWillTerminate :
For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
What do they mean by "generally not called". " the system needs to terminate it.." means that the method appWillTerminate will be invoked ?
I think you're right. When you kill an app from the taskbar (or when your device is running low on memory and the OS kills the app for you), it just sends a SIGKIL signal. As you note, it never calls any of the callbacks.
According to the documentation:
For applications that support
background execution, this method is
generally not called when the user
quits the application because the
application simply moves to the
background in that case. However, this
method may be called in situations
where the application is running in
the background (not suspended) and the
system needs to terminate it for some
reason.
So, iOS can call the applicationWillTerminate: method but probably won't. (I've never seen it.)
If you want to save any state before your app is killed, you need to do it as it goes into the background.
I am using the 'location' UIBackgroundMode to receive GPS background updates when the user presses the Home button. As a result, if the app is left in background mode overnight, the battery is consistently dead the next morning. I have told the locationManager to stopUpdatingLocation, but to no effect.
I understand Apple doesn't want developers to use exit - in fact it seems to have little effect on the app other than to take it to the background - but I can't afford to have the battery die if the user doesn't end the app.
Any suggestions?
Maybe you could register for a local notification that informs the user they should open the app to stop location tracking? It's not very elegant of course, it seems Apple should allow the developer to register for location updates for a specified length of time, maybe you could submit a feature request for that. I think Loopt monitors for 24 hours and then quits, maybe you could research into how they made it stop after 24 hours. I wish I could help more but I haven't messed with the location framework at all.
You could use a timer and/or background task, which would run after a set amount of idle time, and try to turn off the GPS then. So you can still have location tracking in the background of your app, but after 10-20 minutes, it turns off.