cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Soref <>
Subject RE: cordova-browser platform and Hosted Web Apps: the "isSupported(feature)" function
Date Mon, 13 Apr 2015 20:36:43 GMT
(recovering from a weeklong vacation)

I'm -1 on this...

Rob wrote:
> I've been giving some thought to the Browser platform and hosted apps, and
> tightening up some of the functionality that the Browser platform might
> when it comes to supporting W3C things where available.  (Just as an
> I've had trouble recently with the geolocation plugin in the browser not
> actually giving me data even when permitted).

Could you file a bug to track this?

> I wanted to know your thoughts on the idea of creating a standard
> "isSupported(featureName)" function for plugins where it would make sense.

We've ripped things like this out in a number of places.
One is the HTML UA side of things (DOM has a hasCapability() API, which Java
forced, and it's a disaster, and is now hard coded to give stupid answers).
BlackBerry 10 had some similar thing for something, and we somewhat recently
removed pieces of it.

There are various problems with these APIs, one is that developers rarely
know to update the values.

Here's a simple example:
Say I build an app using Chrome 30 or Firefox 30, with cordova-browser 4.30,
and at that time Chrome 30/Firefox 30 don't support "taking pictures" for
"some definition" of "taking pictures", so cordova-browser returns false for
"taking pictures", but this changes in Chrome 32, and Firefox 33, and
someone tries to use the app I built which was packaged w/ cordova-browser
4.30, they get the fallback path, which sort of works.

Some developer looks at my app, thinks it looks ugly, takes it, and rips out
the code and writes new code that does something differently, and it breaks
differently later.

This kind of development jitter is common.

> Platforms could indicate support for a particular function call.  The
> plugin is a great example; it's supported in browsers that have
> [navigator.getUserMedia](
> camera/blob/master/src/browser/CameraProxy.js#L90) (probably Chrome).
> Rather than pivoting there on calling takePicture and having the alert
> pop, the use case could be to write code to conditionally show a button to
> take a picture if it's supported:
> if ('takePicture') {
> _______ {Browse...} {Take Picture}
> }
> else {
> _______ {Browse...}
> }

Personally, I'd rather the camera plugin pivot on getUserMedia, and just
trigger a sheet with a file picker, and some basic settings, and a "snap
picture" button for when the user is satisfied w/ their picture.

Basically, I really really don't want you to make me spend a lot of time
adding "supports Foo" to the blackberry10 port, because it's a game of
whack-a-mole, and I'm terrible at that game.

> There are obviously going to be cases where this doesn't make sense (the
> Device plugin, for example), so I'm not suggesting that this should be on
> plugin.  I'm also not suggesting that we should gate every single function
> behind an isSupported check.
> Is there interest in anything like this?  If I started updating plugins in
this vein,
> would that be welcomed?

View raw message