chrome.bluetoothLowEnergy: Introduce connect and disconnect methods.

chrome/browser/extensions/api/bluetooth_low_energy/bluetooth_low_energy_connection.cc

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/extensions/api/bluetooth_low_energy/bluetooth_low_energy_connection.h"
+
+namespace extensions {
+
+static base::LazyInstance<BrowserContextKeyedAPIFactory<
+    ApiResourceManager<BluetoothLowEnergyConnection> > >
+        g_factory = LAZY_INSTANCE_INITIALIZER;
+
+template <>
+BrowserContextKeyedAPIFactory<
+    ApiResourceManager<BluetoothLowEnergyConnection> >*
+ApiResourceManager<BluetoothLowEnergyConnection>::GetFactoryInstance() {
+  return g_factory.Pointer();
+}
+
+BluetoothLowEnergyConnection::BluetoothLowEnergyConnection(
+    const std::string& owner_extension_id,
+    scoped_ptr<device::BluetoothGattConnection> connection)
+    : ApiResource(owner_extension_id),
+      connection_(connection.release()) {
+}
+
+BluetoothLowEnergyConnection::~BluetoothLowEnergyConnection() {}
+
+device::BluetoothGattConnection*
+BluetoothLowEnergyConnection::GetConnection() const {
+  return connection_.get();
+}
+
+bool BluetoothLowEnergyConnection::IsPersistent() const {
+  return true;
+}

[keybuk, 2014/06/19 17:23:49]

I leave it up to kalman to decide whether having a persistent api resource is a
good thing or not

[not at google - send to devlin, 2014/06/19 17:27:09]

I'm quite sure we do want this, it's important for event pages. But double-check
with Renaud to make sure I understand it correctly. I've never dealt with this
code before.

[rpaquay, 2014/06/19 19:07:26]

Hmm... I don't quite know the use cases for this API, but what I can say is
that:

By making the connection persistent, we are saying that "disconnect" will be
called *only* when either
1) The app calls "disconnect" explicitly, or
2) The Chrome browser process shutdowns.

In particular, this means "disconnect" will *not* be called when an app is
unloaded due to idle time (that includes the common scenario of an app closed
through the user closing the last opened window of the app).

If this is the behavior we want, I would think we need to document it in the
"connect" method, as this is clearly different than the default behavior of
connect/disconnect for sockets, for example.

Another option would be to expose to "persistent" flag through the API, if we
think both use-cases are needed.

[armansito, 2014/06/19 21:58:34]

After offline discussion with rpaquay@, I added an optional ConnectProperties
dictionary argument to connect with "persistent" field. If the field is not
provided, then the default value will be false.

+
+}  // namespace extensions