Closed ergunkocak closed 7 years ago
@ergunkocak very very late reply but I just found some time to spare. I actually designed this library to use for different build types but somehow, gradle didn't work as I expected. I'll definitely make changes for this. Currently I removed tracklytics.properties files and as a practice, public api keys can be actually used through gradle. Build types are quite good for that purpose. Thanks for the detailed feedback
@ergunkocak I changed the tracklytics implementation. All tool implementations will be up to the developer from now on. I think that's the best and flexible way. As I suggested above, the best way to differentiate API Keys is using gradle build type or flavor.
Closing this issue for now due to pivoted project. @ergunkocak thanks for the suggestions though
In my project we use out source teams and i do not want to share our live API Keys with them so i create 2 different project on Google Console and generate 2 different sets of keys. To enable this with Tracklytics i did this :
Result :
I used build.properties.debuggable and set it false for release buildType and true for debug buildType because i could not see different tasks for release and debug in build log. It may be good if there are seperate tasks as " processDebugGoogleServices & processReleaseGoogleServices " in addition to / instead of prepareComOrhanobutTracklyticsTracklyticsRuntime013Library . Or they exists and i could not see :(
I am not a master so i am very open to change the way i did it if this is not the way to do these kind of stuff.