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.
Related
I have troubles using ExtendedExecutionSession in Windows 10 UAP.
First, it seems that ExtendedExecutionSession.RequestExtensionAsync only returns Allowed if it is called from the app Suspending event handler. If it is called outside this event handler the method returns Denied.
Second, most critical problem. My app executes downloads. If any download is in progress I request ExtendedExecutionSession to allow downloads to complete. What I found at least on Windows 10 mobile though is ExtendedExecutionSession is allowed in app on suspend but downloads seem to freeze. Nothing is downloaded while app is in background and when app is resumed downloads appear frozen with no data transferred.
Here is the MSDN guidance for Extended Execution: https://learn.microsoft.com/en-us/windows/uwp/launch-resume/run-minimized-with-extended-execution
SavingData is the only type of Extended Execution Reason that can be used in the Suspending state. Note that this is specifically for saving critical user data locally that will be lost once the process is removed from memory.
It sounds like you should use the Unspecified Extended Execution if you need to accomplish something when your app is running and in the foreground. It will be revoked if the user decides to close the app before the download operation completes. Like was previously suggested, a background transfer or use of the ApplicationTrigger or MaintenanceTrigger may be better options for these downloads if you want them to continue after your app has been closed.
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 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 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.
How do you disable closing an application when it is not responding and just wait till it recovers back?
What you're asking is not just impossible (any user with sufficient priviledges can terminate a process...no matter what OS), it's a horrible User Experience (UX) decision.
Think about it from the User's point of view. You're sitting there looking at an application. The application doesn't appear to be doing anything and isn't providing you any visual feedback that it is doing work. You'd think the application was hung and you'd restart it.
You could do anything from showing a scrolling progress bar to having the long running process update some piece of information on the UI thread (think of an installer in mid-install...it's constantly telling you which files it's putting where rather than just making you wait). In any case, you should be providing some visual feedback to the user so they know your application is still running.
Have the GUI work in a separate thread so that it is (hopefully) never "not responding".
If this is a question about programming, your program should never be in that state since you've tied up the GUI thread somehow. And you can't (and shouldn't) stop Windows or the user from closing your program. They've detected your code is rubbish and have every right to forcefully toss it out of their valuable address space.
In any case, your program's too busy doing other stuff - if it can't respond to the user, it probably can't waste time protecting itself either.
At some point, developers need to get it through their thick skulls that the computer belongs to the user, not them.
Of course, if you're talking about how to configure Windows to prevent this (such as on your PC), then this question belongs on serverfault.
Don't. No matter how important you think your application is, your users' ability to control their own systems is more important.
You can always terminate applications from task manager if you have the privileges. You can just disable or not show the system menu options that has the close icon and close menu option in the application window but that is not going to prevent the user from terminating it from task manager as mentioned before. Instead, I would just show some busy processing icon in the application so the user understands what is going on.
Only thing you can do is disable the close button. Users can still kill it from task manager or similar tool, to way around that. You could make killing it harder by launching it as a privileged process, but that comes with many more problems of its own.