fix(dispatch): decrease timer interval to 15 sec

[chreck]

#344

[brototyp]

Hi @chreck, thanks for your pull request!

I just checked and tried to understand it. Maybe you can help me there. As far as I am understanding the problem, according to the SO thread you linked in the ticket, iOS terminates the app if it is running longer than 30 seconds in the background.

The dispatchInterval property only defines how long the Matomo SDK should wait before it tries to send the next batch of events to the server.

I am struggling to understand how changing this is preventing the iOS to kill the app if it runs longer than 30 seconds in the background.

[chreck]

Maybe an example helps to understand the case.

1. The app is running in background
2. For 2 minutes it does a high memory load task
3. After the task is finished it generate a tracking event ,Task X finished'
4. The matomo dispatcher is started with a timeout of 30 second
5. iOS started a timer to kill the app in 30 seconds
6. iOS killed the app after 30 seconds
7. the tracking event ,Task X finished' could not be sent to matomo server because the app is not running anymore

[brototyp]

Hey @chreck, thanks. That helped to understand the issue in question.

I think there are two underlying problems:

1. The event is not sent to the server early enough (since it, in the worst case, is dispatched only 30 seconds later). If the app is suspended before the event can be sent to the server, it should just be sent the next time it is brought back to the foreground.

2. If the app is terminated before it could be brought back to the foreground, the event is lost, since currently events are not persisted per default.

Against case 1, there isn't too much we can do in this situation. Reducing the 30 seconds to 15, can't fix this problem, it just reduces the probability. But it comes with the downside of talking to the network more often (which has an effect on battery) since now events are per default dispatched twice as often. Since this is a public, variable, I would leave it to the user to decide which tradeoff to take.

For case 2, there is a public protocol, called Queue, that can be implemented and overwritten in oder to add persistence when adding an event to the queue. There is no persistent queue implemented yet though. Have a look at this issue for further details.

[brototyp]

I will close this for now because I am not convinced it's the right approach. Additionally the dispatchInterval parameter is a var, so can be changed when using the MatomoSDK.

Feel free to open it again if needed.

[brototyp]

Hi @chreck, I just created this PR. My approach there is to wrap every sending of the events into a background task. Can you try it out and give me some feedback?

[chreck]

@brototyp we use currently the dispatch 15 seconds approach. What about the persisting of the events? I dont think I have time to test your approach, maybe someone else. Sorry.