The troubling part here is that WebSQL is broken (iOS7 introduced new bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended to
be used on these devices. But then it's still crap and buggy. I started
poking at it to see if I could replace this with a shim of IndexedDB with a
Cordova plugin (maybe File, more likely something specialized) as the
backend. That's probably possible, though it was complicated in a couple of
places by the fact that some IDB/WebSQL calls are sync but all Cordova
native calls are async. Probably still possible to do that port, if we
think it's worthwhile. It would be a nontrivial project, though, and the
IDB interface and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux <b...@brian.io> wrote:
> Deprecated.
> On Sep 19, 2013 5:04 AM, "Andrew Grieve" <agri...@chromium.org> wrote:
>
> > If it's easy to support, then I think it's worth doing.
> >
> > A custom scheme would work, but I think we can do it with a less
> intrusive
> > change:
> >
> > We came up with the following hack during our chrome-apps-on-cordova work
> > for having CORS work when on a custom scheme. Should work for WebSQL as
> > well though. It takes advantage of the fact that file:/// pages can
> access
> > window objects of opened windows that are on different domains. It goes
> > like:
> >
> > The JS Code:
> >
> > var win = window.open("websql://ftw");
> > // wait for window to load. Maybe via onload event? Or via polling?
> > win.onload = function() {
> > window.openDatabase = win.openDatabase;
> > }
> >
> >
> > // The Java code:
> > app.getSettings().setSupportMultipleWindows(true);
> >
> > // In Chrome Client:
> > @SuppressWarnings("unused")
> > private WebView newWebView = null;
> > public boolean onCreateWindow (WebView view, boolean isDialog,
> boolean
> > isUserGesture, Message resultMsg) {
> > WebView.WebViewTransport transport = (WebView.WebViewTransport)
> > resultMsg.obj;
> > newWebView = new WebView(act);
> > newWebView.getSettings().setJavaScriptEnabled(true);
> >
> > newWebView.setWebViewClient(new WebViewClient(){
> > @Override
> > public WebResourceResponse shouldInterceptRequest(final
> > WebView view, String url) {
> > return a response that is just an empty page.
> > }
> > });
> > transport.setWebView(newWebView);
> > resultMsg.sendToTarget();
> > return true;
> > }
> >
> >
> > On Wed, Sep 18, 2013 at 7:43 PM, Jesse <purplecabb...@gmail.com> wrote:
> >
> > > Windows Phone has never supported it. I have always felt that this is
> > more
> > > of a browser responsibility and didn't belong in the 'phonegap
> features'
> > > matrix. Just like we don't list querySelectorAll or SVG support.
> > >
> > > Someone needs to write a JS shim that uses the File API which IS
> > available
> > > on all the devices in cordova.
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser <bows...@gmail.com> wrote:
> > >
> > > > Ok, We've been ignoring this for quite a while, but it's not going
> > away:
> > > >
> > > > There's still people who want to use WebSQL, and WebSQL is still
> > > > totally broken. Part of the reason it's broken is the fact that
> > > > Android prevents us from using the official WebSQL API on file URIs,
> > > > and that we have a nasty collision with the official API on Android.
> > > >
> > > > So, what should we do?
> > > > 1. Use a custom URI scheme?
> > > > 2. Fix the JS so it aliases the existing WebSQL, and keep using our
> > > > own WebSQL plugin.
> > > > 3. Just say it's deprecated and leave it at that?
> > > >
> > > > If we say we're tossing WebSQL by the wayside, what do we support
> > > > instead? Seriously, what do people think of this, because I'm not
> > > > sure what we should do here.
> > > >
> > > > Joe
> > > >
> > >
> >
>
