Create a RegisterViewAssociate method in ViewManager

mojo/services/ui/views/interfaces/view_manager.mojom

 // Copyright 2015 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.
 
 [DartPackage="mojo_services"]
 module mojo.ui;
 
 import "mojo/services/ui/views/interfaces/view_associates.mojom";
 import "mojo/services/ui/views/interfaces/view_trees.mojom";
 import "mojo/services/ui/views/interfaces/views.mojom";
@@ skipping 49 matching lines @@
   //
   // The |label| is an optional name to associate with the view tree for
   // diagnostic purposes.  The label will be truncated if it is longer
   // than |kLabelMaxLength|.
   //
   // To destroy the view tree simply close the |view_tree| or
   // |view_tree_listener| message pipes.
   CreateViewTree(mojo.ui.ViewTree& view_tree,
                  mojo.ui.ViewTreeListener view_tree_listener,
                  string? label);
+
+  // Registers a view associate with the view manager.
+  //
+  // The services provided by |view_associate| will be made available to views.
+  // TODO(mikejurka): This method should only be made accessible to trusted
+  // services, once we have a security story
+  RegisterViewAssociate(mojo.ui.ViewAssociate view_associate, string? label);
+
+  // Registers a ViewAssociateWatcher with the view manager. We use this to
+  // notify methods when a view associate's connection has closed.
+  RegisterViewAssociateWatcher(mojo.ui.ViewAssociateWatcher view_associate_watcher);
 };
+
+// Used to monitor whether a ViewAssociate's connection has closed.
+interface ViewAssociateWatcher {
+  // Called when a ViewAssociate's connection has an error. |label| is the
+  // that was passing in when the ViewAssociate was registered using RegisterViewAssociate
+  OnViewAssociateConnectionError(string? label) => ();

[jeffbrown, 2016/05/17 00:44:49]

Returning the label is useful for diagnostics but whoever registered the
associate won't necessarily be able to use it to identify which one died (and
maybe restart it).

Perhaps you could add a ViewAssociateWatcher to the ViewAssociateRegistration
instead so you'd have one per associate so there's no ambiguity.  Or if we
following something like the pattern of ViewOwner / ViewTreeOwner we could do:

RegisterViewAssociate(mojo.ui.ViewAssociate view_associate,
mojo.ui.ViewAssociateOwner& view_associate_owner, string? label);

If the associate dies, the view manager can close its endpoint of the owner
connection.  If the launcher wants to remove the associate, it can close its
endpoint of the owner connection.  So it's slightly more functional.  (Don't
worry about having lots of extra message pipes, they're supposed to be cheap.)

This also works with the array variant too, though thinking on it we might be
happier keeping the simple case and adding a synchronizing method instead.

interface ViewManager {
  /* existing stuff... */

  RegisterViewAssociate(mojo.ui.ViewAssociate view_associate,
mojo.ui.ViewAssociateOwner& view_associate_owner, string? label);

  // TODO: delete when we add methods for clients to detect when associates come
and go
  FiatLux();
}

+};