[CrOS Tether] Create TetherHostResponseRecorder, which records ConnectTetheringResponses and Tether…

chromeos/components/tether/host_scan_device_prioritizer.h

 // Copyright 2017 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 CHROMEOS_COMPONENTS_TETHER_HOST_SCAN_DEVICE_PRIORITIZER_H_
 #define CHROMEOS_COMPONENTS_TETHER_HOST_SCAN_DEVICE_PRIORITIZER_H_
 
 #include "base/macros.h"
 #include "components/cryptauth/remote_device.h"
 
-class PrefService;
-class PrefRegistrySimple;
-
 namespace chromeos {
 
 namespace tether {
 
+class TetherHostResponseRecorder;
+
 // Prioritizes the order of devices when performing a host scan. To optimize for
 // the most common tethering operations, this class uses the following rules:
 //   * The device which has most recently sent a successful
 //     ConnectTetheringResponse is always at the front of the queue.

[Ryan Hansberry, 2017/04/27 17:45:54]

Now that we capture all of the devices we've connected to, should the queue be
[all connected devices] + [all available devices] + [the rest] ?

[Kyle Horimoto, 2017/04/27 17:51:42]

No, I don't think this should be the case. Here's my reasoning:

The first one should always be the most-recently connected device. Having
connected most recently is a strong indication that you want to connect to the
same device again.

After that, we should prioritize the devices which have responded most recently.
Prioritizing by last connection over last response means that if you connected
to a device a really long time ago but you don't use that device anymore
(perhaps you don't even own that device anymore), you'd be prioritizing that
over a device which has recently responded. A recent response is a stronger
indication that that device is nearby and can provide a tether hotspot than
having connected to that device long ago.

[Ryan Hansberry, 2017/04/27 18:08:25]

Alright, I agree. Thanks.

 //   * Devices which have most recently sent a successful
 //     TetherAvailabilityResponse are next in the order, as long as they do not
 //     violate the first rule.

[Ryan Hansberry, 2017/04/27 18:08:25]

Re-reading this is kind of odd. How can the first rule be "violated"? This last
phrase just seems unnecessary.

 //   * All other devices are left in the order they are passed.
 class HostScanDevicePrioritizer {
  public:
-  // Note: The PrefService* passed here must be created using the same registry
-  // passed to RegisterPrefs().
-  HostScanDevicePrioritizer(PrefService* pref_service);
+  HostScanDevicePrioritizer(
+      TetherHostResponseRecorder* tether_host_response_recorder);
   virtual ~HostScanDevicePrioritizer();
 
-  // Registers the prefs used by this class to |registry|. Must be called before
-  // this class is utilized.
-  static void RegisterPrefs(PrefRegistrySimple* registry);
-
-  // Records a TetherAvailabilityResponse. This function should be called each
-  // time that a response is received from a potential host, even if a
-  // connection is not started.
-  virtual void RecordSuccessfulTetherAvailabilityResponse(
-      const cryptauth::RemoteDevice& remote_device);
-
-  // Records a ConnectTetheringResponse. This function should be called each
-  // time that a response is received from a host.
-  virtual void RecordSuccessfulConnectTetheringResponse(
-      const cryptauth::RemoteDevice& remote_device);
-
   // Prioritizes |remote_devices| using the rules described above.
   virtual void SortByHostScanOrder(
       std::vector<cryptauth::RemoteDevice>* remote_devices) const;
 
  private:
-  PrefService* pref_service_;
+  TetherHostResponseRecorder* tether_host_response_recorder_;
 
   DISALLOW_COPY_AND_ASSIGN(HostScanDevicePrioritizer);
 };
 
 }  // namespace tether
 
 }  // namespace chromeos
 
 #endif  // CHROMEOS_COMPONENTS_TETHER_HOST_SCAN_DEVICE_PRIORITIZER_H_