[iOS] Box/unroot language selector
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}
Showing
This diff is collapsed.
Please register or sign in to comment