Fixes the case where the storage is overwritten by the first sent events.
The buggy flow:
Init the MixpanelAnalytics class, that schedules the periodic process (Timer.periodic(...)) that pushes the events, prior checking if it's the first cycle and pulling events from memory.
Push new events that are stored in the shared prefs right away.
Close the app before the events are sent.
Reopen the app, and init MixpanelAnalytics that starts the Timer.periodic.
Push events before the first cycle of the Timer.periodic happens. At this point no interaction with the sharedprefs happened, and the events stored in the queues of the driver are empty. Although there are old events stored in memory. The new events gets added to the queue and also stored in memory, overwriting the old ones.
First time the Timer.periodic process executes, memory is checked, but we only have the new events as the old ones were lost.
An option is to add some init() method that would retrieve the old events from sharedprefs as soon as the driver starts. But as that is an async process that cannot happen in a constructor (could be some sort of static async factory method) it would be a breaking change. So this is an intermediate solution, where we no longer check for any previous stored events in the Timer.periodic process but in the actual methods where the events are pushed, thus avoiding the overwriting. This solution has the downside that we would only send old events in the scenario where new events are pushed. If no new events are pushed, then any old event would be ever sent.
This also updates the lock dependencies to flutter stable 1.22
Fixes the case where the storage is overwritten by the first sent events.
The buggy flow:
MixpanelAnalyticsclass, that schedules the periodic process (Timer.periodic(...)) that pushes the events, prior checking if it's the first cycle and pulling events from memory.MixpanelAnalyticsthat starts theTimer.periodic.Timer.periodichappens. At this point no interaction with the sharedprefs happened, and the events stored in the queues of the driver are empty. Although there are old events stored in memory. The new events gets added to the queue and also stored in memory, overwriting the old ones.Timer.periodicprocess executes, memory is checked, but we only have the new events as the old ones were lost.An option is to add some
init()method that would retrieve the old events from sharedprefs as soon as the driver starts. But as that is an async process that cannot happen in a constructor (could be some sort of static async factory method) it would be a breaking change. So this is an intermediate solution, where we no longer check for any previous stored events in theTimer.periodicprocess but in the actual methods where the events are pushed, thus avoiding the overwriting. This solution has the downside that we would only send old events in the scenario where new events are pushed. If no new events are pushed, then any old event would be ever sent.This also updates the lock dependencies to flutter stable 1.22