matomo-org/matomo-sdk-ios

Enable custom Queues

brototyp opened this issue · 14 comments

brototyp commented

Right now Events are lost if the application terminates because they are stored in the MemoryQueue which stores them all in memory only. To enable users to add a custom queue we would have to:

  • Expose the uuid of the Event by making it public
  • Let the Event conform to the Codable protocol
  • Expose the URLSessionDispatcher by making it public
  • Add a paragraph to the Readme that explains how to implement and use a custom queue.
mattab commented

It would be great to have this feature, as many users will close app and then re-open a day later. In this case, would be good to still track the users events 👍

Regarding the "Best way to store the events", I'd say go with the simplest solution -> is CoreData simple enough maybe?

  • 👍1
minitrue22 commented

I think CoreData might be overkill.
Almost all problems reported on the old implementation was related to CorrData setup and configuration. Challenge when the app and framework both use CoreData.

One option is just to serialise the data structure to disk. Needs some logic around thread safety and frequency of saving.

minitrue22 commented

Unsent events will only be deleted if the app is terminated, not if put in background.

I do not think it is a huge problem

brototyp commented

I think so too. There is barely any need to query the data. The only importance is to be able to retrieve the data in the same order. Currently I would prefer simply serializing and storing them.

elkorb commented

Hi @brototyp ,
I got a requirement to store any event even when the app is 'force quit', is there any workaround for this?

brototyp commented

Hi @elkorb, thanks for getting in touch. The SDK is setup in a way, that it is very easy to exchange certain parts.
For your question, the right ting to look at is the Queue. Every MatomoTracker instance is setup with an object implementing the Queue protocol. In the current state the SDK only provides a MemoryQueue which loses all data once the application is terminated.

In oder to not lose data on termination, you would have to create a new Class, for example a PersistentQueue, which implements the Queue protocol and the instantiate your MatomoTracker instance with an instance of this new class.

elkorb commented
brototyp commented

Hi @elkorb, yes you are correct. Right now you can't initialize the MatomoTracker with just a custom Queue, because the URLSessionDispatcher is internal and the dispatcher parameter is required. Unfortunately we can't just change the dispatcher to be optional and fall back to a default one, because the dispatcher has to be initialized with the base url of the backend. What do you think if we change the URLSessionDispatcher to be public?
About the Event's uuid: You are totally correct. Additionally: You cannot persist the events, since all the other properties are internal. I would love to expose the uuid by making it public and let the Event implement the Codable protocol. What do you think about that?

elkorb commented

Hi @brototyp , regarding the Queue, it can be added as additional parameter to the convenience init like: convenience public init(siteId: String, baseURL: URL, queue: Queue = MemoryQueue(), userAgent: String? = nil), so the dispatcher will have the url in its initializer.
regarding the Event - This solution will be great.

brototyp commented

Hi @elkorb, actually we cannot do that to the existing function, because the function is an Objective-C compatible function and Queue is not representable in Objective-C.

elkanaoptimove commented
brototyp commented

Alright. I am open for pull request in this regard. I will update the issue to reflect what we discussed.

brototyp commented

This one got implemented and merged. The only thing left here is to document this feature.

larsriehn commented

Since the interest in having a PersistentQueue is there (that does not loose events when the APP is terminated), has anyone ever written one and is able to share it with the community?