Mojo for Chromium Developers1

Mojo for Chromium Developersoverview

This document contains the minimum amount of information needed for a developer-start using Mojo in Chromium. For more detailed documentation on the C + + bindings, see this link.

Terminology

A message pipe is a pair of endpoints. Each endpoint have a queue of incoming messages, and writing a message to one endpoint effectively enqueues this message on The other endpoint. Message Pipes is thus bidirectional.

A mojom file describes interfaces which describe strongly typed message structures, similar to proto fil Es.

Given a  Mojom interface  and a  message pipe , the two  Endpoints  can be given the labels  interfaceptr  and  Binding . This is describes a strongly typed  message pipe  which transports messages described by THE&NB Sp Mojom Interface . the  interfaceptr  is the  endpoint  which "sends" messages, and the  Binding   "receives" messages. Note that the  message pipe  itself is still bidirectional, and it's possible for a message to ha ve a response callback, which the  interfaceptr  would receive.

Another-on-think of this is, an interfaceptr are capable of making remote calls on an implementation of th E Mojom interface associated with the Binding.

The Binding itself is just glue that wires the endpoint's message queue up to some implementation of the INTERFAC E provided by the developer.

Example

Let's apply this to Chrome. Let's say we want to send a "Ping" message from a Browser to a Renderer. First we need to define the Mojom interface.

Module Example.mojom;interface Pingresponder {  //receives a "Ping" and responds with a random integer.  Ping () = (int random);};

Now let's make a messagepipe.

example::mojom::< Span class= "Typ" >pingresponderptr Ping_responder;::mojom::pingresponderrequest< Span class= "PLN" > request = Mojo:: Makerequestping_responder     

In this example, are the ping_responder interfaceptr, and is an request interfacerequest, which is a binding precursor that'll shortly is turned into a Binding. Now we can send our Ping message.

Auto= base::Bind(&onpong);  Ping_responderPing(callback);          

Important Aside:if We want to receive the the the response, we must keep the object ping_responder alive. After all, it's just a wrapper around a Message Pipe endpoint, if it were to go away, there ' d is nothing left to Receive the response.

We ' re done! Of course, if everything were this easy, this document wouldn ' t need to exist. We ' ve taken the hard problem of sending a message from the Browser to a Renderer, and transformed it into a problem where We just need to take request the object, pass it to the Renderer, turn it into a Binding, and implement the Interfa Ce.

In Chrome, processes host services, and the services themselves is connected to a Service Manager via message pipes . It's easy request -to-pass to the appropriate Renderer using the Service Manager, but this requires explicitly declaring our Intentions via manifest files. For this example, we'll use the Content_browser service manifest file and the Content_renderer service manifest file.

Content_renderer_manifest.json: ...   "interface_provider_specs" : {   "service_manager:connector" : {   "provides" : {  "cool_ping_feature" : [  "Example::mojom::P ingresponder"    }, }, ...  

Content_browser_manifest.Json: ...   "interface_provider_specs" : {   "service_manager:connector" : {   "requires" : {  "content_renderer" : [  "cool_ping_feature"  ], }, }, },< Span class= "pun" > ...                

These changes indicate that the Content_renderer service provides the interface Pingresponder, under the  C Apability  named "Cool_ping_feature". And the Content_browser services intends to use this feature. content::bindinterface  is a helper function that Takes request  and sends it to the renderer process via The Service Manager.

Content::renderprocesshost*=getrenderprocesshost();  Content::bindinterface(host, std::move(request));  

Putting this all together for the browser process:

Example::Mojom::PingresponderptrPing_responder; Make sure to keep this alive! Otherwise the response would never be received.Example::Mojom::PingresponderrequestRequest=Mojo::MakeRequest(&Ping_responderping_responder->ping ( base::bindonce (& Onpongcontent::renderprocesshost*  host = getrenderprocesshost  (); content::bindinterface ( host, Std::moverequest         

In the Renderer process, we need to write an implementation for Pingresponder, and ensure that a Binding is creat Ed using the transported request . In a standalone Mojo service, this would require us to implement service_manager::Service::OnBindInterface() . In Chrome, this is abstracted behind content::ConnectionFilters and service_manager::BinderRegistry . This is typically do in RenderThreadImpl::Init .

Class Pingresponderimpl :Mojom::Pingresponder { void Bindtointerface(Example::Mojom::PingresponderrequestRequest) {Binding_.Reset( NewMojo::Binding<Mojom::Memlogclient> (This,Std::Move(Request))); } void Ping(PingcallbackCallback) {Std::Move(Callback).Run(4); }Std::Unique_ptr<Mojo::Binding<Mojom::Pingresponder>>Binding_;};Renderthreadimpl::Init() {... This-Ping_responder=Std::Make_unique<Pingresponderimpl> (); AutoRegistry=Base::Makeunique<Service_manager::Binderregistry> (); This makes the assumption that |this->ping_responder| would outlive |registry|.Registry-AddInterface(Base::Bind(&Pingresponderimpl::bindtointerface),  base ::unretained (this- >ping_responder. getservicemanagerconnection ()-> Addconnectionfilter ( Base::makeunique< Span class= "pun" ><simpleconnectionfilter> (std::move (registry ...                

Powered by gitiles| Privacy

Mojo for Chromium Developers1