cordova-browser platform and Hosted Web Apps: the "isSupported(feature)" function

[Rob Paveza <Ro...@microsoft.com>]

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 offer when it comes to supporting W3C things where available.  (Just as an example, I've had trouble recently with the geolocation plugin in the browser not actually giving me data even when permitted).

I wanted to know your thoughts on the idea of creating a standard "isSupported(featureName)" function for plugins where it would make sense.  Platforms could indicate support for a particular function call.  The camera plugin is a great example; it's supported in browsers that have [navigator.getUserMedia](https://github.com/apache/cordova-plugin-camera/blob/master/src/browser/CameraProxy.js#L90) (probably Chrome).  Rather than pivoting there on calling takePicture and having the alert dialog pop, the use case could be to write code to conditionally show a button to take a picture if it's supported:

if (navigator.camera.isSupported('takePicture') {
_______ {Browse...} {Take Picture}
}
else {
_______ {Browse...}
}

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 EVERY 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?

Thanks,
-Rob

RE: cordova-browser platform and Hosted Web Apps: the "isSupported(feature)" function

[Josh Soref <js...@blackberry.com>]

(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
offer
> when it comes to supporting W3C things where available.  (Just as an
example,
> 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
camera
> plugin is a great example; it's supported in browsers that have
> [navigator.getUserMedia](https://github.com/apache/cordova-plugin-
> camera/blob/master/src/browser/CameraProxy.js#L90) (probably Chrome).
> Rather than pivoting there on calling takePicture and having the alert
dialog
> pop, the use case could be to write code to conditionally show a button to
> take a picture if it's supported:
> 
> if (navigator.camera.isSupported('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
EVERY
> 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?