[ios clean] Use ToolsMenuConfiguration for Menu context.

ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.mm

Index: ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.mm
diff --git a/ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.mm b/ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.mm
index c6743ce14532c6d0500ccf91b01f02421d291d30..1fcf1f5f415d4f8f5de6f90a6baab214548857b6 100644
--- a/ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.mm
+++ b/ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.mm
@@ -4,6 +4,7 @@
 
 #import "ios/clean/chrome/browser/ui/toolbar/toolbar_coordinator.h"
 
+#import "ios/chrome/browser/ui/tools_menu/tools_menu_configuration.h"

[sczs, 2017/04/12 00:59:26]

Realized I need to update the BUILD.gn file, but importing from
ios/chrome/browser... is OK, right? 

[marq (ping after 24h), 2017/04/12 11:17:07]

Currently the rules are:

/clean can import from /shared and /chrome, but the /chrome imports will need to
be cleaned up later, so they should only be done as part of the "hacking in"
process of refactoring.
/shared can't import from either /chrome or /clean
/chrome can import from /shared but not /clean

So ideally, if you can move the tools menu configuration files into shared/,
that would be better. (and in a separate CL).

[sczs, 2017/04/12 15:06:07]

Understood, will start working on moving that file! 

 #import "ios/clean/chrome/browser/ui/commands/tools_menu_commands.h"
 #import "ios/clean/chrome/browser/ui/omnibox/location_bar_coordinator.h"
 #import "ios/clean/chrome/browser/ui/toolbar/toolbar_mediator.h"
@@ -101,6 +102,10 @@
   ToolsCoordinator* toolsCoordinator = [[ToolsCoordinator alloc] init];
   [self addChildCoordinator:toolsCoordinator];
   [toolsCoordinator start];
+  ToolsMenuConfiguration* menuConfiguration =
+      [[ToolsMenuConfiguration alloc] initWithDisplayView:nil];

[sczs, 2017/04/12 00:59:26]

Currently [[ToolsMenuConfiguration alloc] init] is disabled, I will refactor it
a little bit. 

+  menuConfiguration.inTabSwitcher = NO;
+  toolsCoordinator.toolsMenuConfiguration = menuConfiguration;

[sczs, 2017/04/12 00:59:26]

This is my main question, should the Coordinator initializing the ToolsMenu
Coordinator configure the ToolsMenuConfiguration? 
Or should we use the UI Model so the ToolsMenu Coordinator configures its own
ToolsMenuConfiguration object? 

[marq (ping after 24h), 2017/04/12 11:17:07]

Conceptually ToolsMenuConfiguration is model code, so ideally the
ToolsMenuMediator just creates the instance it needs and nobody else knows
anything about it.

[sczs, 2017/04/12 15:06:07]

The problem is that ToolsMenuConfiguration needs to know about the current
context of the UI so we can configure it accordingly.
e.g. It needs to know if we are on the TabGrid or in "navigation/toolbar" mode,
because we will never show the overflow controls on the TabGrid ToolsMenu, even
if we are on compact width. 

[marq (ping after 24h), 2017/04/14 10:01:51]

Ah, OK; I missed that. Then, yes the coordinator that starts the menu
coordinator should pass in a menu config to the menu coordinator, like you are
doing here.

I'd also prefer to see (in another CL is fine) ToolsMenuConfiguration subclasses
for the switcher/toolbar cases rather than a property with conditional logic in
the class. Any time we can extract conditions that won't change at runtime into
separate implementations we should do so (I think).

[sczs, 2017/04/14 22:21:07]

Ack. Will merge this as an initial POC and keep iterating on how the Config is
set up.

   self.toolsMenuCoordinator = toolsCoordinator;
 }