RFC: Mobile Platform Support

[ibgreen]

For #

Background

• This is intended as a strategic alignment RFC, Align tech leads on a "longer term" strategy for Mobile and Native Mobile Platform support
• If someone picks up this work, it will be advantageous to have an agreed-upon strategy for how what should be done.

Change List

• New RFC.

[coveralls]

Coverage decreased (-2.4%) to 80.674% when pulling 3496533 on ib/mobile-platform-rfc into 7cdf284 on master.

[tgorkin]

I agree that the WebView approach seems like the most logical to initially research. A concern will be mobile browser WebGL version and extension support. Is there any "prior art" we can refer to, such as three.js with WebViews that we can look into to evaluate the scope of this work and viability?

[ibgreen]

A concern will be mobile browser WebGL version and extension support.

deck.gl already run on mobile browsers. Not sure on current state, WebViews used to have some limitations compared to the main mobile browsers but should support same WebGL extensions.

Is there any "prior art" we can refer to, such as three.js with WebViews that we can look into to evaluate the scope of this work and viability?

We should look around though I am not aware of any pre-packaged setups, as what is being served in the webview is a deployed URL, not a framework.

This is where the "native API messaging proxy" comes in to let the native app and deck.gl talk... as one idea, maybe we can use our JSON transport to create native Android/iOS layer classes similar to how pydeck offers python classes...

Also, @tsherif has worked with a similar setup in the past and had good experience with WebViews, and suggested the integration SDK approach.

[tsherif]

My understanding is that the Webviews on iOS and Android are essentially the renderers from their default browsers, so I don't expect there to be any compatibility concerns other than the ones already existing in those browsers.

The pieces I imagine being involved in this are:

• Decouple input handling from deck core. This would involve setting creating methods to control deck programmatically separating that from a set of default handlers that would implement the current interactions. This would allow us to set up alternative input handling to that used for the web and potentially allow native input events and UI elements to control deck.
• Set up whatever callbacks are necessary for the native application wrapping deck to send and receive messages from deck. I believe this is simply a matter of checking for some global variable and setting up callback functions if they exist, but it's been a while since I've looked at code that does this.

Overall, I don't think it would be too difficult to make deck amenable to be used in a webview.