Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. Not receiving Qt::ApplicationState = ApplicationActive on iOS in all cases of return from suspend
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Mobile and Embedded
6 Posts 2 Posters 1.8k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    swoods
    wrote on last edited by
    #1

    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.

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi,

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

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      S 1 Reply Last reply
      0
      • SGaistS SGaist

        Hi,

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

        S Offline
        S Offline
        swoods
        wrote on last edited by
        #3

        @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.

        1 Reply Last reply
        0
        • SGaistS Offline
          SGaistS Offline
          SGaist
          Lifetime Qt Champion
          wrote on last edited by
          #4

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

          Interested in AI ? www.idiap.ch
          Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

          S 1 Reply Last reply
          0
          • SGaistS SGaist

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

            S Offline
            S Offline
            swoods
            wrote on last edited by
            #5

            @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.

            1 Reply Last reply
            0
            • SGaistS Offline
              SGaistS Offline
              SGaist
              Lifetime Qt Champion
              wrote on last edited by
              #6

              Good, cleaning code is always a good idea :)

              Interested in AI ? www.idiap.ch
              Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

              1 Reply Last reply
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved