B2G/Bluetooth/WebBluetooth-v2/Discussion/2014-03-14

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

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?

(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.