B2G/Bluetooth/WebBluetooth-v2/Discussion/2014-03-14
From MozillaWiki
< B2G | Bluetooth | WebBluetooth-v2
Contents
Info
Attendees
- BT team: Eric Chou, Gina Yeh, Ben Tian, Shawn Huang, Jamin Liu, Jocelyn Liu
- Gaia: Arthur Chen, Ian Liu, Evelyn Hung, Alive Kuo
- WebAPI: Gene Lian
Time & Location
3pm - 6pm @Utopia
Meeting Minutes
Meeting minutes by Jamin Liu
Response to Suggestions
- Revision (2014-05-12)
- 13) Should we rebind handlers for adapter after it's been disabled ? (Evelyn)
-
YES. To be consistent with attributes, the event handlers should also be reset as default value (nullptr). Application should rebind all handlers after adapter is re-enabled. - NO. The event handlers are kept until applications remove them. The reason is that applications are unaware of the reset by gecko and assignments of reset event handlers cause unexpected behavior.
- Example
var adapter = navigator.mozBluetooth.defaultAdapter; var device = PairedDevice; device.attributechanged = adapter.onattributechanged; adapter.disable().then { function onResolve() { console.log("Resolved with void value"); // device.onattributechanged becomes nullptr but application is unaware! }, function onReject(aReason) { console.log("Rejected with this reason: " + aReason); });
BT Team Internal Discussion Result
BluetoothManager
- Access adapter in onadapterremoved
- onadapterremoved(address) -> onadapterremoved(adapter) before adapter is really removed? adapter's attributes are accessible with default values.
- (Unchanged) Yes. Remove.
- Remove adapter from adapters[] array or not?
- gaia has to rebind handlers if adapter is removed from array.
- (Unchanged) Yes. Remove.
- Track default adapter added/removed - options
- +ondefaultadapteradded/ondefaultadapterremoved
- onadapteradded/removed(adapter, bool isDefault)
- bool adapter.isDefault
- Option 2
BluetoothAdapter
- adapter state
- add "discovering" and "discoverable"?
- add "pairing", "connecting", and "connected"?
- outgoing vs incoming pairing/connection state transition
- (Unchanged) No for both. Reason - 1) independent states from enabled/disabled 2) we cannot ensure correct 'pairing'/'connecting' transition for incoming pairing/connection.
- adapter attributes validity
- are all attributes available after state is "enabled"?
- (Unchanged) No. Just forward what we get from backend and we don't ensure the sequence.
- DOMRequest life cycle
- should gaia hold req reference until stop discovery?
- YES. gaia should hold reference if req is still needed.
- does DOMRequest live after onsuccess is fired?
- YES. the life cycle ends when both gaia and gecko release the req. (by schien)
- fire onsuccess before or after ondevicefound?
- should gaia hold req reference until stop discovery?
- (Unchanged) before. Note BluetoothReplyRunnable frees the DOMRequest object after onsuccess is fired.
- Return BluetoothDevice in pairing event handlers
- carry correct address
- what are the value of the device's attributes?
- Carry a handle. pros over func ptr - signature & address.
[chrome only] interface BluetoothPairingObject { void setPasskey(DOMString passkey); readonly BluetoothDevice device; }
- Move pairing event handlers into device?
- (Unchanged) No.
- Can application start discovery while adapter is discovering?
- No. It gets onerror. Applications have to stop current discovery first.
- When adapter.state becomes "disabled", should all its attributes become default values and onattributechanged are fired?
- Yes. As state becomes "enabled" for consistency.