(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?
smime.p7s
Description: S/MIME cryptographic signature
