Implement Android shared memory data fetcher for Device Motion.

content/browser/device_orientation/data_fetcher_shared_memory.h

Index: content/browser/device_orientation/data_fetcher_shared_memory.h
diff --git a/content/browser/device_orientation/data_fetcher_shared_memory.h b/content/browser/device_orientation/data_fetcher_shared_memory.h
new file mode 100644
index 0000000000000000000000000000000000000000..296308d1b80df11aa4b824d52fb4c729149360d3
--- /dev/null
+++ b/content/browser/device_orientation/data_fetcher_shared_memory.h
@@ -0,0 +1,42 @@
+// Copyright (c) 2013 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_BROWSER_DEVICE_ORIENTATION_DATA_FETCHER_SHARED_MEMORY_H_
+#define CONTENT_BROWSER_DEVICE_ORIENTATION_DATA_FETCHER_SHARED_MEMORY_H_
+
+#include "content/browser/device_orientation/device_data.h"
+#include "content/common/device_motion_hardware_buffer.h"
+
+namespace WebKit {
+class WebDeviceMotionData;
+}
+
+namespace content {
+
+class DataFetcherSharedMemory {

[bulach, 2013/07/04 08:23:36]

in the "vibration API" review, jam@ pointed out to:
http://dev.chromium.org/developers/design-documents/conventions-and-patterns-...

I think this falls into the case described "
Small platform differences in the header, larger ones in the implementation:
split the implementation"

so this data_fetcher_shared_memory.h would have a corresponding .cc for all
platforms, and one specific for data_fetcher_shared_memory_android.cc with a
different implementation. this would avoid the need for typedef and the extra
indirection at data_fetcher_platform.h/cc..

[timvolodine, 2013/07/04 12:02:52]

hmm, yes that looks like the normal way to go. However in this case I think
typedefs are still needed because we need to instantiate a particular singleton
fetcher using a static instance() method. Not sure how I would do this using the
approach with split implementations..
The current approach with typedefs is based on how the gamepad solves this
problem, which I think is cleaner as compared to the DataFetcherFactory in
provider_impl..

+ public:
+  virtual ~DataFetcherSharedMemory() {}
+
+  // Returns true if this fetcher needs explicit calls to fetch the data.
+  virtual bool NeedsPolling() = 0;
+
+  // If this fetcher needsPolling() is true, this method will update the
+  // buffer with the latest device motion data.
+  // This method will do nothing if needsPolling() is false.
+  // Returns true if there was any motion data to update the buffer with.
+  virtual bool FetchDeviceMotionDataIntoBuffer() = 0;
+
+  // Returns true if the relevant sensors could be successfully activated.
+  // This method should be called before any calls to
+  // FetchDeviceMotionDataIntoBuffer().
+  virtual bool StartFetchingDeviceMotionData(
+      DeviceMotionHardwareBuffer* buffer) = 0;
+
+  // Indicates to the fetcher to stop fetching device data.
+  virtual void StopFetchingDeviceMotionData() = 0;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_DEVICE_ORIENTATION_DATA_FETCHER_SHARED_MEMORY_H_