Datapad → Android

The WebView exposes a window global Android that contains the interface postMessage(...) for sending messages across the Datapad→Android boundary. It’s presumably implemented on the WebView end as something like:

class JsMessageBridge
{
	@JavascriptInterface
	public String postMesssage(String message)
	{ 
		// Do something with the message 
	}
}

// Later
webView.addJavascriptInterface(new JsMessageBridge(), "Android");

It’s this interface that consumes the commands that Datapad issues. The command format is discussed below. Commands are replied to in a Android→Datapad return channel.

Async data resolution

A typical request issued by the frontend looks something like this:

{
	"reqId": 6,
	"type": "asyncResponse",
	"command": "GET_GAME_CONTENT",
	"payload": {
		"contentId": "page-counts",
		"contentVersionId": "87"
	}
}

Breaking it down:

• reqId is a key in a dictionary of promise handlers. The response message must use the same corresponding ID to make sure the response data is handled by the right promise.
• type is always asyncResponse.
• command is one of many command IDs that are each handled differently on the backend (see below)
• payload is specific to each command, and contains the parameters required by the backend handler for the command
  • In this case, the command is loading data from the Firebase dump. It’s issuing a request in the format starWarsGalaxysEdgeGame_{contentVersionId}_{contentId}.json, which here resolves to starWarsGalaxysEdgeGame_87_page-counts.json.

Events

The frontend can also subscribe to a number of events. An event subscription takes the form:

{
	"reqId": 227,
	"type": "asyncResponse",
	"command": "GAME_MODE_CONFIGURATION_UPDATED",
	"payload": {
		"event_type": "EVENT_TYPE_SUBSCRIBE",
		"params": {
			"gameModeId": "swgs"
		}
	}
}

While these take the same basic form as async data requests, their return channel is notably different.

Android → Datapad

Async data resolution

The PlayAPI has a static method handlePromiseReponse which can either:

• Accept a serialized JSON payload message, as issued by the Android backend, in which case it’s deserialized in place
• Accept a raw JavaScript object payload, as issues by an iOS backend, in which case no deserialization is necessary

This method is invoked directly by the native handlers, and there aren’t any direct references to it in the frontend.

A typical message dispatched by the backend looks similar to:

{
	"requestID": "6",
	"status": "SUCCESS",
	"type": "asyncResponse",
	"requestType": "GET_GAME_CONTENT",
	"payload": {
		"data": [
			{
				"lang/generated-en": 95,
				"lang/en": 12
			}
		]
	}
}

Breaking this one down:

• requestID denotes which request this data is in response to
  • The response ID is a string, while the request ID is an integer. I’m not sure why that’s the case on the native side, because the frontend handles this field perfectly fine as an integer as well.
• status can be either SUCCESS for an affirmative result, or anything else for a negative.
• type can only be asyncResponse
• requestType mirrors the request’s command
• payload is the data that has been resolved in response to the command
  • Here, it loaded the contents of starWarsGalaxysEdgeGame_87_page-counts.json and discovered there are 95 language file banks for the generated-en locale, and 12 for the en locale.

Events

Event subscriptions initially respond to the subscription request with a standard data resolution message, such as:

{
	"requestID": "227",
	"status": "SUCCESS",
	"type": "asyncResponse",
	"requestType": "GAME_MODE_CONFIGURATION_UPDATED",
	"payload": true
}

The PlayAPI has another static method nativeCallback which will also conditionally parse the data. This function is directly invoked when the native backend dispatches an event, and will fire the corresponding event in the frontend.

An event dispatch message takes this form:

{
	"requestID": "1",
	"status": "SUCCESS",
	"type": "event",
	"requestType": "GAME_MODE_CONFIGURATION_UPDATED",
	"payload": {
		"arrived": false,
		"preArrival": false,
		"previousSailing": false,
		"isGuestOnPlanet": false,
		"duringReservation": false,
		"isGuestOnShip": false
	}
}

Some notes:

• Despite the event dispatching with an ID, the ID is never utilized on the frontend
• Events with status == 'SUCCESS' will be dispatched as a CustomEvent with its type set to the event’s requestType, and the detail set to the event’s payload
• Events with status != 'SUCCESS' will fire a CustomEvent with the type set to GAME_ON_ERROR and detail set to the entire event message, instead of just the payload

Common Commands