Child coordinators notify their parent upon -start and -stop.

ios/clean/chrome/browser/ui/tab/tab_coordinator.mm

 // 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.
 
 // ======                        New Architecture                         =====
 // =         This code is only used in the new iOS Chrome architecture.       =
 // ============================================================================
 
 #import "ios/clean/chrome/browser/ui/tab/tab_coordinator.h"
 
@@ skipping 54 matching lines @@
   ToolbarCoordinator* toolbarCoordinator = [[ToolbarCoordinator alloc] init];
   toolbarCoordinator.webState = self.webState;
   [self addChildCoordinator:toolbarCoordinator];
 
   // Unset the base view controller, so |toolbarCoordinator| doesn't present
   // its view controller.
   toolbarCoordinator.context.baseViewController = nil;
   [toolbarCoordinator start];
 
   self.viewController.toolbarViewController = toolbarCoordinator.viewController;
   self.viewController.contentViewController = webCoordinator.viewController;

[rohitrao (ping after 24h), 2017/03/08 13:01:03]

These two lines are examples of code that should move into didStart, under the
proposed pattern.  If you make that change, how does it feel to you?

[lpromero, 2017/03/08 13:45:41]

Uploading a patch. But is clearly contrived.

[lpromero, 2017/03/08 13:45:41]

The goal (maybe not in this class, but generally speaking) is to have someone
else than the parent coordinator call -start, is that right?

[rohitrao (ping after 24h), 2017/03/08 13:50:23]

The goal is to allow it, but that may not always happen. The toolbar is UI that
is always visible, so its parent coordinator will always immediately call
-start.  The find bar is only sometimes visible, so it is useful to have a
mechanism that allows the FindBarCoordinator to start itself, letting us stitch
together the view controllers on demand.

I expect that our UI will have a mix of the two cases.  I'd like to develop one
patterns that handles both.

 
   // PLACEHOLDER: Replace this placeholder with an actual tab strip view
   // controller.
   UIButton* button = [UIButton buttonWithType:UIButtonTypeCustom];
   [button addTarget:nil
                 action:@selector(hideTabStrip:)
       forControlEvents:UIControlEventTouchUpInside];
   [button setTitle:@"Hide Strip" forState:UIControlStateNormal];
   button.frame = CGRectMake(10, 10, 100, 100);
 
   UIViewController* tabStripViewController = [[UIViewController alloc] init];
   tabStripViewController.view.backgroundColor = [UIColor blackColor];
   [tabStripViewController.view addSubview:button];
   self.viewController.tabStripViewController = tabStripViewController;
 
   [self.context.baseViewController presentViewController:self.viewController
                                                 animated:self.context.animated
                                               completion:nil];
+  [super start];
 }
 
 - (void)stop {
+  [super stop];
   [self.viewController.presentingViewController
       dismissViewControllerAnimated:self.context.animated
                          completion:nil];
   _webStateObserver.reset();
 }
 
 - (BOOL)canAddOverlayCoordinator:(BrowserCoordinator*)overlayCoordinator {
   // This coordinator will always accept overlay coordinators.
   return YES;
 }
@@ skipping 41 matching lines @@
 - (id<UIViewControllerAnimatedTransitioning>)
 animationControllerForDismissedController:(UIViewController*)dismissed {
   ZoomTransitionAnimator* animator = [[ZoomTransitionAnimator alloc] init];
   animator.presenting = NO;
   animator.presentationKey = self.presentationKey;
   [animator selectDelegate:@[ dismissed.presentingViewController ]];
   return animator;
 }
 
 @end