-
Notifications
You must be signed in to change notification settings - Fork 837
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved BeaconParser API #1052
Comments
Thinking more, the system probably should still support wildcard regions. It is common to do this with the current api:
The above will match all beacons of all formats for registered beacon parsers. This is highly useful for many cases and less awkward than registering multiple wildcard regions, one for each beacon parser. This should still be supported somehow, perhaps like this:
Similarly, we could allow setting a default beacon parser for the common case where users only use one at a time, for example:
Then once the above is set, any calls to the old, non-explicit syntax will work without warnings:
The above would effectively be the same as this:
|
Closed in favor of #1061 |
The Problem
Failing to configure the proper BeaconParser is a common source of frustration with library users. Library users often don't realize the library only detects AltBeacon out of the box, and then are disappointed when their code fails to detect their beacon that advertises the Eddystone or iBeacon format. The library needs to make this step easy and obvious.
Constraints
This proposal for improvement in the library API is designed to stay within the following constraints:
Proposal
Modify the
Region
class so that theBeaconParser
is specified for each region. Instead of registering newBeaconParser
s with theBeaconManager
, the user will have no choice but to specify theBeaconParser
at the time aRegion
is constructed to start ranging or monitoring. This will make it obvious to users what kind of beacon they are telling the library to look for.Under the hood, the library will register a new parser as needed if the parser specified in the region has not yet been added. When ranging or monitoring are stopped, if no remaining region uses a parser, that parser will be removed.
Example
instead of:
The new API would be this:
or perhaps
Deprecation Plan
The old API where a Region is constructed without specifying a parser will be deprecated with a warning added in the log when used. The
beaconManager.getBeaconParsers()
will be deprecated as well.The text was updated successfully, but these errors were encountered: