| OLD | NEW |
| 1 JavaScript Mojo Example Applications | 1 JavaScript Mojo Example Applications |
| 2 ===================== | 2 ===================== |
| 3 | 3 |
| 4 hello.js, world.js - A minimal application that connects to another. | 4 hello.js, world.js - A minimal application that connects to another. |
| 5 | 5 |
| 6 wget.js - Uses the network service to load a URL. | 6 wget.js - Uses the network service to load a URL. |
| 7 | 7 |
| 8 |
| 9 --- Running Mojo Applications --- |
| 10 |
| 11 A Mojo application written in JavaScript is launched with mojo_shell like this: |
| 12 |
| 13 mojo_shell <js-application-url> |
| 14 |
| 15 Where js-application-url is either a file or an http URL that names a JS source |
| 16 file. The JS file itself must begin with a Mojo "shebang" that specifies the |
| 17 Mojo URL of the JS content handler. In other words, the first line of the JS |
| 18 source file must be: |
| 19 |
| 20 #!mojo:js_content_handler |
| 21 |
| 22 Following the shebang should be a single AMD module called "main" whose value |
| 23 is an Application class. The JS content handler will create an instance of the |
| 24 Application and make it the client of the Mojo shell. The JS content handler is |
| 25 itself a Mojo application and it's responsible for creating an instance of V8 |
| 26 and loading the "main" JS module and all of the modules the main module |
| 27 depends on. |
| 28 |
| 29 The overall structure of a JS Mojo application is this: |
| 30 |
| 31 #!mojo:js_content_handler |
| 32 |
| 33 define("main", [<list of modules this application depends on>], |
| 34 function(<one parameter per dependent module>) { |
| 35 function Application(appShell, url) { |
| 36 } |
| 37 |
| 38 Application.prototype.initialize = function(args) { |
| 39 } |
| 40 |
| 41 Application.prototype.acceptConnection = function(url, spHandle) { |
| 42 } |
| 43 |
| 44 return Application; |
| 45 }); |
| 46 |
| 47 The hello.js example is little more than this basic skeleton. |
| 48 |
| 49 The JS content handler loads the "main" module and makes an instance of its |
| 50 value, which must be the application's class. The application's constructor is |
| 51 passed two arguments: |
| 52 |
| 53 appShell - a pointer to the Mojo shell. Typically this will be wrapped by a |
| 54 Shell object, see below. |
| 55 |
| 56 url - the URL this application was loaded from as a String. |
| 57 |
| 58 The initialize() and acceptConnection() methods are defined by application.mojom |
| 59 and they're needed because the JS content handler makes the JS application the |
| 60 Mojo shell's client. |
| 61 |
| 62 |
| 63 --- Mojo Application Structure --- |
| 64 |
| 65 Mojo applications can connect to services provided by other applications and |
| 66 they can provide services of their own. A service is an implementation of a Mojo |
| 67 interface that was defined as part of a Mojo module in a ".mojom" file. |
| 68 |
| 69 To implement a service you'll need the JS "bindings" for the Mojo interface. The |
| 70 bindings are generated by the build system and end up in files whose name is the |
| 71 same as the '.mojom' file with a '.js' suffix. It's often helpful to look at the |
| 72 generated 'mojom.js' files. |
| 73 |
| 74 The JS Shell class simplifies connecting to applications and services. It's a |
| 75 wrapper for the Application's appShell argument. |
| 76 |
| 77 The Shell's connectToService() method returns a "proxy" to a service provided by |
| 78 another application. |
| 79 |
| 80 The JS bindings for a Mojo interface's API are delivered as a JS module whose |
| 81 name is based on the '.mojom' file's path. For example, to use the Mojo network |
| 82 service you need the JS module based on network_service.mojom: |
| 83 |
| 84 define("main", [ |
| 85 "mojo/services/public/interfaces/network/network_service.mojom", |
| 86 "mojo/services/public/js/shell", |
| 87 ] |
| 88 function(netModule, shellModule) { |
| 89 function Application(appShell, url) { |
| 90 this.shell = new shellModule.Shell(appShell); |
| 91 } |
| 92 |
| 93 Application.prototype.initialize = function(args) { |
| 94 var netService = this.shell.connectToService( |
| 95 "mojo:network_service", netModule.NetworkService); |
| 96 |
| 97 } |
| 98 ... |
| 99 return Application; |
| 100 }); |
| 101 |
| 102 The first connectToService() parameter is the Mojo URL for the network service |
| 103 application and the second is the JS "interface" object for NetworkService. The |
| 104 JS interface object's properties identify the (generated) JS bindings classes |
| 105 used to provide or connect to a service. For example (from |
| 106 network_service.mojom.js): |
| 107 |
| 108 var NetworkService = { |
| 109 name: 'mojo::NetworkService', // Fully qualified Mojo interface name. |
| 110 proxyClass: NetworkServiceProxy, |
| 111 stubClass: NetworkServiceStub, |
| 112 // ... |
| 113 }; |
| 114 |
| 115 The 'proxyClass' is used to access another application's NetworkService and the |
| 116 'stubClass' is used to create an implementation of NetworkService. |
| 117 |
| 118 In the netService case above the Shell connects to the Mojo application at |
| 119 "mojo:network_service", then connects its service called |
| 120 'NetworkService.name' with an instance of 'NetworkService.proxyClass'. The proxy |
| 121 instance is returned. |
| 122 |
| 123 |
| 124 --- Interface Parameters --- |
| 125 |
| 126 Mojo functions with interface valued parameters allow one to request a service |
| 127 from a service or to provide a service to a service. The |
| 128 indirect_service example demonstrates this. |
| 129 |
| 130 The NetworkService CreateURLLoader() method has an interface request parameter: |
| 131 |
| 132 interface NetworkService { |
| 133 CreateURLLoader(URLLoader& loader); // Return a URLLoader to the caller. |
| 134 ... |
| 135 } |
| 136 |
| 137 Interface request parameters can be specified as an instance of the interface's |
| 138 proxy class. Ordinary interface parameters can be specified as an instance of |
| 139 the interface's stub class. The stub class constructor has an optional delegate |
| 140 parameter that defines the stub's implementation. |
| 141 |
| 142 Here's an example of an interface request parameter taken from wget.js: |
| 143 |
| 144 var urlLoader = new loader.URLLoader.proxyClass; |
| 145 netService.createURLLoader(urlLoader); // interface& parameter |
| 146 |
| 147 var urlRequest = new loader.URLRequest({ |
| 148 url: "http://www.cnn.com", |
| 149 method: "GET", |
| 150 auto_follow_redirects: true |
| 151 }); |
| 152 |
| 153 urlLoader.start(urlRequest).then(function(result) { |
| 154 // ..Do something with result.response |
| 155 }); |
| 156 |
| 157 |
| 158 --- Mojo Responses are Promises --- |
| 159 |
| 160 Mojo functions can return zero or more values called a "response". For example |
| 161 the EchoString function below returns a string or null. |
| 162 |
| 163 interface EchoService { |
| 164 EchoString(string? value) => (string? value); |
| 165 }; |
| 166 |
| 167 The response is delivered to the function caller asynchronously. In C++ the |
| 168 caller provides a Callback object whose Run() method has one argument for |
| 169 each response parameter. In JS, Mojo functions that specify a response return |
| 170 a Promise object. The Promise resolves to an object with one property per |
| 171 response parameter. In the EchoString case that would be something like |
| 172 {value: "foo"}. |
| 173 |
| 174 Similarly, the implementation of a Mojo interface functions that specify a |
| 175 response, must return a Promise. The implementation of EchoString() could |
| 176 be written like this: |
| 177 |
| 178 MyEchoStringImpl.prototype.EchoString = function(s) { |
| 179 return Promise.resolve({value: s}); |
| 180 }; |
| OLD | NEW |