Not receiving Qt::ApplicationState = ApplicationActive on iOS in all cases of return from suspend

[swoods]

Hello --

I have an iOS application that performs certain operations when the app goes to sleep/suspend and then reactivates. I queue these actions off the Qt::ApplicationState change signals. However, in one type of suspend operation, I am not receiving the Qt::ApplicationActive when the app returns to full focus.

What works:

App is running normally -- user hits "Home" button. I receive Qt::ApplicationInactive (2), and then Qt::ApplicationSuspended (0). I suspend my operations as expected. When the user then selects the app to come back up, I get Qt::ApplicationActive (4), and can restart the processes without issue. Works fine.

What doesn't work:

User leaves the system up and it goes into background (still see it, but masked) -- I received the Qt::ApplicationInactive (2). User does not touch anything, and the screen goes black, and the system receives Qt::ApplicationSuspended (0). My app suspends its operations. Then the user hits the Home button and gets the "Swipe to Unlock" screen on the iPad. When they swipe to unlock, our app comes up to full focus, but I never receive the Qt::ApplicationActive signal, and don't queue my "resume operation" processes.

Can anyone tell me what is the differences between these two suspend operations on the iPad? Do I need to more actively reconnect to the Qt::ApplicationState change signal?

(One thing I found out trying to test that is that you cannot use the XCode simulator to test the second case, only the first case.)

Thanks! Any help appreciated.

[SGaist]

Hi,

Interesting use case, can you share a minimal example that demonstrate this behavior ?

[swoods]

@SGaist

Sorry for long time for response -- got called off on another task.

Interestingly enough -- I put together a simple app as you suggested, and I cannot recreate this behavior. When I come back from the case I described above, I do get the Active state signal as expected.

There are a couple of differences between our app and the simple app -- on the original, we are running a separate thread for communications. On this simple app, I emit a signal to notify my simple app's display that a Q_PROPERTY has changed (namely the value telling me what is the last ApplicationState, which I display on the app.)

So, this may be the result of our multithread process, rather than an issue with the ApplicationState signal itself. Thanks for the suggestion of the simple app! This shows me that there is nothing special about this sort of sleep and the signal is generated -- there's just something in our app I need to fix.

[SGaist]

Once you find out I'd be interested in the detail of what is happening

[swoods]

@SGaist

Further expansion of the simple app example has indicated it was not the multithreading. (i.e. I added multithreading to our app and still could not reproduce the problem.) We've discovered a number of issues with this part of our app since I first reported this and I think the problem I saw is due to how we implemented our signal handling, including the one that reported new ApplicationState. If I manage to recreate the problem after we fix our other issues, I'll come back here, but I am pretty sure this problem was created by issues of our app.

[SGaist]

Good, cleaning code is always a good idea :)