Record IDFV For Internal Billing

[bleege]

In order to Mapbox to monitor usage for billing purposes, it needs to be able to count the number of Unique Users per customer. This will be done using the iOS's IDFV.

One MapboxEndUser event will be sent to the Mapbox Events API from the MGLAccountManager constructor. This is possible because all implementing apps will need to / eventually will call directly or indirectly (ex: -[MGLMapView setAccessToken]) at some point:

• +[MGLAccountManager setAccessToken:]
• +[MGLAccountManager setMapboxMetricsEnabledSettingShownInApp:]

@mapbox/mobile @mapbox/mobiledata @pdgoodman

[1ec5]

One MapboxEndUser event will be sent to the Mapbox Events API from the MGLAccountManager constructor.

Will it still go through MGLMapboxEvents, or will MGLAccountManager now be responsible for sending HTTP requests too?

all implementing apps will need to / eventually will call directly or indirectly (ex: -[MGLMapView setAccessToken]) at some point:

With #1553, MGLAccountManager and MGLMapboxEvents will have code that runs immediately at startup, as long as the account token is set in the Info.plist (which is the route I’d expect most developers to take), but in +load and +initialize, which are expected to do noninvasive tasks only.

[bleege]

Will it still go through MGLMapboxEvents, or will MGLAccountManager now be responsible for sending HTTP requests too?

I'm torn, but I'm leaning towards MGLAccountManager as it keeps this completely separate from Metrics and the benefits of not instantiating it if not needed. It's unclear if we'll have to do URL checking on this re #1396.

As for implementation, I'm thinking that an Async HTTP GET could be fired off from +MGLAcountManager sharedManager with just the event name and the IDFV value.

@1ec5 What do you think ^ ?

[1ec5]

I'm torn, but I'm leaning towards MGLAccountManager as it keeps this completely separate from Metrics and the benefits of not instantiating it if not needed.

MGLMapboxEvents is always instantiated as of #1491. You’re thinking of MGLMapboxEventsData. If you put this in MGLAccountManager, you’ll want to factor out the guts of -[MGLMapboxEvents URLSession:didReceiveChallenge:completionHandler:].

I'm thinking that an Async HTTP GET could be fired off from +MGLAcountManager sharedManager with just the event name and the IDFV value.

That may work for now, but #1553 would cause +[MGLAccountManager sharedManager] to be called from within +[MGLAccountManager load], and I think it’d be bad for any class’s +load to attempt network requests.

[bleege]

Ah yeah... was just noticing that there's always and instance of MGLMapboxEvents thanks to this.

think it’d be bad for any class’s +load to attempt network requests.

Agreed. The logical way now seems to add this as a regular event and do a quick flush from the startup block in +[MGLMapboxEvents sharedManager]. It also has the added benefit of getting to reuse the events transportation infrastructure.

[bleege]

@1ec5 When you have a second can you walk through f3d7212 to make sure that it makes sense? Testing confirms that it works, but I'd like some fresh 👀 to make sure that it does fire with all the opt out scenarios.

[bleege]

Thanks for the feedback @1ec5. Could I trouble you one last time to review the workaround for Turnstile events? I've tested on device and it works in both Opt In and Opt Out.

To be clear, when Opt Out is enabled this is the ONLY event that always gets sent in. This is done in order to reuse MGLMapboxEvents infrastructure and security model.

[bleege]

Latest rounds of feedback enhancements have now been made and tested. Will wait for Travis to complete and will then merge.

[bleege]

Refactored, Tested, Travised, and now Merged.