Closed samgiles closed 8 years ago
Argh, I just realised formatting and indenting is gonna be all over the place because of my defaults. Actually wasn't that bad.
Looks like you've arrived at a nice solution, ♠️ce!
Before landing:
api
interface as it's not HTTP and not a magnet-service API. Sorry if this wasn't clear before :( Let's expose a dedicated track
native API that can replace the tracking.js
module we have right now.react-native-google-analytics-bridge
?Also what is this for?
$ adb shell setprop log.tag.GAv4 DEBUG $ adb logcat -v time -s GAv4
I've ended up making a massive patch that will remove the bridge. It's in the no-bridge
branch.
I disagree that this isn't an HTTP API/magnet service thing. Essentially it is - we just happen to use GA as the backend. In the future, I see us wanting to have our own analytics backend for tracking beacons discovered, beacon health etc. It seems to make sense to make use of the API mechanism. It's nice and generic. It means when we want to add our own tracker for something, we just create a new CallableTracker
instance, and start calling stuff in the frontend.
I can see this going either way thought tbf. I mean we could expose each magnet thing as a library for example, either way I'm happy to compromise, this was just easier to implement.
The shell stuff was to turn on the Analytics logging, and then filter only Google Analytics logs, helps you see what's going on.
Replaced by WIP in #349
This also means we can remove the bridge at some point. Will have to be a follow up. The advantage of this is that checking whether we need to send a tracking event at all is entirely contained in the API.
Adds a
NoopCallback
static instance as a convenience for not caring about the result. Adds to.gitignore
for vimswp
files.For now it uses the wrapper around the GA lib that the bridge has, but we can extract that code into this repository at a later date.
I did test this using adb:
r? @wilsonpage