This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
Add option to configure CLLocationManager activityType #2149
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proof of concept to illustrate (and get feedback about) exposing location manager options so a client can have some say about how active the location manager will be when it runs in the background.
Since the MGLMapboxEvents is a singleton and because it has not (historically) been directly exposed
to client code, it does not lend itself to configuration. I worked around this (for now) by proxying
config calls via the MGLMapView which is sort of the main interface to the library for a client. This approach may actually be ok but the names I chose for the API should probably be made better. We could also consider creating some sort of configuration object that a user creates and passes in. The important point is that the configuration must happen before
MGLAccountManager.setAccessToken
is called since that is what actually starts the metrics location tracking process.In a client app, the usage of this new feature looks like this:
In short; this works but the impl feels a little weird because of MGLMapboxEvents singleton-ness and also because of the call dependency that leaks through to the clients. Ideally, I would want some sort
of
setUp:
API that takes an access token and config options but, currently, MGLAccountManagerdoes not seem like the right object to build something like
setUp
on top of.Finally, it might be even more useful to use something like this pattern to allow users to set
distanceFilter
anddesiredAccuracy
. Those options might do even more to mellow out the background activity and not having control over them (as a client) would make me somewhat concerned. Don't want this to turn into a 747 flight deck though