Is there some type of notifications that iOS emits when app get force quited?
By force quite i mean tapping the home button while app is in active state and then removing it from multitasking menu.
I want to be able to detect force quit, to gracefully handle everything.
We have an issue like this with one of our games and our publisher wants us to handle this.
This is not standard Cocoa App, this is game ported from PC, written mostly in C++.
This happens only on iPad Mini 2nd gen, when app is force quit-ed it will crash on next launch.
On other devices, when app is activated it will load up properly and continue with proper scene loading order.
Does iPad mini 2nd gen has something different from other devices regarding development?
Crash logs says that app crashes immediately after force quit, well duh...
- (void)applicationWillTerminate:(UIApplication *)application
is not really useful, it doesnt detect force app quit.
The idea is that your app should handle termination the same regardless of whether it was initiated by the operating system or by the user. You are encouraged to save the app's state and reload on the next start. And it's probably a good idea to save state when your app is sent to the background because according to the second paragraph below, applicationWillTerminate is not always called when the system kills your app.
According to the documentation
This method lets your app know that it is about to be terminated and purged from memory entirely. You should use this method to perform any final clean-up tasks for your app, such as freeing shared resources, saving user data, and invalidating timers.
Also
For apps that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the app. For apps that support background execution, this method is generally not called when the user quits the app because the app simply moves to the background in that case. However, this method may be called in situations where the app is running in the background (not suspended) and the system needs to terminate it for some reason.
Related
C++, WinRT, VS2017 MFC, Win10
I have a C++/WinRT VS2017 console app as a test platform to find my Bluetooth LE device, enumerate the services and characteristics, and then write a value to the Tx characteristic, etc. I have all of that working and now I am trying to move that code to an existing VS2017 MFC app.
In the console app the BluetoothLEAdvertisementWatcher and callback to the watcher.Received() were done in the main.cpp. Once my BLE device was found, a separate function was called to create the device object from the deviceAddress and then enumerate the services and characteristics.
In the MFC app I created a separate function run in a separate thread to establish the watcher and attach the callback. That all works fine up to the point that it needs to GetGattServicesAsync(). In the console app the function OpenDevice() used to create the device object and get the services was done with a get() as in:
OpenDevice(deviceAddress).get();
The first thing OpenDevice() does is create the device object using
auto device = co_await BluetoothLEDevice::FromBluetoothAddressAsync(deviceAddress);
If the device object is created, then the next thing it did was get the Services with:
auto services = co_await device.GetGattServicesAsync();
Here is where my MFC code fails. In the function thread that creates the watcher and watcher.Received callback my MFC code does the same call to OpenDevice(). In OpenDevice the device object is indeed created but then the call to GetGattServicesAsync() will never finish so matter how long I wait. If I enter the GetGattServicesAsync() in Debug mode, however, then it works fine.
For testing I have also put the OpenDevice() code within the watcher thread but, again, it stalls on GetGattServicesAsync().
In this case, however, I cannot use the co_await but had to use
auto services = device.GetGattServicesAsync().get();
Regardless, the GetGattServicesAsync() never finished.
Any suggestions of what I need to do or what I am doing wrong?
Since running in Debug was working I was trying to solve why this was not working in Release mode. I was relying on my log file entries to track the progress after the fact. For the halibut I put in some Beeps() to let me hear the progress and I was hearing beeps but not seeing log entries after that GetGattServicesAsync(). Apparently what was happening is that, for what ever reason, the GetGattServicesAsync() was NULLing out the handle to my log file so no writes were taking place. I did a check for NULL after the GetGattServicesAsync() and, if it was, re-established the log file. All of a sudden my log file was showing the progress that I thought was not happening. Sometime I think it is just me...:-(
I've got a C++ app (Qt-based) running on MacOS (10.10 and newer), and I'd like it to modify its behavior slightly when it is running under MacOS's app-nap mode. (In particular, there are some periodic network queries it does in order to update status indicators in its GUI, but if the application is napping I'd prefer that it stop doing them until after it has woken up from its nap).
If I had a function like this:
bool IsThisProcessNapping(); // returns true iff we're in app-nap mode
... I think I could implement the behavior I want, but I don't know of any such function. Does it exist under some other name?
(Note that I don't want to just disable app-nap, since I want my program to be energy-efficient if possible)
I'm not sure there's a specific answer to your question (I don't think the API you talk about actually exists).
You could start by reading Energy Efficiency Guide for Mac Apps, especially the section "Enhancing App Nap":
By default, your app becomes eligible for App Nap if it’s not actively
engaged with the user and hasn’t updated a visible window for some
length of time. However, your app knows the most about the importance
of its activity, and shouldn’t rely on App Nap to put it into an idle
state. The most effective way to enhance App Nap is for your app to
listen for notifications that it’s no longer in active use and to
suspend energy-intensive work as quickly as possible
Given the scenario you describe (pausing network requests to update status indicators), check out Notify Your App When Visibility Changes.
It has examples of the application delegate methods applicationDidChangeOcclusionState: and windowDidChangeOcclusionState:. When your app or the relevant window is occluded, you could pause your network activity, and resume it when the occlusion state goes back to visible.
The guide mentioned above also links to similar documentation for checking the active state of your app.
If your app is not visible, and not active, it's a candidate for App Nap. At that point, what difference does it make in your case if the app is actually napping yet? If your aim is to be energy efficient, pause your network activity once the app is not visible - since no-one can see your status indicator anyway!
in a PC game I have ingame browser used for news, virtual currency shop and social networks. It's built with quite fresh update of Chromium Embedded Framework. The problem is when I open a browser window (website is working fine there) and then close, for certain websites CEF sub-process doesn't finish. I also may continue hearing audio, if it was Youtube video, for example. I use offscreen rendering, other native windows are not created, only subprocesses. To close the browser window I remove all references to CefBrowser and call:
m_browser->GetHost()->CloseBrowser(true);
I also tried other ways to close/destroy/finalize that render subprocess, such as loading 'about:blank' before closing, but that was no help: process stayed awake, audio continued playing.
Important note: it happens only on certain websites, which I suppose use some feature, that others don't. When I tried to disable JavaScript in CEF settings, the bug disappeared, but I need JS.
Is there a way to force kill browser subprocess? (Notice that GetWindowHandle returns 0, because it does not have a window)
Is there another way to correctly terminate browser which I don't know?
What feature of the websites may cause such bug?
Thank you!
CEF runtime configuration: multi-process, single threaded message loop, with subprocess path, windowless rendering, no sandbox.
PC configuration: OS Windows 8, VS 2010, Chromium Embedded Framework version 3.3071, build 1649, C++ language.
You should check your implementation of onbeforeunload.
CEF GeneralUsage writes about CefBrowserHost::CloseBrowser:
The parent window then needs to call CloseBrowser(false) and wait for a second OS close event to indicate that the browser has allowed the close. The second OS close event will not be sent if the close is canceled by a JavaScript ‘onbeforeunload’ event handler or by the DoClose() callback.
And if you still want to just kill the sub-process , I would suggest you use the browser IPC message and exit at the app.
At your game run
CefRefPtr<CefProcessMessage> msg = CefProcessMessage::Create(KILL_subprocess);
m_browser->SendProcessMessage(PID_RENDERER, msg);
and at the subprocess implement “OnProcessMessageReceived”:
if (msg->GetName() == KILL_subprocess)
{
delete this;
std::exit(EXIT_FAILURE);
}
I'm quite confused as to what should and should not be done in QApplication::commitData. The name implies that I should just store the state, and the docs say it should not close the application. However, the default implementation indeed closes all windows thereby closing the application. Also, if this is not the way to detect windows shutdown, I don't see any other way to tell that windows is indeed being shutdown.
There is also the related saveState. The function name means about the same and the documentation is also quite similar.
How am I supposed to properly detect when the system is being shutdown and both save my state and close my application? Is commitData indeed the correct way and just suffering from a very poor name and bad documentation?
In my practice to detect an application shutdown I usually connect to the slot void QCoreApplication::aboutToQuit (). As it says in the docu:
The signal is particularly useful if your application has to do some last-second cleanup. Note that no user interaction is possible in this state.
So far so good this has worked for me properly
commitData() and saveState() may seem redundant.
But the documentation
says
Futhermore, most session managers will very likely request a saved state immediately after the application has been started. This permits the session manager to learn about the application's restart policy.
Maybe that explains why the notion of 'data' and 'state' are separated. During that initial call, it would not be user friendly to interact with the user.
The default response to shutdown the application seems like a good design, because if you don't reimplement, then the safest thing to do is to close the app (as if the user had chosen the Quit action), which should also save the user's data.
Is the OS shutting down, or only the session? As far as your app should be concerned, it is only the session (since technically, the user could be logging off and the OS continues to run.) And the user might consider the app to be not 'shut down', just 'paused with data safed.'
Also consider mobile platforms like iOS, where an application seeming runs forever.
How can i programatically check if the windows shell (explorer) has loaded all startup programs & the user login process is over ?
There is a somewhat documented event you can wait for, but it is signaled when explorer has started loading. On XP this event is called "msgina: ShellReadyEvent" and "ShellDesktopSwitchEvent" on Vista. I linked to the sources of some alternative shells in a post related to this event.
Another alternative would be to listen for the Taskbar Creation Notification message. It can fire more than once so you would need to keep track of that.
On Vista+ there is one last alternative that might just work: Programs set to run at startup are part of a job object so they cannot run at high priority. If your program runs at startup you could maybe check for this, either by using IsProcessInJob or SetPriorityClass+GetPriorityClass in a loop. (SetPriorityClass will lie about its return value IIRC)