feat: add offline mode

[Mercy811]

Summary

Add support for offline. When online, it behaves exactly the same as previous versions. When offline, tracking an event will not schedule a flush not will only be stored in storage. When back to online, the SDK will flush all stored events.

Offline feature is support by default

To opt of the default offline logic provided by network checker plugin

amplitude.init('API_KEY', {
  offline: OfflineDisabled
});

Checklist

• Does your PR title have the correct title format?
• Does your PR have a breaking change?:

[Mercy811]

It requires setOffline() to enable custom offline logic by first opting out the default plugin and then toggling config.offline which is unlike Kotlin which has direct access to amplitude.config. I think adding setOffline() is an extended feature and we should release this version without supporting custom offline logic first. If there is customer request, then we can plan for it later.

[justin-fiedler]

Overall looks good. Thanks @Mercy811. Really appreciate the test coverage.

See question about scheduling flush earlier on return to online.

[Multiply]

It requires setOffline() to enable custom offline logic by first opting out the default plugin and then toggling config.offline which is unlike Kotlin which has direct access to amplitude.config. I think adding setOffline() is an extended feature and we should release this version without supporting custom offline logic first. If there is customer request, then we can plan for it later.

We just noticed this landing, and we'll most definitely use this functionality to pause sending events, and just let them queue up.
For the most part, we'll just do the same as the default plugin, but also check if we've paused sending events before setting it back to online.

[Mercy811]

Hi @Multiply, thanks for choosing Amplitude and using the new feature! I will put it into our roadmap. Could you give me more context on the difference between the default networkConnectivityCheckerPlugin and the one you want to implement? We can see if that's what we can make it as default to support more customers with the same needs.

[Multiply]

Currently, I'm trying to set offline to disabled, and then set it to true via our own plugin, but it seems to result in the default plugin being loaded anyway. (Our plugin is most likely added first, and setup also called first, which is why the default one is still added) - Might be better to have a separate flag for disabling the default plugin?

What we're trying to achieve is storing all events in the storage provider, until a user gives consent, instead of simply dropping events.
If the user eventually consents to tracking, we'd like to push the whole queue at that point in time.

Opting out doesn't quite do what we want, but the offline variable would.

Essentially we just want to pause sending for a while.

Edit: I succeeded in disabling the plugin, by moving my initialization into the async execute call for the first event, so I could set offline to true, until consent comes in.

[Mercy811]

Hi @Multiply,

What we're trying to achieve is storing all events in the storage provider, until a user gives consent, instead of simply dropping events.
That sounds like another feature request. But glad to hear that we are unblocked now.

[cgibson-emesent]

Is there going to be react-native support for offline mode when the network drops out and automatically start sending once the connection returns? I would have expected that if the attempt to send the event fails due to a network error, it's not removed from the _unset array in the local storage. I'm a bit puzzled as to what the purpose of the offline config flag is as you can then never send events.

[Mercy811]

Hi @Multiply, I created a separate issue to track requests on setOffline(). Could you leave a comment with why you need this feature there? Thanks.

[Mercy811]

Hi @cgibson-emesent, I also created a separate issue to track requests on supporting offline mode for React Native SDK. Please leave a comment there to help us better track customer requests.