Remove Client relationship between mojo.Shell/mojo.Application
Instead of mojo.Shell and mojo.Application being clients of each other
they are now separate interfaces. An implementation of mojo.Application
receives a handle to the shell in its Initialize call, as described in
this doc:
https://docs.google.com/document/d/1xjt_TPjTu0elix8fNdBgWmnjJdJAtqSr1XDS_C-Ct8E/edit?usp=sharing
An analogous change is made to the content handler definition.
In C++, this is handled by the mojo::ApplicationImpl class which stores
shell handle in its implementation of Initialize. Thus the only change
for most C++ applications is the meaning of the handle in MojoMain is
different, although mains that use the ApplicationRunners do the same
thing with it. Connecting to other apps is largely the same although
instead of grabbing the ApplicationImpl's client() to talk to the shell
code must now use the ApplicationImpl::shell() getter.
In JavaScript, the initialization sequence is a bit different although
this is hidden mostly in the Application class which calls initialize()
on its subclass with the same set of parameters. Connecting to another
application looks different, especially for sky code using the shell
proxy handle exposed via internals. Hans has some ideas about how to
make this a bit nicer.
Python apps similarly need to change their startup sequence a bit. I
didn't find a common library to take care of this dance, although it's
possible I just missed it.
Other languages probably a bit of reworking - I fixed everything here
that is covered by mojob.py test but some might be missing.
This patch also uses typed handles (i.e. InterfacePtr<> or
InterfaceRequest<> or their type aliases) wherever possible instead of
ScopedMessagePipeHandle for clarity.
R=davemoore@chromium.org
Review URL: https://codereview.chromium.org/868463008
diff --git a/shell/android/android_handler.cc b/shell/android/android_handler.cc
index 5b29ad7..f88d6dc 100644
--- a/shell/android/android_handler.cc
+++ b/shell/android/android_handler.cc
@@ -33,7 +33,8 @@
jobject j_context,
const base::FilePath& app_path,
jint j_handle) {
- ScopedMessagePipeHandle handle((mojo::MessagePipeHandle(j_handle)));
+ InterfaceRequest<Application> application_request = MakeRequest<Application>(
+ MakeScopedHandle(mojo::MessagePipeHandle(j_handle)));
// Load the library, so that we can set the application context there if
// needed.
@@ -63,7 +64,8 @@
// Run the application.
base::ScopedNativeLibrary app_library_from_runner(
- shell::DynamicServiceRunner::LoadAndRunService(app_path, handle.Pass()));
+ shell::DynamicServiceRunner::LoadAndRunService(
+ app_path, application_request.Pass()));
}
} // namespace
@@ -73,7 +75,9 @@
AndroidHandler::~AndroidHandler() {
}
-void AndroidHandler::RunApplication(ShellPtr shell, URLResponsePtr response) {
+void AndroidHandler::RunApplication(
+ InterfaceRequest<Application> application_request,
+ URLResponsePtr response) {
JNIEnv* env = AttachCurrentThread();
ScopedJavaLocalRef<jstring> j_archive_path =
Java_AndroidHandler_getNewTempArchivePath(env, GetApplicationContext());
@@ -84,7 +88,7 @@
RunAndroidApplicationFn run_android_application_fn = &RunAndroidApplication;
Java_AndroidHandler_bootstrap(
env, GetApplicationContext(), j_archive_path.obj(),
- shell.PassMessagePipe().release().value(),
+ application_request.PassMessagePipe().release().value(),
reinterpret_cast<jlong>(run_android_application_fn));
}
