Beacon Model questions

[yodutouf]

Today the library uses a very generic "Beacon" Object. Frames emitting by a "physical" beacon are parse as a generic "Beacon" object (eddystone-url, eddystone-uid, altbeacon, ibeacon etc..)

But like there is more frames, I find this "Beacon" Object not enough clear. What do you think about using an explicit "Beacon" object for each frame (eddystone-url etc..) ?

A- What do you thing about the following possibility ?

1- A Beacon Interface with 3 methods

public int getServiceUuid()
public int getBeaconType()
public List<Beacon> getExtraBeaconInformations() -> permits to get extra information like eddystone-tlm

2- Two annotations for parsing the data

• '@'BeaconParser(start=12,end=16) -> to parse the data
• '@'BeaconExtra -> to indicate it's an extra beacon information

  3- Creating explicit objects for parsing the frames implementing the interface and using the annotations.

For exemple

public class BeaconEddyStoneUid implements Beacon{
    '@'BeaconParser(start=0, end=1)
    public int serviceId;
    '@'BeaconParser(start=2, end=2)
    public int beaconType
    '@'BeaconParser(start=11, end=20)
    public String id1;
    '@'BeaconParser(start=21, end=26)
    public String id2;
}

'@'BeaconExtra
public class BeaconEddyStoneTlm implements Beacon{
     '@'BeaconParser(start=0, end=1)
      public int serviceId;
      '@'BeaconParser(start=2, end=2)
      public int beaconType
      public 
}

4- Adding to the BeaconParser the ability to create parser from annotation

beaconParsers.add(new BeaconParser.setBeacon(BeaconEddyStoneUid.class));

B- Perhaps we could go a step further, but breaking the model, seeing the beacon as a list of frames

1- The Beacon is an object with

• beacon uid (the uid of the machine)
• List < BeaconFrame >

  2- The Beacon interface is becoming a BeaconFrame Interface and the BeaconEddyStoneUid is becoming :

public class BeaconFrameEddyStoneUid implements BeaconFrame 

3- There is no more extra informations

[davidgyoung]

Interesting ideas. Much of the class models and interfaces has slowly evolved over time from a library devoted to parsing only iBeacon transmissions, so I agree that there are opportunities for making the API more streamlined to support different beacon types like Eddystone. A critical factor is that any breaking change in the API would have to be held off until a 3.0 release so that users of 2.x versions of the library can upgrade without having to recode their apps.

Thoughts on a few particulars:

A1: I certainly agree a beacon type identifier is long overdue, so there is an easy way of telling if a beacon is an Eddystone-UID or an AltBeacon. The type identifier is closely related to the parser.

A2/A3/A4: I think the idea of annotations for beacon layouts is interesting and attractive. One disadvantage is that this mechanism for specifying beacon layouts is specific to Java, and the beacon layout string scheme has been used on cross-platform projects in ObjectiveC , C# and Ruby. As a result, I wouldn't want to replace the string layout. But a mechanism like this could augment it.

B: I agree that the "extra" info is not an elegant API and deserves a replacement. Your idea is a good one. I'd prefer a slightly more generic implementation that simply allows access to a list of other visible beacon objects from the same physical device as keyed by the mac address. Which could be accessed by something like: beacon.getDevice().getBeacons(). Part of the challenge of doing this is making this more complex class model implement the Parcelable interface.

[yodutouf]

A : I agree with you. I see this in complement of the beacon layout string scheme. It's possible to keep the "generic Beacon" Object. It just needs to implements the interface.

B: mac address is not enough. I know partner that put the same for all their beacons, but we could use the mac address with the serial number.

B: From my point view, it's simple to get a "Beacon Device" object that give all the "Beacon Frames" (beacon Frame is what is called Beacon for now into the library) So we do directly : beaconDevice.getBeaconFrames() or perhaps it's better to put frame into a map to get a really easy access : beaconDevice.getBeaconFrames(serviceId, beaconType)

As consequence the ranging interface will return a "Beacon Device". I see it simple to use when coding with the library, and simple to implement serialization with parcelable (a little).

When do you plan the 3.0 version ? When we agree on the specification of this feature, I could see to participate to implement it.