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).
Related
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.
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.
I am new to mobile website development, and facing this issue where I want to refresh data on the website in every 30 sec which is invoked from the client side and server provides the data in response. Problem is when I close the browser or when the browser goes in background it stops working. Is there any thing we can do to make this thing possible?
Have a look at the Android Developers - Processes and Threads guide. You'll get a deeper introduction to how process life-cycles work and what the difference is between the states for background- and foreground processes.
You could embed your web app in a WebView. This way you could deal with the closing browser case: you could provide a means to "exit" the app that involves closing only your container activity. That way the timers you have registered in javascript will still be running in the 'WebViewCoreThread'. This is an undesirable behavior and a source of problems, but you can take advantage of it if you want (just make sure you don't run UI-related code there). I've never tested this in Kit Kat (which uses a different WebView based on Chrome) but works for previous versions, as I described here.
Now the user can always close any app. Even without user interaction, the OS can kill your app on low memory. So just give up on long-running apps that never end, because the OS is designed in such a way this is simply not possible.
You could go native and schedule Alarms using the AlarmManager.
Just checked this out on the Android KitKat WebView and as per Mister Smith's comments the javascript will continue executing in the background until the Activity is killed off:
Just tested with this running in a WebView:
http://jsbin.com/EwEjIyaY/3/edit
My gut instinct is that if the user has moved your application into the background, there seems little value in performing updates every 30 seconds, it makes more sense to just start updating again once the user opens the device up and cache what information you currently have available to you.
As far as Chrome for Android goes the same is happening, as Chrome falls into the background the javascript is still running.
If you are experiencing different behaviour then what exactly are you seeing and can you give us 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.