-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offline mode missing #16
Comments
I'm probably going to tackle this before going into production with piwik in my Android app. Any ideas on a solution direction? |
@d4rken I think there should be some FIFO container within Tracker instance so we could store here untracked views. It would be great if this container would be configurable (for example it might accept |
A few points that we should consider:
|
I have now 😉 . It's one way to solve it but as you mentioned, it addresses none of the concerns. I would probably start from scratch, not refactor this. @apc-kamezaki You might want to refactor |
I just had a look at both the iOS and Android tracking library codebases. The iOS tracking library uses CoreData (ultimately SQlite) to persistently queue a configurable number of events. Wouldn't it be logical to implement it in the same way for Android, i.e. using sqlite and optionally some lightweight ORM on top of it? |
@suzukieng That would be one good way. But generally we don't have to focus on a specific implementation just because other piwik code bases use it (as long as it works sufficiently well). The public API should be similar and it should behave similar. "Under the hood" stuff like this is almost FFA 😁 . SQlite would be fine, but so would raw files or maybe fancy stuff like realm.io. The primary goal is to have a low impact on the host app and as secondary goals to somehow achieve the points mentioned above. |
@d4rken Completely agree with primary/secondary goals, low impact is absolutely key. What I find hard to judge is how much of a difference it makes if you store events persistently vs. buffer them in-memory, i.e. how often will the app be killed by the OS before events can be uploaded. Android processes are in general pretty long-lived (see: http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle) and perhaps an Android Service can be persuaded to live on as long as there are events. But this would again probably go against the low-impact goal and also slightly complicates integration because you would have to add the Service to the manifest. BTW: SharedPreferences are another light-weight mechanism for storing stuff persistently, I know the folks at count.ly use it in their Android SDK. |
Many Android devices despite having pretty decent version of system (4.3+, many 5.0.3) are short on resources. Thus I would not assume the processes are 'long lived' or the logs from the low-level devices will often be lost. Also keeping them alive just because we can sounds less user friendly than just dumping the data and sending on the next occasion. Storage |
SharedPreferences would not be very suited for this as this isn't a good case of key/value based access. In general we have to assume the app could be killed at any moment, so unless we can somehow get a callback for when the app is killed, we shouldn't keep data in memory for long. Something like batching a few failed requests and writing them into storage based on a timer, would be my idea. The right location to store this would indeed be a subdir of the cache dir because these files are cached and can be lost without any grave repercussions. More specifically Context.getCacheDir() (private cache, i.e. /data/data//cache) because the analytics could be considered private information (depending on what the developer tracks). |
Hello guys, FYI: we are also implementing Offline mode for the official Piwik JS Tracker code (in matomo-org/matomo#9939). So far we make it super simple and you can see the idea here: https://github.com/piwik/piwik/compare/2.x-dev...offlinetracker?expand=1
(Just FYI in case we could maybe reuse same method name or similar. Fun to see that we are synchronised and implementing this important functionality at the same time in both projects!) |
Not sure yet about which approach to take. Manually settings online/offline mode really is a simple approach, but i think the sdk should provide this on Android. Alternatively reacting only to successful/failed communication with Piwik would also allow clients to cache data in cases where the issue is on the server side. But permanent issues due to code errors would just max out the cache.... Maybe just checking connectivity and reacting to changes then... As we don't want the authtoken to be used on Android (can't be stored securely), we should just have to cache data for up to 4 hours and discard older data. All already have the "cdt" parameter set, so sending them out of order should also not matter, right? |
Hi @d4rken To answer a few points:
|
Even if the |
Basic offline mode with age and size based limits. Stores the dispatch queue on transmission error until network connectivity is available again. Items are replayed in order. Closes #16
If the dispach of events occurs when the device is offline, the events queue is cleared before knowing if the request was a success.
The text was updated successfully, but these errors were encountered: