bluetooth: Browser side partial implementation of getPrimaryService.

content/child/bluetooth/bluetooth_primary_service_request.h

Index: content/child/bluetooth/bluetooth_primary_service_request.h
diff --git a/content/child/bluetooth/bluetooth_primary_service_request.h b/content/child/bluetooth/bluetooth_primary_service_request.h
new file mode 100644
index 0000000000000000000000000000000000000000..d81ee796e5d077db587d2647a6cca94c7ed929aa
--- /dev/null
+++ b/content/child/bluetooth/bluetooth_primary_service_request.h
@@ -0,0 +1,27 @@
+// Copyright 2015 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.
+
+#ifndef CONTENT_CHILD_BLUETOOTH_BLUETOOTH_PRIMARY_SERVICE_REQUEST_H_
+#define CONTENT_CHILD_BLUETOOTH_BLUETOOTH_PRIMARY_SERVICE_REQUEST_H_
+
+#include "base/memory/scoped_ptr.h"
+#include "third_party/WebKit/public/platform/modules/bluetooth/WebBluetooth.h"
+
+namespace content {
+
+struct BluetoothPrimaryServiceRequest {

[Jeffrey Yasskin, 2015/05/29 20:31:42]

I'd default to just defining this in the single .cc file that it's used.

[scheib, 2015/05/31 19:48:41]

I suspect this is based on a conversation ortuno and I had where I lamented
multiple classes defined in a single .h file. E.g. 
device/bluetooth/bluetooth_discovery_session.h
containing the related BluetoothDiscoveryFilter class.

I agree that a class/struct used in only one implementation file is appropriate
to be contained at the top of that file unless it becomes rather large and
unwieldy. BluetoothPrimaryServiceRequest is fine in just the
bluetooth_dispatcher_host.cc.

BluetoothDiscoveryFilter, on the other hand is used by multiple other
compilation units, and though not required I prefer it to be in
bluetooth_discovery_filter.h instead of joined in bluetooth_discovery_session.h.

[Jeffrey Yasskin, 2015/05/31 21:11:12]

SGTM. I think the argument to split classes out into their own files gets
stronger as the classes get more widely used and more complicated. If
BluetoothPrimaryServiceRequest were its current complexity but its header were
included by multiple other .cc files, I'd be on the fence about where to put it,
and reasonably happy to see it in its own header in order to make users' lives
easier. If it were the complexity of BluetoothDiscoveryFilter but only used in
bluetooth_dispatcher.cc, I would similarly be happy to see it defined in a
header rather than bluetooth_dispatcher.cc, so it could be unittested. It's only
because the class is so simple and can be defined completely in a single .cc
that I'm suggesting putting it there.

[ortuno, 2015/06/01 18:27:03]

Done.
Hm I was having some trouble with the compiler not allowing me to define a
"complex" struct in the cc file. But now it works.

+  BluetoothPrimaryServiceRequest(
+      blink::WebString device_instance_id,
+      blink::WebString service_uuid,
+      blink::WebBluetoothGetPrimaryServiceCallbacks* callbacks);
+  ~BluetoothPrimaryServiceRequest();
+
+  blink::WebString device_instance_id;
+  blink::WebString service_uuid;
+  scoped_ptr<blink::WebBluetoothGetPrimaryServiceCallbacks> callbacks;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_CHILD_BLUETOOTH_BLUETOOTH_PRIMARY_SERVICE_REQUEST_H_