Their method is also how I have built most of my Android apps. You use a WebView for the user interface and then use the addJavascriptInterface[1] method to allow calls from the Javascript code back through to chosen methods in the Java code. You also need to use Java when you want native settings menu and system search functionality.

Making calls from Java back into the Javascript is a bit more painful since you don't get a response back directly, but is sufficiently useful to dispatch events.

You can bundle your javascript, images, html etc in the app assets so it will still work even if there is no networking. Depending on the app network requirements it is also likely you'll want to do the networking from Java so it can manage threads, connectivity, saving resumable state in SQLite databases.

This approach is fairly easy to develop and test (you can do a lot of it in a desktop environment). The drawbacks are that elements of your UI may not appear "native" and that some events are a pain from Javascript, especially dealing with swipes.

I must admit I thought a lot of mobile apps were developed this way, and hence this article being a non-story.

[1] http://developer.android.com/reference/android/webkit/WebVie..., java.lang.String)

> The drawbacks are that elements of your UI may not appear "native" and that some events are a pain from Javascript, especially dealing with swipes.

Another drawback on iOS is that it can be hard to limit the memory that your UIWebView consumes, and it will crash the whole app if it needs to much.