Refactor OAuth2TokenService to have profile- and device-based implementations.

chrome/browser/chromeos/settings/device_oauth2_token_service_factory.cc

+// Copyright (c) 2012 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/chromeos/settings/device_oauth2_token_service_factory.h"
+
+#include "base/lazy_instance.h"
+#include "chrome/browser/browser_process.h"
+#include "content/public/browser/browser_thread.h"
+
+namespace chromeos {
+
+static base::LazyInstance<DeviceOAuth2TokenServiceFactory>
+    g_device_oauth2_token_service_factory_ = LAZY_INSTANCE_INITIALIZER;
+
+DeviceOAuth2TokenServiceFactory::DeviceOAuth2TokenServiceFactory() {
+}
+
+DeviceOAuth2TokenServiceFactory::~DeviceOAuth2TokenServiceFactory() {
+  // The OAuth2TokenService destructor will cancel all pending fetchers.
+}
+
+// static
+DeviceOAuth2TokenService* DeviceOAuth2TokenServiceFactory::Get() {
+  DCHECK(content::BrowserThread::CurrentlyOn(content::BrowserThread::UI));
+  DeviceOAuth2TokenServiceFactory factory =
+      g_device_oauth2_token_service_factory_.Get();
+
+  return factory.GetImpl();
+}
+
+DeviceOAuth2TokenService* DeviceOAuth2TokenServiceFactory::GetImpl() {
+  if (!device_oauth2_token_service_) {
+    device_oauth2_token_service_.reset(
+        new DeviceOAuth2TokenService(
+            g_browser_process->system_request_context()));

[Mattias Nissler (ping if slow), 2013/03/21 06:59:15]

Ha, so the factory design is broken here after all. You're actually depending on
g_browser_process being initialized already, which breaks the general
expectation towards singletons that they're stand-alone and without
dependencies.

I suggest you look into whether we can hook the DeviceOAuth2TokenService
instance off g_browser_process or something similar.

[David Roche, 2013/03/21 20:36:31]

The factory singleton doesn't have an external dependency.  The Get() method
that returns an instance of the DeviceOAuth2TokenService has a dependency on the
IO thread being created.  Moving this to g_browser_process wouldn't change that
requirement: it would simply be moved into a lazy factory method that can't be
invoked until the IO thread is up.

Indeed, the global browser process singleton has this exact same problem in many
of its methods: the g_browser_process pointer value is set to a valid value in
its constructor, but many of its factory methods would fail if called
immediately.  Instead they depend on the fact that they won't be invoked until
after the browser has come up, the threads have been started, etc.

I'm not sure that moving this into g_browser_process really buys us anything
here.  Perhaps it would be better to simply document the requirement on the
IOThread, and have the Get() method return null if the IOThread isn't up yet? 
This would behave the same as the g_browser_process implementation, but would
avoid having to extend that monolithic global object with yet-more CrOS-only
logic.

+  }
+  return device_oauth2_token_service_.get();
+}
+
+}  // namespace chromeos