Hacker News Reader

Comment by walexander | Hacker News Reader

I don't know if the convergence will happen, but they certainly need to fix WebView in Android to at least allow migration. It's still using the old Android Browser and is severely outdated (no WebSockets, etc).

My guess is that Chrome Packaged apps will be the replacement for WebViews on Android.

Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview

View on HN

From the ChromeView github page:

"Attempting to scroll the view (by swiping a finger across the screen) does not update the displayed image. However, internally, the view is scrolled. This can be seen by displaying a stack of buttons and trying to click on the topmost one. This issue makes ChromeView mostly unusable in production"

Have you used ChromeView successfully in a production application? This seems like a deal killer.

I forked ChromeView, and then the more time I spent with the Chromium build and codebase, I realized the content shell was a better starting point, so I created a similar project that uses different chromium artifacts as a base: https://github.com/davisford/android-chromium-view; scrolling has no issues at all. There are a few quirks, and myself and a few other people are discovering them and finding ways around them -- since we all want to use Chromium for our various projects.

A WebView in a native app always seemed like a really hacky way of doing it, so a proper Chrome App functionality would be fantastic. Just like how Firefox does it (even on Android, in the Aurora builds)

> Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview

A stop gap that adds at least 30mb to your application is a really shitty solution.

This isn't 100% true. The majority of that is the native shared library and binary resources. These could be hosted centrally and loaded from an APK. It isn't totally necessary to package them in an APK.

But in that case you're both drawing attention to the fact that your app is HTML5 (which thanks to Facebook is associated with a low quality experience) and also that the user has to download a separate library in order to run it. You'll likely get a significant portion of bad reviews solely motivated by this, just as with apps that require the user to download Adobe AIR separately.

For example: https://www.google.com/search?q="requires+adobe+air"+bloatwa...

In my case, I happen to be doing something completely different with AOSP. I'm not looking to build a webapp for the Play store. We are embedding AOSP on our own hardware.

Also, I don't care what Facebook says.

You still have to download the library at some point, and the library has to end up in your app's private libs folder. Android doesn't do dependencies or inter-app shared libraries outside of those that are part of the platform.

If you embed Android yourself, you can make it do anything you want.

Actually, it's just what I was looking for in this announcement from Google. We currently deploy our internal apps on phonegap, and I want the snappy and the APIs that Chrome offers over the stock webview.

Reply on news.ycombinator.com