I want to test suspend/resume functionality of my app. In suspending event I save required data and I want to simulate that my tablet hasn't enough memory and it released my app data while it was in suspended state so that when I resume, it will load saved data in resuming event. In visual studio I use Suspend button from Debug Location panel to suspend the app, but when I resume it I see that all the data, e.g. values that were enetered to textboxes, are still exist. How to force the simulater to release my app data while it's in suspended state?
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 developing a win forms application for Windows CE based devices.
I have to initialize all controls my dialog shows at runtime because I get the information about the UI layout from a backend system via WLAN every time the user performs an action on the screen.
The performance is not the best but it's ok in most cases. But sometime there is a thread in background that ends and the next function call in main thread needs 300-400 ms to return.
In debugger I can see the thread ID from the thread that ends. Is there any way to find out which thread is associated with this thread ID, so that I could keep the thread alive until the application is in an time uncritical part?
I think it's a thread from an UI element because I don't start threads manually.
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.
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).
Windows XP/VISTA/7
How might it be possible to run an application during the logoff procedure of a user, after explorer.exe terminates?
The purpose is to block shutdown but with an application that runs after explorer has terminated.
It is of course possible to temporararily block shutdown in vista with ShutdownBlockReasonCreate, or to cancel it in XP via WM_QUERYENDSESSION. However both of those methods occur during the user session before Explorer terminates. The question is how to get an app to run after explorer terminates AND to block shutdown.
This is not possible from a service because in VISTA/7 if the user has selected Shutdown/Restart, the service seems to have no way to block shutdown after the user has been logged-off. (The kernel seems to terminate the service and the service itself cannot block shutdown like a user app can ?)
How and when exactly does WinLogon terminate explorer.exe? It seems that it waits until all/any other applications have terminated and have ceased blocking shutdown, then it terminates explorer?
Does WinLogon wait for explorer.exe to close before it will finally close the desktop / session?
I have considered, for example attempting to hook NTDLL for the APIs that terminate a process and intercept the termination of explorer but it is unclear how or why Winlogon would then wait rather than continue the shutdown.
The purpose of all this is to find a way to run an executable during Vista/7 shutdown, which is able to block shutdown for as long as it pleases, only AFTER explorer has exited and all files and resources have been released by explorer and all other apps running as that user.
In XP this is possible by simply cancelling the shutdown in WM_QUERYENDSESSION then re-issuing ExitWindowsEx (LOGOFF) then doing the tasks in a system service. It however leaves the user at a logon screen with no progress indication.
If it was possible to inject a process after explorer terminated, the process would be able (in my theory) to show UI on the same user's desktop and effectively act as a second-time-around custom shell during the logoff procedure.
It is believed/suspected that Windows performs something similar when it installs updates during shutdown (but this behaviour has not been noted on Vista so far)
In summary there seems to be no obvious way in Vista to block shutdown after explorer closes during a user's logout?