Add a Physical Web data source

components/physical_web/data_source/physical_web_data_source.h

+// Copyright 2016 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 COMPONENTS_PHYSICAL_WEB_DATA_SOURCE_PHYSICAL_WEB_DATA_SOURCE_H_
+#define COMPONENTS_PHYSICAL_WEB_DATA_SOURCE_PHYSICAL_WEB_DATA_SOURCE_H_
+
+#include <memory>
+
+#include "base/values.h"
+
+// Helper class for accessing Physical Web metadata and controlling the scanner.
+class PhysicalWebDataSource {
+ public:
+  PhysicalWebDataSource();
+  virtual ~PhysicalWebDataSource();
+
+  // Returns the global instance of the PhysicalWebDataSource singleton. This
+  // does not create the singleton and will return NULL if an instance has not
+  // yet been set with SetInstance.
+  static PhysicalWebDataSource* GetInstance();

[blundell, 2016/07/28 11:12:25]

Singletons are generally an anti-pattern. Is there any particular reason that
this needs to be a singleton (as opposed to e.g. being a KeyedService with one
instance per Profile/ChromeBrowserState)?

[mattreynolds, 2016/07/29 01:36:31]

I don't think there's any issue with running multiple instances of the scanner,
but we should limit Chrome to a single instance if possible since the scanner
caches a list of all nearby URLs and requests metadata from our server for each
one.  I don't expect the amount of memory used by the list to be very large
(typically less than a dozen beacons, with <1 kB metadata for each) but it would
be best to not duplicate it unnecessarily or cause extra load on our metadata
service.

In what situations does Chrome use multiple profiles?  I suspect on mobile it's
only for incognito, and we'll likely want to disable physical web features on
incognito anyway so there will typically only be one active scanner.  However,
we wouldn't want to fetch the same metadata more than once on platforms that
support multiple logged-in profiles.

I think we could justify keeping this as a global singleton since the
information it provides is tied to the user's device and shouldn't differ
between profiles.  ClipboardRecentContent is a singleton that solves a similar
problem -- clipboard content is also tied to the device and shouldn't differ
between profiles.

+
+  // Sets the global instance of the PhysicalWebDataSource singleton.
+  static void SetInstance(PhysicalWebDataSource* instance);
+
+  // Starts scanning for Physical Web URLs. If |network_request_enabled| is
+  // true, discovered URLs will be sent to a resolution service.
+  virtual void StartDiscovery(bool network_request_enabled) = 0;
+
+  // Stops scanning for Physical Web URLs and clears cached URL content.
+  virtual void StopDiscovery() = 0;
+
+  // Returns a list of resolved URLs and associated page metadata. If network
+  // requests are disabled, the list will be empty.
+  virtual std::unique_ptr<base::ListValue> GetMetadata() = 0;
+
+  // Returns boolean |true| if network requests are disabled and there are one
+  // or more discovered URLs that have not been sent to the resolution service.
+  virtual bool HasUnresolvedDiscoveries() = 0;
+};
+
+#endif  // COMPONENTS_PHYSICAL_WEB_DATA_SOURCE_PHYSICAL_WEB_DATA_SOURCE_H_