Don't send hits when app is in background

[toto]

This PR stops the SDK from sending any hits if the app is not in UIApplicationState.active aka on screen and receiving events.

This should be a sensible default since you might otherwise send hits if iOS re-renders the UI in the background without user interaction (e.g. if background refresh or background push happens).

Normally you would not want this to be tracked as a hit.

Depending on your preference you could also add a configuration option for this behaviour.

To validate this change:

• Set up the SDK and send a hit in applicationDidFinishLaunching.
• Start the app with "Launch due to a background fetch event" enabled in "Schema > Run" (Only present on devices, not simulator)

With the current master of the SDK you should see a hit, with the changes in this PR there should be no hits being received unless you set enableBackgroundTask = true in the SDK config.

[d-theo]

Hello,
thank you for your PR. I'm adding some modification to the last commit.
The new condition seems buggy

(TechnicalContext.applicationIsActive && !tracker.backgroundTaskEnabled)

In a "normal" usage scenario, the value of TechnicalContext.applicationIsActive is true and tracker.backgroundTaskEnabled * could * be set to false, resulting in loss of all hits for some of our clients.

We chose to keep backgroundTaskEnabled for those who want Offline hit to be sent in background and we add a new configuration key sendOnlyWhenAppActive that should be set to truein your case (but set to false by default to preserve the original behaviour for everybody else)

In addition, I changed UIApplication.shared.applicationState == .active to a non-warning solution (with pub/sub) as some of our clients look closely UIKit thread warnings and may provoque compatibility problem with "non-UIKit" devices like MacOS or WatchOS.

Can you confirm that everything is still ok with your App ?

[toto]

The changes work for our app. Using a async mechanism to support other platforms makes sense. From my side you can merge this.

However: watchOS and macOS also support background processing to some degree, maybe it would make sense to incorporate that? For macOS it would be application active (maybe?). watchOS mechanism is very similar to my knowledge - it also supports background activity through some pushes (e.g. watch faces) background downloads and for watchOS 5 background audio just like on iOS.

[nsagnett]

Sorry for the long delay to respond but it's fixed since v2.11.3

Thanks for your help on this topic