Create the BackgroundFetchBatchManager and initiate a download.

content/browser/background_fetch/background_fetch_batch_manager.cc

+// 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.
+
+#include "content/browser/background_fetch/background_fetch_batch_manager.h"
+
+#include <string>
+#include <vector>
+
+#include "base/bind.h"
+#include "base/memory/ptr_util.h"
+#include "content/public/browser/browser_context.h"
+#include "content/public/browser/browser_thread.h"
+#include "content/public/browser/download_manager.h"
+#include "content/public/browser/storage_partition.h"
+
+namespace content {
+
+BackgroundFetchBatchManager::BackgroundFetchBatchManager(
+    BrowserContext* browser_context,
+    StoragePartition* storage_partition)
+    : browser_context_(browser_context),
+      storage_partition_(storage_partition) {}
+
+BackgroundFetchBatchManager::~BackgroundFetchBatchManager() = default;
+
+void BackgroundFetchBatchManager::ProcessBatch(
+    const std::string& batch_guid,
+    BackgroundFetchDataManager::BatchData* batch_data) {
+  DCHECK_CURRENTLY_ON(BrowserThread::IO);

[Peter Beverloo, 2017/02/24 02:05:15]

For your consideration (not per se for this CL either) --

Normally we try to use DCHECK_CURRENTLY_ON in code (a) when different parts live
on different threads, in which case every method gets annotated, and (b) the
class implements an interface elsewhere whose contract defines threading
constraints.

I would very much prefer for this entire class to live on a single, defined
thread. Today, the constructor and destructor will be called on the UI thread
(because that's where the BackgroundFetchContext lives). Since you'll need
{Init,Shutdown}OnIO methods in there anyway, consider the option of holding on
to this instance as an std::unique_ptr<> created later on.

That way you can do away with the threading DCHECKs in the implementation, and
instead document it in the header.

[harkness, 2017/02/24 11:47:10]

I think that's a really good idea, I'll switch it over in the next CL (when I
will also be creating more than one of these.)

+  const FetchRequest& fetch_request = batch_data->GetNextFetchRequest();
+  ProcessRequest(batch_guid, fetch_request);
+
+  // Currently this only supports batches of size 1.
+  // TODO(crbug.com/692544)
+  DCHECK(!batch_data->HasRequestsRemaining());
+
+  // TODO(harkness): Save the BatchData so that when the download completes we
+  // can notify the DataManager.
+}
+
+void BackgroundFetchBatchManager::ProcessRequest(
+    const std::string& batch_guid,
+    const FetchRequest& fetch_request) {
+  // First add the new request to the internal map tracking in-progress
+  // requests.
+  fetch_map_[batch_guid] = std::move(fetch_request);
+
+  // TODO(harkness): Check if the download is already in progress or completed.
+
+  // Send the fetch request to the DownloadManager.
+  std::unique_ptr<DownloadUrlParameters> params(
+      base::MakeUnique<DownloadUrlParameters>(
+          fetch_request.url(), storage_partition_->GetURLRequestContext()));
+  BrowserContext::GetDownloadManager(browser_context_)

[Peter Beverloo, 2017/02/24 02:05:15]

Are we going to use the browser_context_ for more than this? Otherwise we could
do with just the DownloadManager.

[harkness, 2017/02/24 11:47:10]

I'm not sure at this point. I'll add in a TODO to evaluate whether we can switch
to just DownloadManager later once more of the code is written. I do know that
the way the tests are set up, we override the download manager by setting it on
the browser context, so we'd need to modify the test, but I think that's doable.

+      ->DownloadUrl(std::move(params));
+}
+
+}  // namespace content