Eddystone beacon support

[plrdev]

Eddystone beacon support would make this awesome, but as far as I can see, iBeacon is only supported.

[MacKentoch]

Hi @eduplus

Great idea.

• For Android it would be straightforward, I would just blindly follow altbeacon example and bridge it.
• For iOSI have no idea what it would require right now but I guess it should not be unbearable task

But at the end, I need to emulate an eddystone beacon to develop and test.
That is where the critical part is.

[plrdev]

I have taken part in implementing Eddystone with altbeacon on Android, but not on iOS. I also have an Eddystone beacon that I can do tests and I am willing to test if you are able to add the support.

[ismaeldcom]

Hi @MacKentoch

I can help with the iOS implementation, for emulation I use beacon simulator for Android and any BLE Android device and it works fine.

[MacKentoch]

Hi @ismaeldcom

Any help is always welcomed.
Feel free to submit PR.

My main concern was this issue (when I merged android part, altbeacon was already updated: I guess it comes from that).

Maybe I may focus on extending functionalities rather fighting against android backward compatibility

[MacKentoch]

I forgot something important: thank you 💯 @ismaeldcom for beacon simulator: really awesome and useful!

[MacKentoch]

Alright as I fixed the issues on android 6, time has come to add Eddystone support.

For sure it is great feature to add.

[ismaeldcom]

Hi @MacKentoch

I have a Eddystone implementation for a very specific case, I spent a couple of hours trying to implement it with your lib and make a PR, but I think this might be very complex, if you want to maintain a unified API. Because Eddystone have 4 different protocols and don't share any common property with iBeacon.

Anyway, If you like to try it, you can see a old implementation from christopherdro. Based on Google implementation, which have a new version of the code.

With this you can cover UID, URL & TLM.

[MacKentoch]

Hi @ismaeldcom

Thank you very much for information and link.

I had a look at Google implementation too here so both example should help.

I'm not sure but if I point my index finger in the air (I don't know, it is just suggestion or idea I have) I would say that I may implement something like:

Beacon.startIBeacon // if user want to start iBeacon (instantiates native iBeacon specific classes)

Beacon.startEddystone // if user want to start Eddystone (instantiates native iBeacon specific classes)

It will look like altBeacon library that handles multiple types of beacon.

[plrdev]

@MacKentoch Your plan sounds good.

I would also prefer similar handling than what altbeacon does. You can just tell what kind of beacons you are interested in and then get monitor/ranging data, where you can check the type and work accordingly to that specific type of beacon.

[MacKentoch]

Yes I'm working on a standardisation of both iOS and Android (as much as possible).

It is more coherent is easier to play with if it is nearly the same for both platform.

I'm really excited on adding Eddystone but I first have to fix all inherited bugs (bugs from original versions that I discover super fast thanks to helpful contributions).

I'm currently fixing this major one on iOS #9

[MacKentoch]

I updated README and add a TODO so that you exactly know what I'm preparing/doing.

TODO List is opened to suggestions.

This lib is not mine it is open source so it is ours.

[rrjanbiah]

I'm a newbie. But, in my understanding different standardization is not possible (that is obvious when you check https://play.google.com/store/apps/details?id=net.alea.beaconsimulator ) Google's Nearby API seems the only standardization, if I'm right.