Over on the mobile team we've been chatting for a while about the various
trade-offs in native vs HTML-based (PhoneGap/Cordova) development.
Currently our main Wikipedia apps are all HTML-based:
* Android - HTML + Cordova + plugins
* iOS - HTML + Cordova + plugins
* BlackBerry PlayBook (and later BB 10) - HTML + WebWorks
* Firefox OS - HTML
* Windows 8 - HTML + WinRT (mostly separate UI code)
We also used Cordova and HTML for the Wiki Loves Monuments app. While it
worked and was good for quick prototyping, we've run into a number of
problems doing HTML-based development in both apps:
* performance -- especially when combining large scrolling text areas with
static controls
* compatibility -- making something that worked on Android 2.x and 4+, and
on iOS 4.x and 5+, is sometimes.... fun. Since we're stuck running in the
native web view control on each platform, we're stuck with old bugs and
sometimes have to make huge workarounds.
* platform limitations -- for WLM we had to modify the Cordova platform so
we could do a progress bar on upload. Ouch!
* platform integration -- to use system sharing features and other things
well we often need plugins for Cordova, which means either relying on
third-party code (which may not be as well maintained as Cordova core) or
writing our own (and keeping them up to date as Cordova evolves). Either
way we have to fiddle with native code to handle things like saved pages
already, so we're not playing pure HTML+JS.
* crash reports are often useless, not giving us JavaScript stack traces
For instance we recently ran into a problem where HTTPS stopped working in
release builds on Android 2.2... we got no backtraces from the system, just
knew that *something* somewhere in the WebView's infrastructure stopped
working. It was.... not fun to track down. If we'd been doing the page
loads in native Java, we probably would have gotten stack traces
automatically.
We've started a couple experimental projects as fully-native Android apps:
a Signpost app that uses native notifications to alert you to new issues,
and a Commons uploader which lets you take photos or videos and upload them
direct to Commons.
Going native on these means:
* good access to notifications, multimedia, etc
* faster startup times
* native use of Android accounts management system when doing editing
features
* more native look & feel
* no damn tricks for scrolling areas :P
* crash reports are more likely to point at something relevant
So we've been thinking about splitting up the HTML-based Wikipedia app as
well. There'll still be a big WebView in the middle of the app -- it shows
web content after all! -- but most of the UI chrome, retrieval of data, and
all the system integration will go into the native-side code.
Essentially we may reorg to:
* HTML core for the WebView -- handle section collapsing, references, table
collapse/expand, etc. Probably share much of this code with MobileFrontend.
* native iOS UI (Obj-C)
* native Android UI (Java)
* separate HTML UI for Firefox OS, BlackBerry PlayBook & BB 10
* separate HTML UI for Windows 8/RT
Firefox OS, BlackBerry 10, and Windows 8 all give us fairly good system
integration within the HTML+JS environment so we probably won't have to do
truly 'native' code on these, which is good since we'll have less time to
devote to them.
iOS and Android remain our top-tier mobile platforms, and we know we can do
better on them than we do so far...
Any thoughts? Wildly in favor or against?
-- brion