GitLab

This CL moves the UI implementation out of BeforeTranslateInfobar.

There's quite a lot going on here, but the basic interactions are straightforward:

- Since UI doesn't belong in browser/translate, chrome_ios_translate_client now
takes a language selection handler on initialization, and the before-translate
infobar uses that handler to request language selection from the user. That involves
passing a context object (LanguageSelectionContext) and a delegate for the UI
to signal when language selection is complete.

- The language selection handler passed into the translate client is an instance
of LanguageSelectionCoordinator, owned by the BVC. This is a long-lived coordinator,
repeatedly started and stopped by the LanguageSelectionHandler method call. It
creates a new view controller and mediator instance each time it's invoked.

- The view controller used for this isn't presented; it's a contained child of the
BVC, but it's "presented" and "dismissed" using a from-the-bottom animation. This
animation, along with the logic of adding and removing a child view controller, and
positioning the child inside the BVC, is handled by a generic 'presenter' interface.

- The presenter interface doesn't specify any particular positioning or animation;
this is defined by the VerticalAnimationContainer implementation. This is passed into
the coordinator by the BVC; effectively the BVC dictates how the child is presented,
and the coordinator doesn't know about it. There's a delegate protocol so the
coordinator knows when dismissal is completed.

- The view controller uses the mediator as a data source for language names, and
this relationship is set up over the consumer interface.

On one hand, this feels like a fairly straightforward refactor that gets UI code out
of browser/translate. On the other hand, it's creating five classes and six protocols
to move ~200 lines of code.

An argument could be made that more of the code in before_translate_infobar_controller
should move into the mediator; I suspect that will need to wait until we have better
patterns for refactoring infobars.

I do think the presenter pattern here is something we can use in general to better
encapsulate child view controller positioning and animation without needing to build
specific support for it in coordinators.

One issue here is that the coordinator is long-lived and acts as the language selection
handler. This is intentional, to keep code out of the BVC. An argument could be made that
the BVC should be the handler, and it should directly start/stop the coordinator.

Bug: 785388
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Ied9da19bb88cabd1e14b67689052597186e190e8
Reviewed-on: https://chromium-review.googlesource.com/764327Reviewed-by: Louis Romero <lpromero@chromium.org>
Commit-Queue: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517818}