Sitata / titanium-google-analytics

Google analytics for Appcelerator Titanium
MIT License
92 stars 47 forks source link

Dispatch Interval #34

Open danny005 opened 9 years ago

danny005 commented 9 years ago

According to the example in app.js

// Data collected using the Google Analytics SDK for Android is stored locally before being // dispatched on a separate thread to Google Analytics. // By default, data is dispatched from the Google Analytics SDK for Android every 30 minutes. GA.dispatchInterval = 15; // minutes

Looking at the official documentation, it looks like the unit is in seconds for iOS and minutes for Android.

https://developers.google.com/analytics/devguides/collection/ios/v3/dispatch https://developers.google.com/analytics/devguides/collection/android/v3/dispatch

I've looked into the java and obj-c code of this module. There is no conversion of the unit so I guess I have to set the dispatchInterval depending on the OS in the JS code to have it behave identical?

if(Ti.Platform.osname == 'android') {
    GA.dispatchInterval = 2; // in minutes
}
else if(Ti.Platform.name == 'iPhone OS') {
    GA.dispatchInterval = 120; // in seconds
}

Can someone confirm this?

Thanks Danny

astjohn commented 9 years ago

@danny005 Good catch. Unfortunately, this is an oversight, but I have just changed the readme to reflect this. In a future version, we should normalize the value to seconds so I will keep this issue open as a reminder to do so. Thanks!

hengsok commented 8 years ago

Hi all,

I believe there is a confusion in this. From what I have found out, the setLocalDispatchPeriod is in seconds all along since v3.

You can see here. Although they mentioned every 30min which Danny might have confused, they mentioned again in the code "Set the dispatch period in seconds." https://developers.google.com/analytics/devguides/collection/android/v3/dispatch#overview

Likewise, for v4, it also says "Set the dispatch period in seconds." https://developers.google.com/analytics/devguides/collection/android/v4/dispatch#overview

When I decompile google play services jar file to analyse, it was in seconds too.

void setLocalDispatchPeriod(int dispatchPeriodInSeconds)

You can also see it here https://developers.google.com/android/reference/com/google/android/gms/analytics/GoogleAnalytics.html#public-method-summary

So admin please update the README file accordingly to prevent others from confusing.

hengsok commented 8 years ago

I have tested it and it is proven that the time is in seconds.

You can try to turn on debug mode and observe when it sends batch hits according to the interval you set.

Sometimes, you can't deduce the logic based on battery. 30s is just an example and not a requirement.

On Apr 1, 2016, at 19:16, Adam St. John notifications@github.com wrote:

@hengsok I'll try to decompile the jar file and take a look as well. The only way to determine what is truly the value isn't the method definition, but the code that's inside it which implements the actual timing. The documentation on Google is actually contradictory. https://developers.google.com/analytics/devguides/collection/android/v4/dispatch#periodic

On that link it clearly states:

By default, data is dispatched from the Google Analytics SDK v4 for Android every 30 minutes. To set the dispatch period programmatically:

// Set the dispatch period in seconds. GoogleAnalytics.getInstance(this).setLocalDispatchPeriod(30); Note that the code comment they used contradicts the description.

30 minutes instead of seconds is a much more sane value to use when communicating with a server intermittently and so I'm partial to think that it's actually minutes. Otherwise the app would consume too much battery.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

astjohn commented 8 years ago

Understood about the example. I’m not basing any decision on the battery assumption.

If you send me your logs then we can prove that the time is in seconds. Otherwise, I’ll have to decompile the jar and take a look at the internals because we also can’t deduce the logic based on the method definitions since there is a clear discrepancy in the documentation.

If you can’t send any logs, then I’ll try to do as you suggest as well and observe when the batch hits are sent.