Move mojo/application/public -> mojo/shell/public

docs/mojo_in_chromium.md

 # Mojo in Chromium
 
 **THIS DOCUIMENT IS A WORK IN PROGRESS.** As long as this notice exists, you
 should probably ignore everything below it.
 
 This document is intended to serve as a Mojo primer for Chromium developers. No
 prior knowledge of Mojo is assumed, but you should have a decent grasp of C++
 and be familiar with Chromium's multi-process architecture as well as common
 concepts used throughout Chromium such as smart pointers, message loops,
 callback binding, and so on.
@@ skipping 318 matching lines @@
 and as for the `mojo::ServiceProvider` interface:
 
 ```
 module mojo;
 interface ServiceProvider {
   ConnectToService(string interface_name, handle<message_pipe> pipe);
 };
 ```
 
 Definitions for these interfaces can be found in
-`/mojo/application/public/interfaces`. Also note that `mojo::URLRequest` is a
+`/mojo/shell/public/interfaces`. Also note that `mojo::URLRequest` is a
 Mojo struct defined in
 `/mojo/services/network/public/interfaces/url_loader.mojom`.
 
 Note that there's some new syntax in the mojom for `ConnectToApplication` above.
 The '?' signifies a nullable value and the '&' signifies an interface request
 rather than an interface proxy.
 
 The argument `ServiceProvider&? services` indicates that the caller should pass
 an `InterfaceRequest<ServiceProvider>` as the second argument, but that it need
 not be bound to a pipe (i.e., it can be "null" in which case it's ignored.)
@@ skipping 26 matching lines @@
                    ServiceProvider&? services,
                    ServiceProvider? exposed_services,
                    string resolved_url);
   OnQuitRequested() => (bool can_quit);
 };
 ```
 
 Of course, in Chromium and Mandoline environments this interface is obscured
 from application code and applications should generally just implement
 `mojo::ApplicationDelegate` (defined in
-`/mojo/application/public/cpp/application_delegate.h`.) We'll see a concrete
+`/mojo/shell/public/cpp/application_delegate.h`.) We'll see a concrete
 example of this in the next section,
 [Your First Mojo Application](#Your-First-Mojo-Application).
 
 The takeaway here is that an application can be anything. It's not necessarily a
 new process (though at the moment, it's at least a new thread). Applications can
 connect to each other, and these connections are the mechanism through which
 separate components expose services to each other.
 
 **NOTE##: This is not true in Chromium today, but it should be eventually. For
 some components (like render frames, or arbitrary browser process code) we
@@ skipping 85 matching lines @@
 An app that prints `"Hello, world!"` isn't terribly interesting. At a bare
 minimum your app should implement `mojo::ApplicationDelegate` and expose at
 least one service to connecting applications.
 
 Let's update `main.cc` with the following contents:
 
 **components/hello/main.cc**
 
 ```cpp
 #include "components/hello/hello_app.h"
-#include "mojo/application/public/cpp/application_runner.h"
+#include "mojo/shell/public/cpp/application_runner.h"
 #include "third_party/mojo/src/mojo/public/c/system/main.h"
 
 MojoResult MojoMain(MojoHandle shell_handle) {
   mojo::ApplicationRunner runner(new hello::HelloApp);
   return runner.Run(shell_handle);
 };
 ```
 
 This is a pretty typical looking `MojoMain`. Most of the time this is all you
 want -- a `mojo::ApplicationRunner` constructed over a
@@ skipping 25 matching lines @@
 ```
 
 **components/hello/hello_app.h**
 
 ```cpp
 #ifndef COMPONENTS_HELLO_HELLO_APP_H_
 #define COMPONENTS_HELLO_HELLO_APP_H_
 
 #include "base/macros.h"
 #include "components/hello/public/interfaces/greeter.mojom.h"
-#include "mojo/application/public/cpp/application_delegate.h"
-#include "mojo/application/public/cpp/interface_factory.h"
+#include "mojo/shell/public/cpp/application_delegate.h"
+#include "mojo/shell/public/cpp/interface_factory.h"
 
 namespace hello {
 
 class HelloApp : public mojo::ApplicationDelegate,
                  public mojo::InterfaceFactory<Greeter> {
  public:
   HelloApp();
   ~HelloApp() override;
 
  private:
@@ skipping 12 matching lines @@
 
 #endif  // COMPONENTS_HELLO_HELLO_APP_H_
 ```
 
 
 **components/hello/hello_app.cc**
 
 ```cpp
 #include "base/macros.h"
 #include "components/hello/hello_app.h"
-#include "mojo/application/public/cpp/application_connection.h"
+#include "mojo/shell/public/cpp/application_connection.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/strong_binding.h"
 
 namespace hello {
 
 namespace {
 
 class GreeterImpl : public Greeter {
  public:
   GreeterImpl(mojo::InterfaceRequest<Greeter> request)
@@ skipping 45 matching lines @@
 import("//mojo/public/mojo_application.gni")
 
 source_set("lib") {
   sources = [
     "hello_app.cc",
     "hello_app.h",
   ]
   deps = [
     "//base",
     "//components/hello/public/interfaces",
-    "//mojo/application/public/cpp",
     "//mojo/environment:chromium",
+    "//mojo/shell/public/cpp",
   ]
 }
 
 mojo_native_application("hello") {
   sources = [
     "main.cc",
   ],
   deps = [ ":lib" ]
 }
 ```
@@ skipping 23 matching lines @@
 
 **components/hello/hello_apptest.cc**
 
 ```cpp
 #include "base/bind.h"
 #include "base/callback.h"
 #include "base/logging.h"
 #include "base/macros.h"
 #include "base/run_loop.h"
 #include "components/hello/public/interfaces/greeter.mojom.h"
-#include "mojo/application/public/cpp/application_impl.h"
-#include "mojo/application/public/cpp/application_test_base.h"
+#include "mojo/shell/public/cpp/application_impl.h"
+#include "mojo/shell/public/cpp/application_test_base.h"
 
 namespace hello {
 namespace {
 
 class HelloAppTest : public mojo::test::ApplicationTestBase {
  public:
   HelloAppTest() {}
   ~HelloAppTest() override {}
 
   void SetUp() override {
@@ skipping 33 matching lines @@
 
 ```
 mojo_native_application("apptests") {
   output_name = "hello_apptests"
   testonly = true
   sources = [
     "hello_apptest.cc",
   ]
   deps = [
     "//base",
-    "//mojo/application/public/cpp:test_support",
+    "//mojo/shell/public/cpp:test_support",
   ]
   public_deps = [
     "//components/hello/public/interfaces",
   ]
   data_deps = [ ":hello" ]
 }
 ```
 
 Note that the `//components/hello:apptests` target does **not** have a binary
 dependency on either `HelloApp` or `GreeterImpl` implementations; instead it
@@ skipping 28 matching lines @@
 Note that generated interface bindings include a constant string to identify
 each interface by name; so for example the generated `hello::Greeter` type
 defines a static C string:
 
     const char hello::Greeter::Name_[] = "hello::Greeter";
 
 This is exploited by the definition of
 `mojo::ApplicationConnection::ConnectToService<T>`, which uses `T::Name_` as the
 name of the service to connect to. The type `T` in this context is inferred from
 the `InterfacePtr<T>*` argument. You can inspect the definition of
-`ConnectToService` in `/mojo/application/public/cpp/application_connection.h`
+`ConnectToService` in `/mojo/shell/public/cpp/application_connection.h`
 for additional clarity.
 
 We could have instead written this code as:
 
 ```cpp
 mojo::URLRequestPtr app_url = mojo::URLRequest::New();
 app_url->url = "mojo::hello";
 
 mojo::ServiceProviderPtr services;
 application_impl()->shell()->ConnectToApplication(
@@ skipping 179 matching lines @@
 
 This is still a work in progress and might not really take shape until the
 Blink+Chromium merge. In the meantime there are some end-to-end WebUI examples
 in `/content/browser/webui/web_ui_mojo_browsertest.cc`. In particular,
 `WebUIMojoTest.ConnectToApplication` connects from a WebUI frame to a test app
 running in a new utility process.
 
 ## FAQ
 
 Nothing here yet!