check platform via bleno in case were behind a websocket

[jacobrosenthal]

for #23

[jacobrosenthal]

This needs to get fixed, I need a to get platform check seperated from websocket stuff, unless we can just get that all merged

[sandeepmistry]

Separating it would be great. The characteristic request handling is still WIP right?

[jacobrosenthal]

Hrm. So this works on linux. But on osx 10.10.5 with the uid examples only Im getting xpcError: connection interrupted now
https://gist.github.com/jacobrosenthal/3d35e7e5390da73129cc

[jacobrosenthal]

ugh. duh, were back to an async timing issue. Beacon is accessing the property while its still unknown before the bindings return.

Jacobs-MacBook-Air:node-eddystone-beacon jacobrosenthal$ node examples/uid/with-tlm.js 
beacon platform unknown
bleno platform darwin
xpcError: connection interrupted

The point of my previous implementation was to hold back the initial state change emit in bleno until i got the platform, but were not doing that anymore now that its in bindings.

[jacobrosenthal]

No.. nevermind, we got that with the emit platform in child_process.

The problem is we generate advertisement data when user calls advertiseUid, (thus only doing it once) but this happens before bleno.platform has been set as state hasnt even been reported as powered on yet. Advertise actually waits for that later.

We could make a copy of all the advertising properties and generate later, but that feels gross.
Or we could not accept advertise() if we're not powered on... (ie become more like bleno)

[jacobrosenthal]

quickest fix would be for me to go back to generating flags and stripping them off when statechange fires

[jacobrosenthal]

Blah. Cant do that. _updateAdvertisementDataIfNeeded calls advertiseTlm directly, which would then not have its flags stripped

[sandeepmistry]

I think we need to expose the adapter state to the user like discussed in: #25 (comment)