Add skeleton implementation of ExtensionPushMessagingEventRouter.

chrome/browser/extensions/api/push_messaging/push_messaging_api.h

Index: chrome/browser/extensions/api/push_messaging/push_messaging_api.h
diff --git a/chrome/browser/extensions/api/push_messaging/push_messaging_api.h b/chrome/browser/extensions/api/push_messaging/push_messaging_api.h
new file mode 100644
index 0000000000000000000000000000000000000000..dcf68c136af31269e522fc57894d47f4366caf41
--- /dev/null
+++ b/chrome/browser/extensions/api/push_messaging/push_messaging_api.h
@@ -0,0 +1,40 @@
+// 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.
+
+#ifndef CHROME_BROWSER_EXTENSIONS_API_PUSH_MESSAGING_PUSH_MESSAGING_API_H__

[Munjal (Google), 2012/07/31 17:36:12]

Name this file push_messaging_event_router.h to match with the class name.

[dcheng, 2012/07/31 19:04:11]

I opted to follow the general implementation pattern that other app/extension
APIs have used: they all define their EventRouter class in a *_api.h file. Do
you still want to rename the file in light of that?

(ChromeOS doesn't follow this covention, but CrOS extension code lives in
another directory).

+#define CHROME_BROWSER_EXTENSIONS_API_PUSH_MESSAGING_PUSH_MESSAGING_API_H__
+
+#include <string>
+#include "base/memory/scoped_ptr.h"
+#include "chrome/browser/extensions/api/push_messaging/invalidation_handler_observer.h"
+
+class Profile;
+
+namespace extensions {
+
+class ExtensionPushMessagingEventRouter : public InvalidationHandlerObserver {

[Munjal (Google), 2012/07/31 17:36:12]

Add comment for the class.

[dcheng, 2012/07/31 19:04:11]

Done.

+ public:
+  explicit ExtensionPushMessagingEventRouter(Profile* profile);
+  virtual ~ExtensionPushMessagingEventRouter();
+
+  void Init();
+
+  void TriggerMessageForTest(const std::string& extension_id,
+                             int subchannel,
+                             const std::string& payload);

[Munjal (Google), 2012/07/31 17:36:12]

Test class can become a friend class and directly call OnMessage. I have seen
that pattern used a lot, and will obviate the need for a public method just for
testing.

[dcheng, 2012/07/31 19:04:11]

Done. That being said, I think the ForTest method has two obvious advantages
over friending tests with no disadvantages:
- The test code is clearer (TriggerMessageForTest is a little more obvious than
calling OnMessage, which I had to add a comment for)
- The coupling between implementation and tests isn't as tight. I'm not a big
fan of a long list of FRIEND_TEST_ALL_PREFIXES macros.

[Munjal (Google), 2012/07/31 23:09:58]

Yeah, I agree about readabiity of ForTest. But I do that by adding a method to
the base test class with a good name that calls OnMessage. That way I don't ahve
to do FRIEND_TEST_ALL_PREFIXES for various tests. I just declare the base class
as friend (since that is the only one that calls OnMessage directly) and the
readability is also good.

+
+ private:
+  // InvalidationHandlerObserver implementation.
+  virtual void OnMessage(const std::string& extension_id,
+                         int subchannel,
+                         const std::string& payload) OVERRIDE;
+
+  Profile* profile_;
+
+  DISALLOW_COPY_AND_ASSIGN(ExtensionPushMessagingEventRouter);
+};
+
+}  // namespace extension
+
+#endif  // CHROME_BROWSER_EXTENSIONS_API_PUSH_MESSAGING_PUSH_MESSAGING_API_H__