Dart: Adds a content handler and a test.

services/dart/lib/src/application.dart

Index: services/dart/lib/src/application.dart
diff --git a/services/dart/lib/src/application.dart b/services/dart/lib/src/application.dart
new file mode 100644
index 0000000000000000000000000000000000000000..d5c7fa18f7706d4415734877876741a1c13d6d45
--- /dev/null
+++ b/services/dart/lib/src/application.dart
@@ -0,0 +1,77 @@
+// Copyright 2014 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.
+
+part of application;
+
+// The Application interface doesn't explicitly have a Shell as a Client, but
+// that is what is at the other end of the MessagePipe.
+abstract class Application extends application.ApplicationInterface

[abarth-chromium, 2015/01/18 22:19:02]

The way we've been naming things in C++ is to have the abstract interfaces
(e.g., ApplicationInterface) have the "short" name (e.g., Application) and have
the implementation of the interface have a more decorated name (e.g.,
ApplicationImpl).  That's different from the norm in COM (e.g., IApplication for
the interface).

If ApplicationInterface is idiomatic in Dart, we can use that naming convention.
 If Dart doesn't have a convention for naming interfaces/implementations, then
we might want to follow the style we use in C++ for Mojo (e.g., Application and
ApplicationImpl).  If we decide to change this, lets do that in a separate CL
because it will just add a bunch of renaming noise to this CL.

[abarth-chromium, 2015/01/18 22:19:02]

The way we've been naming things in C++ is to have the abstract interfaces
(e.g., ApplicationInterface) have the "short" name (e.g., Application) and have
the implementation of the interface have a more decorated name (e.g.,
ApplicationImpl).  That's different from the norm in COM (e.g., IApplication for
the interface).

If ApplicationInterface is idiomatic in Dart, we can use that naming convention.
 If Dart doesn't have a convention for naming interfaces/implementations, then
we might want to follow the style we use in C++ for Mojo (e.g., Application and
ApplicationImpl).  If we decide to change this, lets do that in a separate CL
because it will just add a bunch of renaming noise to this CL.

[zra, 2015/01/20 17:36:51]

Added TODO in the interface template.

+                           with shell.ShellCalls {

[abarth-chromium, 2015/01/18 22:19:02]

What is ShellCalls?

[zra, 2015/01/20 17:36:51]

I have (partly) implemented Client= using Dart mixins. ShellCalls is a generated
mixin class that contains the client calls to Shell. Normally it would have been
included in application.ApplicationInterface, but since there is no Client= on
Application, I have to do it manually. This will go away when Client= goes away.

+  List<service_provider.ServiceProviderClient> _clients;
+
+  Application(core.MojoMessagePipeEndpoint endpoint) :
+      _clients = [],
+      super(endpoint);
+
+  Application.fromHandle(core.MojoHandle shellHandle) :
+      _clients = [],
+      super.fromHandle(shellHandle);
+
+  Function interfaceFactoryClosure();
+
+  void initialize(List<String> args) {
+  }
+
+  void acceptConnection(
+      String requestorUrl,
+      service_provider.ServiceProviderInterface services,
+      service_provider.ServiceProviderClient exposedServices) {
+    var serviceProvider = new ServiceProvider(interfaceFactoryClosure());
+    services.delegate = serviceProvider;
+    services.listen();
+  }
+
+  core.MojoMessagePipeEndpoint connectToService(String url, String service) {
+    var applicationPipe = new core.MojoMessagePipe();
+    var clientEndpoint = applicationPipe.endpoints[0];
+    var applicationEndpoint = applicationPipe.endpoints[1];
+    var serviceProviderClient =
+        new service_provider.ServiceProviderClient.unbound();
+    callConnectToApplication(url, serviceProviderClient, null);

[abarth-chromium, 2015/01/18 22:19:02]

callConnectToApplication ?  Why not connectToApplication ?

[zra, 2015/01/20 17:36:51]

This is more cruftiness related to Client=. Since e.g. the Client= of
ServiceProvider is ServiceProvider, the Call mixin class has to have methods
with different names than the Interface class. When Client= goes away, I can
rename methods in the Client classes to X instead of callX.

+    serviceProviderClient.callConnectToService(service, applicationEndpoint);
+    _clients.add(serviceProviderClient);
+    return clientEndpoint;
+  }
+
+  void close() {
+    _clients.forEach((c) => c.close());
+    _clients.clear();
+    super.close();
+  }
+}
+
+
+// TODO(zra): Is this generally useful? If not remove.
+// A ClientApplication is a Mojo Application that does not provide any
+// services (does not implement any interfaces).

[abarth-chromium, 2015/01/18 22:19:02]

I'd remove this.  We don't have this concept in the other languages.

[zra, 2015/01/20 17:36:51]

Done.

+abstract class ClientApplication extends Application {
+  ClientApplication(core.MojoMessagePipeEndpoint endpoint) : super(endpoint);
+
+  ClientApplication.fromHandle(core.MojoHandle shellHandle) :
+      super.fromHandle(shellHandle);
+
+  Function interfaceFactoryClosure() => () => null;
+
+  void initialize(List<String> args) {
+    run(args);
+  }
+
+  void acceptConnection(
+      String requestorUrl,
+      service_provider.ServiceProviderInterface services,
+      service_provider.ServiceProviderClient exposedServices) {
+  }
+
+  run(List<String> args) async;
+}