Add ContextMenuCoordinator.

ios/chrome/browser/ui/context_menu/context_menu_wrangler.h

+// Copyright 2016 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_CHROME_BROWSER_UI_CONTEXT_MENU_CONTEXT_MENU_WRANGLER_H_
+#define IOS_CHROME_BROWSER_UI_CONTEXT_MENU_CONTEXT_MENU_WRANGLER_H_
+
+#import <UIKit/UIKit.h>
+
+#include "base/ios/block_types.h"
+
+namespace web {
+struct ContextMenuParams;
+}
+
+// Abstracts displaying context menus for all device form factors. Will show a
+// sheet on the phone and use a popover on a tablet.
+@interface ContextMenuWrangler : NSObject
+
+// Whether the context menu is visible.
+@property(nonatomic, readonly, getter=isVisible) BOOL visible;
+
+// Initializes with details provided in |params|. Context menu will be presented
+// from |viewController|.
+- (instancetype)initWithViewController:(UIViewController*)viewController

[Eugene But (OOO till 7-30), 2016/05/17 19:40:30]

initWithPresentingViewController: ?

[michaeldo, 2016/05/17 21:08:30]

I like that name a bit better, but then the method name wraps strangely:

- (instancetype)
initWithPresentingViewController:(UIViewController*)viewController
                          params:(const web::ContextMenuParams&)params;

[marq (ping after 24h), 2016/05/18 10:38:09]

The fact that this object happens to use |viewController| for presentation is an
implementation detail. In general coordinators will accept some view controller
that they run 'on top of', but how they do that shouldn't matter elsewhere. So I
don't think this is necessary. 
Line length issues should be at the bottom of the list of concerns around
naming; if line length limits change, we wouldn't go back and use more
descriptive but more cumbersome names.

You can also wrap like this:

- (instancetype)initWithPresentingViewController:
    (UIViewController*)viewController
                                          params:
    (const web::ContextMenuParams&)params;

(Although, for obvious reasons, you may not care to).

[Eugene But (OOO till 7-30), 2016/05/18 15:23:44]

If clients of this method don't know how |viewController| is used, then how do
they know what should be passed? Root view controller, view controller which is
not in the hierarchy, nil?

+                                params:(const web::ContextMenuParams&)params;
+
+// Adds an item at the end of the menu.
+- (void)addItemWithTitle:(NSString*)title action:(ProceduralBlock)action;
+
+// Displays the context menu.
+- (void)start;

[Eugene But (OOO till 7-30), 2016/05/17 19:40:30]

Method should describe the action. -[ContextMenuWrangler start] is too generic
and can mean anything.

[michaeldo, 2016/05/17 21:08:30]

Mark, what do you think? This should be consistent for coordinators, but until
this is named a coordinator (and likely inheriting from your ChromeCoordinator),
should I rename this to something more descriptive like "present"?

[Eugene But (OOO till 7-30), 2016/05/17 22:49:40]

Honestly I really have troubles finding a good name which is:
1.) Prefixed with "start" and/or has only word
2.) Follows "Coding Guidelines for Cocoa"
3.) Reflects the purpose of the methods

Even if the class name is ContextMenuCoordinator, one word name like "start"
still does not feel right. "Starting coordination" is very vague thing, while
method name should be very specific. Questions to Mark:
Why do you want start/stop? 
Is there a class in Standard library that inspired you for this naming scheme?
(if there is no class than maybe we should not use start/stop naming scheme at
all. Objective-C standard library is very mature and if some naming scheme does
not exist there, it probably should not exist at all).
How would you name this method?

[marq (ping after 24h), 2016/05/18 10:38:09]

The overall idea is that a coordinator manages a specific user interaction -- a
context menu, a login screen, First Run, a Safe Mode launch, etc. But the
specifics of how that UI is displayed is by design not part of the API. It's
intended to be understood that when you -start a ContextMenuCoordinator, that
what it will start doing is running the UI for a context menu. The presentation
of the menu is part, but not all of that; to be accurate the method would be
something like -startRunningTheMenu, but since this class's job is, in fact, to
run the menu, it seems sufficient to me to just say 'start'.

The best analogy I can think of to existing iOS libraries is to network sessions
of various kinds -- you set them up, then you start them, and you may stop,
pause, or cancel them along the way. GKVoiceChat has a -start method (not
-startVoiceChat) and NSURLSessionTask has -cancel, -resume, and -suspend (not
-cancelTask or -cancelLoading or whatever). 

[Eugene But (OOO till 7-30), 2016/05/18 15:23:44]

Thanks for detailed explanation, I understand your rationale now.
|startRunningTheMenu| would indeed be an unusual name for Objecitve-C. 

[ContextMenuCoordinator start] is very different from [GKVoiceChat start]. The
latter is well defined thing (it starts a voice chat), while people will
obsoletely need to read class comments to understand what
[ContextMenuCoordinator start] does. Anyways discussion the naming scheme is out
of scope for this CL, so I'm done with asking the questions :) Overall the idea
of coordinators sounds very good to me. Thanks again.

+// Dismisses displayed context menu.
+- (void)stop;
+
+@end
+
+#endif  // IOS_CHROME_BROWSER_UI_CONTEXT_MENU_CONTEXT_MENU_WRANGLER_H_