Skip to content
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

support for offline mode with queued hit requests #3

Open
zwetan opened this issue Oct 3, 2015 · 9 comments
Open

support for offline mode with queued hit requests #3

zwetan opened this issue Oct 3, 2015 · 9 comments
Milestone

Comments

@zwetan
Copy link
Owner

zwetan commented Oct 3, 2015

see Queue Time parameter

"Used to collect offline / latent hits.
The value represents the time delta (in milliseconds) between
when the hit being reported occurred and the time the hit was sent."

@zwetan
Copy link
Owner Author

zwetan commented Oct 9, 2015

strategy is simple

implement a custom HitSender which detect if there is an Internet connection

if no connection
queue the hit request data with the current getTimer() value, eg the queue_time

if connection
send the current hit request
then look into the queue and if there are queued requests
send the data with the Queue Time parameter

calculation is easy
current_time = getTimer()
qt = current_time - queue_time
eg. a value in millisecond which is the difference
between when the hit is being reported (queue_time) and when the hit is send (current_time)

note from the doc

Values greater than four hours may lead to hits not being processed.
eg. 4 * 60 * 60 * 1000 = 14400000 max 14400000 milliseconds

@zwetan
Copy link
Owner Author

zwetan commented Oct 9, 2015

we would need 2 timers

a global timer that look and send queued requests
every 1h or so (configurable?)

a timer loop for each queued request
we do not want to send 100 requests in a for loop
we want a little delay between each requests
to not trigger the RateLimiter

@zwetan
Copy link
Owner Author

zwetan commented Oct 9, 2015

priority: make it work with AIR
nice to have: make it work for SWF file too

eg. AIR have a a easy Event.NETWORK_CHANGE
while Flash need a custom solution

@zwetan zwetan added this to the 0.9 milestone Oct 9, 2015
@Xakaloz
Copy link

Xakaloz commented Sep 10, 2016

Hi Zwetan,
First of all, thanks a lot for your amazing library.
I would like to know if you plan to add this functionality soon?
Thank you by advance,
Jon.

@zwetan
Copy link
Owner Author

zwetan commented Sep 10, 2016

yeah been a busy year, it was planed for v0.9 milestone and still is
many months passed and voila...

I ll try to release that for the 1st nov 2016 more or less
I still use this library a lot but it does really 95% of the things I need
hence why I didn't furiously updated it

@Xakaloz
Copy link

Xakaloz commented Sep 10, 2016

Good news!

Merci beaucoup !

@matt-shoesmith
Copy link

I'm also looking forward to this.
How does it work as is if an internet connection is temporarily lost?
Does a screenview get completely missed if it's sent while there is no connection?

@zwetan
Copy link
Owner Author

zwetan commented Feb 26, 2017

OK, so I presented the problem wrongly

It's not

implement a custom HitSender which detect if there is an Internet connection

it's more about

provide an implementation of the HitSender which can cache or queue the requests
if the request fails for whatever reasons.

the problem is not "if no connection" do this, but "if the request fail" do that.

so to answer your questions

How does it work as is if an internet connection is temporarily lost?

the request fail, if there is an option to queue the request
the whole request is stored with its current timestamp in an array (FIFO, First in first out),
a "global loop" check for entries in the array and if it find some entries it fire them with
the Queue Time parameter setup with the timestamp.

Does a screenview get completely missed if it's sent while there is no connection?

with a mechanism to queue the requests when they fail nothing should be completely missed as long as the timestamp is not older than 4h, a limitation of the Queue Time parameter

Doing it this way should allow to cover both Flash and AIR (and even Redtamarin), avoid the classic problem of polling on a URL to check if there is a connection or not (see Unusual traffic from your computer network), and be able to avoid to track the order of requests.

For example, if you send 10 screenviews, but at the time of screenview 6 and 7 the requests failed (internet connection problem, switch from wifi to other, etc.), then the following requests 8, 9 10 pass through, the array of stored failed request would kick-in after that and resend screenview 6 and 7.

Because Google Analytics backend register the hit either when it is received or based on the Queue Time parameter, even unordered requests should be able to be register at the right place and time.

The goal is to keep it simple, make it not the default behaviour but "user actionable",
for example in Configuration add a property enableQueueing.

@matt-shoesmith
Copy link

That's amazing! Thanks for your answer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants