Enable custom Queues

[brototyp]

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]

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?

[minitrue22]

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]

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]

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]

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

[brototyp]

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]

Thanks for the quick response, Right now, the only public initializer of the 'MatomoTracker' that receives a Queue, requires the client to provide a Dispatcher. Why not provide convenience initializers that accept either a Queue or Dispatcher and defaults to Matomo's implementations of the two? Also, any implementation of Queue is benign since Event's *uuid* property is internal and thus cann not be used as Equatable/ Hashable external implementations. Thanks again

…

On Sun, Apr 15, 2018 at 4:46 PM, Cornelius Horstmann < ***@***.***> wrote: Hi @elkorb <https://github.com/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 <https://github.com/matomo-org/matomo-sdk-ios/blob/master/MatomoTracker/Queue.swift>. Every MatomoTracker instance is setup with an object implementing the Queue protocol. In the current state the SDK only provides a MemoryQueue <https://github.com/matomo-org/matomo-sdk-ios/blob/master/MatomoTracker/MemoryQueue.swift> 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#137 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEtD5JXWtRDEPdBjk9Lq9_czyEphBFkCks5to09CgaJpZM4NTObW> .

[brototyp]

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]

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]

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]

Ok, then make URLSessionDispatcher public is also excellent. Thanks

…

--- Why it's Too Soon to Fear AI Capabilities<https://www.optimove.com/blog/the-impact-of-ai-on-our-lives?utm_source=emailSig&utm_medium=email&=utm_blog_AI_Impact> Elkana Orbach iOS Developer +972-50-846-4927 skype: elkana_o@optimove.com <http://www.optimove.com/?utm_source=emailSig&utm_medium=email&utm_campaign=sig-Logo>[http://www.optimove.com/wp-content/uploads/2017/03/optimove_logo_sig.png]<https://www.optimove.com/?utm_source=emailSig&utm_medium=email&utm_campaign=sig-Logo> Connect with us on LinkedIn<https://www.linkedin.com/company/optimove> | Twitter<https://twitter.com/optimove> | Facebook<https://www.facebook.com/optimove> | Blog<https://www.optimove.com/blog?utm_source=emailSig&utm_medium=email&utm_campaign=sig-Blog> New York: 1.888.235.5604 | London: +44.203.608.1270 | Tel Aviv: +972.3.672.4546 From: Cornelius Horstmann <notifications@github.com> Reply-To: matomo-org/matomo-sdk-ios <reply@reply.github.com> Date: Monday, 16 April 2018 at 19:00 To: matomo-org/matomo-sdk-ios <matomo-sdk-ios@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [matomo-org/matomo-sdk-ios] Persisting Events (#137) Hi @elkorb<https://github.com/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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#137 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ac-c74-mi7bZlAL6GKV48j64bO1LFrL4ks5tpMAQgaJpZM4NTObW>.

[brototyp]

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