User:YuviPanda/Wikipedia app reboot

This page contains technical notes for the reboot of the Wikipedia app as a purely native application - on Android and iOS. It currently concentrates on only things that are needed for the reader experience, but a view towards being extensible enough that adding contributory features should not be that hard. It's also open enough that if / when we need to fall back to screen scraping the mobile web site (should be avoided!), it is possible too.

Content Fetching
The page contents will be fetched from Parsoid, rather than the Mediawiki API as such. There is currently a hack to get the output of parsoid (via action=visualeditor on the API) - but Gabriel tells me that there will be publicly available API endpoints in the next month or so.

Parsoid produces HTML that is annotated with lots of wonderfully useful metadata about the information. Full information about the metadata is available in the DOM API Spec. It lets us do things like detect images, infoboxes, citations, warning templates, etc - in a really structured, stable way. This allows us to be super flexible in how we want to present the information - natively or as part of the content webview.

Content Display
This will be just a regular WebView control, that mostly just displays HTML styled with CSS. JS will be minimal for now - acting simply as a glue to bubble events back up to the native code. We will be loading CSS dynamically, via RL. We can specify RL modules specifically for the app in a new MobileApp extension - that does nothing but define RL modules. This lets us change CSS without having to update the app.

Content to display pipeline
Actions that happen when the user requests to see a page.
 * 1) Hit the Parsoid API to fetch the HTML
 * 2) Parse the Parsoid HTML to rip out metadata that we want, and also perhaps simplify it to make it easier for the Webview to render.
 * 3) Load the HTML in the WebView
 * 4) Request Mobile App Specific Content CSS from RL (heavily cached)
 * 5) * Is there a good way for us to get site-, page-, and extension-used-on-this-page-specific CSS? I can envision extensions invoked by parser/parsoid specifying their RL modules or something on output, or sending a full RL CSS-loading URL with the output data, or something?
 * 6) Profit!

Communicating from WebView to Native Code
We'll need to define a very, VERY simple message passing API that lets the JS in the WebView communicate with the Native Code and vice versa. Crossing this boundary should be minimized, both for performance and code sanity reasons.

Message
The only thing that should be able to pass between the barrier should be objects that are Messages. They have a  and a , and nothing more. is essentially a JSON structure, and hence can represent anything JSON can represent. is used to route messages between various endpoints on both the native and WebView side.

Sending Messages
Sending messages should be trivial. There can be an object somewhere with a  method that takes   and   as parameters. It is then routed to the appropriate location on the other side of the barrier based on the. There are no multicast messages.

Receiving Messages
Receiving them is also trivial. There should be a  method on an object that code can call with a   and an associated callback. If there is another receiver already registered for the same, an error is thrown. When a message with the registered type is sent from the other side, it is routed to this particular callback.