[iOS Clean] Created OverlayService.

ios/clean/chrome/browser/ui/commands/overlay_commands.h

Index: ios/clean/chrome/browser/ui/commands/overlay_commands.h
diff --git a/ios/clean/chrome/browser/ui/commands/overlay_commands.h b/ios/clean/chrome/browser/ui/commands/overlay_commands.h
new file mode 100644
index 0000000000000000000000000000000000000000..bc63728b1812386fa2a947c7ced5bba24df3fb19
--- /dev/null
+++ b/ios/clean/chrome/browser/ui/commands/overlay_commands.h
@@ -0,0 +1,36 @@
+// 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 IOS_CLEAN_CHROME_BROWSER_UI_COMMANDS_OVERLAY_COMMANDS_H_
+#define IOS_CLEAN_CHROME_BROWSER_UI_COMMANDS_OVERLAY_COMMANDS_H_
+
+#import <Foundation/Foundation.h>
+
+namespace web {
+class WebState;
+}
+
+// Commands used to schedule overlay coordinators requested by web pages.
+@protocol OverlaySchedulerCommands<NSObject>
+// Notifies the scheduler that |webState| has a queued overlay coordinator to
+// display.
+- (void)scheduleOverlayForWebState:(web::WebState*)webState;
+// Notifies the scheduler that |webState|'s currently visible overlay has been
+// replaced by another coordinator.
+- (void)visibleOverlayWasReplacedForWebState:(web::WebState*)webState;

[marq (ping after 24h), 2017/06/14 10:02:32]

This feels more like something I'd expect in an observer or delegate. I'm not
sure if I want to use commands for that kind of notifications or not.

Should the schedule observe the overlay queues of each webstate instead?  

So the sequence would be:

- as soon as an overlay is triggered, -scheduleOverlay is called, and the
scheduler catches it.
- The scheduler starts observing that webstate's overlay queue
- once an overlay queue is emptied (either from the last overlay being
displayed, or form -cancelOverlays), the scheduler stops observing the queue.

WDYT? What am I missing?

[kkhorimoto, 2017/06/15 08:26:28]

I've converted this protocol to OverlayQueueObserver.  It works differently than
how you describe though: it's a WebStateListObserver and begins/stops observing
when WebStates are added/removed from the list.  That ways it can rely
completely on observer callbacks rather then requiring OverlayQueue to call
|-scheduleOverlay|.

+// Notifies the scheduler that the overlay that was started over |webState|'s
+// content area has been stopped.
+- (void)overlayWasStoppedForWebState:(web::WebState*)webState;
+// Notifies the scheduler to cancel all overlays scheduled for |webState|.
+- (void)cancelOverlaysForWebState:(web::WebState*)webState;
+@end
+
+// Commands used by the scheduler to start queued OverlayCoordinators.
+@protocol OverlayPresentationCommands<NSObject>
+// Called by the scheduler to notify the coordinator showing the web content to
+// start its next queued overlay.
+- (void)startNextOverlayForWebState:(web::WebState*)webState;
+@end
+
+#endif  // IOS_CLEAN_CHROME_BROWSER_UI_COMMANDS_OVERLAY_COMMANDS_H_