Architecture overhaul (SDK 2.0) #148
Conversation
Event.class is responsible for encoding, not Tracker.class or Dispatcher.class, this simplifies testing as less parsing/conversion is necessary, meaning more directly testing what needs to be tested in each class.
Removed QueryParams that only work in conjunction with an auth_token. It was not working correctly anyways as only POST not GET transmissions contained an auth_token.
DryRun option can now be set per Tracker.
…houldn't enforce this. By moving it to Piwik.class and making the constructor public we allow devs more choice over `Tracker` creation (especially using multiple trackers.
Refactored classes to allow for better testing and injecting mocks.
Each Tracker can now have their owns settings. Previously Tracker objects would affect each others settings. Each Tracker now gets a unique name to allow retaining settings even if URL or ID changes.
|
✨ |
Core = Piwik, Tracker, TrackMe, QueryParams (+ internal dispatcher implementation) Extra = Everything else.
…ables with Custom Dimensions. Also: Previous use of CustomVariables was flawed. Transmission with every track was superfluos (waste of traffic).
Usage examples can be seen here: ba25abf#diff-a9f2a402bc64d1dc87638db64836ec35 |
…d custom variables even if we deprecate them.
|
Migrating from CustomVariables to CustomDimensions is not possible without data loss, or is it? |
|
I know it's quite a handful of changes, but I felt that this was necessary to future proof the SDK. A modern Piwik 3.0 deserves a modern Android SDK... I need help with making sure that the server-side analytics is not affected by these changes. I've done testing in my own app and with the example app, would be good if we could get a few more apps to test that switching doesn't alter analytics. Guide:
|
Brilliant! @d4rken I'll look at this for sure, but it will take some time, so please be patient ;) BTW what do you think about releasing current |
|
Hello, I have done a release (stable) of my app with what @dotsbb call 1.1.0 and add +optout, optin wifi, optin always mode (only one check). I will include and test 2.0 in my beta release in next days (one week max), I have a bunch of thing to do on other stuff. Maybe it's a good idea to release a 1.1.0, keep dev for 1.1.n, and have a 2.0 beta branch with its own dev ? Thanks, Eric |
Don't really like it, because the offline mode is a change that will affect not only analytics but also app behavior (storage, traffic). I would prefer this comes along with a breaking change so devs are aware of what's new. I think we could change the dev code branch such that offline mode is disabled by default, tag that as v1.1.0 and release.
I don't think it's necessary to split development of 1.X and 2.X, after some testing/review from you @dotsbb we can merge this into dev. Worst case: We make a PR against master to fix a bug 😁 . |
Could you make a PR of these changes against the current dev branch? I would like to look at them and maybe we include it in a 1.1.0 release. What do you think about disabling offline mode by default? |
As I use "Opt-in" in my app, user must say YES to send datas, if user don't, no datas are collected and dispatched, so no connexion needed, no connexion choice to do. Some others devs, may prefer to use "Opt-out" : user must say NO, if user don't, datas are collected and dispatched, so connexion choice may be given. In EU, and in France (I better know), from legal point of view, "Opt-in" is always the final choice, on existing legislation or when a new one is made. As I have used/tested some other tools, before to make PIWIK choice, a lot of them are "Opt-out", or better done to use it. So for some, enable connexion by default will be good, others may have or prefer to have it defaulted to disable.
I will do it before end of week |
|
@eldk I was refering to offline mode, not all data collection. I think we should disable offline mode by default in 1.X and enable it by default in 2.X. |
|
I've gone with @eldk's idea and created a |
Architecture rework for a 2.0 release.
Notes:
auth_tokenwhich was previous depcrecated has now been removed from code, including allQueryParamsthat only work in conjunction with a token. IOS SDK also does not support it and using it was semi broken because the token was only supplied when doing POST, but not in GET requests.Trackernow has it's own settings object, which paves the way for multiple Trackers (with different endpoints). To support different preferences, but still allow changing domain names or site IDs, a unique name needs to be supplied duringTrackercreation. The classLegacySettingsPorterports previous settings over to the firstTrackercreated.opt-outaction now takes effect retroactively and also wipes out the Dispatchers queue and offline cache.