To give you some more inspiration. This is how WAC does it (and I am not saying it's better than any of your suggestions).
http://specs.wacapps.net/camera/index.html#the-getcameras()-method getSomething() would return [] if device does not have that "Something" feature. I agree that we should have some extended device information (or capabilities). Native plugins, as far as I know, are lazily loaded on Android (whenever they're called/used). I don't know about iOS. Cheers Anis On Fri, Oct 19, 2012 at 6:04 PM, Andrew Lunny <alu...@gmail.com> wrote: > +1 flat hierarchy > > The use case as I understand it is > > * dev has feature in app that uses camera > * dev includes Camera plugin in their app > * app gets deployed to lots of devices, including some that may not have > cameras > > Right now (as I understand it) the process is: > > * app shows camera UI; user touches it > * camera API throws error ("I don't have a camera) > * app code handles that, tells user > > Whereas the feature request would enable > > * app detects there's no camera; doesn't show camera UI > > One thought is that if plugins can be eagerly loaded, selectively, then > they can register their capabilities right away. Failing that, plugins > could just have an "initialize" step that modifies the > window.device.capabilties object - but that could get confusing quickly. > > On 19 October 2012 17:52, Shazron <shaz...@gmail.com> wrote: > > > But that's not true -- if the Camera API is missing, the device does > > still have a camera for example. Perhaps the dev wants to > > conditionally load support for their own Camera plugin, yes? > > > > The query code would be the same (in iOS) where we detect everything > > in window.device. Whether it is fast/slow we haven't determined yet > > since it would delay deviceready. > > > > On Fri, Oct 19, 2012 at 5:46 PM, Jesse <purplecabb...@gmail.com> wrote: > > > I was thinking that if there is no camera API, or no plugin present > > > then window.device.camera will be null > > > > > > window.device.camera.supports("frontcamera"); // boolean > > > > > > However, it is easy enough to map the same thing to : > > > > > > window.device.capabilities.frontcamera = false; > > > > > > My point is, where is the code that queries the capabilities going to > > live? > > > I suggest that each plugin be responsible for detecting what it is > > > capable of, and setting values that developer code can check. > > > Otherwise we end up with a huge capabilities detection logic in native > > > that may not even be used. > > > ie. I haven't even included camera, or capture, but code is still run > > > to detect, front camera, back camera, resolution, color depth, zoom > > > capabilities, hdr, ... > > > > > > > > > > > > > > > On Fri, Oct 19, 2012 at 5:44 PM, Shazron <shaz...@gmail.com> wrote: > > >> re: the boolean properties -- I was thinking about Modernizr plus > > >> yepnope http://yepnopejs.com/ > > >> > > >> Don't know about the other platforms, but Cordova waits for the > > >> Objective-C side to return with the device properties before calling > > >> deviceready, so we need to bench it first > > >> > > >> On Fri, Oct 19, 2012 at 5:39 PM, Brian LeRoux <b...@brian.io> wrote: > > >>> plus there could be more than one camera accessing api (and there > is!) > > >>> > > >>> kinda like the flat bool property approach you propose shaz. the > > >>> calling code would be clean. worried we're going to end up throwing > > >>> lots of shit on that pile. also not sure what the perf impact would > be > > >>> like. (presumably these are blocking calls which kinda sucks.) > > >>> > > >>> > > >>> On Fri, Oct 19, 2012 at 5:29 PM, Shazron <shaz...@gmail.com> wrote: > > >>>> So... if the device is capable of something (say front and back > > >>>> camera) and we don't enable the Camera plugin, one can't query for > it? > > >>>> This is more of a device thing I think than a Camera API thing. > Can't > > >>>> think of a scenario besides diagnostics though... > > >>>> > > >>>> On Fri, Oct 19, 2012 at 5:23 PM, Jesse <purplecabb...@gmail.com> > > wrote: > > >>>>> Ask the camera API, not the device! Otherwise we will surely be > > >>>>> screwed with every new capability that ever comes out ... > > >>>>> > > >>>>> window.device.camera.capabilities// returns ... an array? an > integer? > > >>>>> > > >>>>> or > > >>>>> > > >>>>> window.device.camera.supports("frontfacingcamera"); // boolean > > >>>>> > > >>>>> window.device.capture.supports("h264recording"); > > >>>>> .... > > >>>>> > > >>>>> Since the Camera is really just a plugin to us, we should just be > > >>>>> defining a way for a plugin to describe it's capabilities on a > > >>>>> particular device. > > >>>>> > > >>>>> My 2 cents, ... back to parental leave ... > > >>>>> > > >>>>> Cheers, > > >>>>> Jesse > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Fri, Oct 19, 2012 at 5:16 PM, Brian LeRoux <b...@brian.io> wrote: > > >>>>>> ya. slippery ground. the orig query, and valid one at that imo, is > > how > > >>>>>> to find out if we have any camera, or two. > > >>>>>> > > >>>>>> window.device.capabilities.camera // returns ... an array? an > > integer? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On Fri, Oct 19, 2012 at 5:06 PM, Filip Maj <f...@adobe.com> wrote: > > >>>>>>> Hmm so then standardizing the .capabilities object becomes the > > hard part? > > >>>>>>> > > >>>>>>> On 10/19/12 4:56 PM, "Shazron" <shaz...@gmail.com> wrote: > > >>>>>>> > > >>>>>>>>We already have the window.device object -- we can tack on a > > >>>>>>>>window.device.capabilities object that could contain the boolean > > >>>>>>>>properties or something. > > >>>>>>>> > > >>>>>>>>On Fri, Oct 19, 2012 at 4:52 PM, Brian LeRoux <b...@brian.io> > wrote: > > >>>>>>>>> I dunno, I think this is independent of the current APIs. (More > > than > > >>>>>>>>> one API we have deals w/ Cameras for example.) Seems like we > > want more > > >>>>>>>>> nuance than boolean too (consider front && back camera). We are > > >>>>>>>>> definitely talking about hardware/sensors detection. > > >>>>>>>>> > > >>>>>>>>> Not loving the w3c cc/pp spec, that RDF business looks hairy, I > > think > > >>>>>>>>> we need something more approachable like you describe. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Fri, Oct 19, 2012 at 4:23 PM, Filip Maj <f...@adobe.com> > > wrote: > > >>>>>>>>>> Tack on a .yep boolean onto every API surface? > > >>>>>>>>>> > > >>>>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> wrote: > > >>>>>>>>>> > > >>>>>>>>>>>Community member Ian has noticed our lack of a capabilities > > api, and > > >>>>>>>>>>>ignoring the snipe at our foresight, I do agree its a missing > > piece in > > >>>>>>>>>>>the web platform. [1] > > >>>>>>>>>>> > > >>>>>>>>>>>There is some prior art. > > >>>>>>>>>>> > > >>>>>>>>>>>- Media queries have a couple of interesting APIs (matchMedia > > [2], > > >>>>>>>>>>>window.devicePixelRatio, and potentially a future > > >>>>>>>>>>>navigator.supportsCSS). > > >>>>>>>>>>>- Flash has a comprehensive capabilities API. [3] > > >>>>>>>>>>>- The W3C has a somewhat unwieldy take on this issue. [4] It > > should > > >>>>>>>>>>>be noted that a new working group at the w3c called sysapps > > will be > > >>>>>>>>>>>addressing this. > > >>>>>>>>>>>- Tizen has a System Info API (which I'd link to but cannot). > > >>>>>>>>>>> > > >>>>>>>>>>>Does anyone have any thoughts on how we should structure / > > develop out > > >>>>>>>>>>>the ability for our users to query the device capbilities? > > >>>>>>>>>>> > > >>>>>>>>>>>[1] https://twitter.com/iandevlin/status/259309546969903104 > > >>>>>>>>>>>[2] > > https://developer.mozilla.org/en-US/docs/DOM/window.matchMedia > > >>>>>>>>>>>[3] > > >>>>>>>>>>> > > http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flas > > >>>>>>>>>>>h/s > > >>>>>>>>>>>ystem/Capabilities.html > > >>>>>>>>>>>[4] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/ > > >>>>>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> @purplecabbage > > >>>>> risingj.com > > > > > > > > > > > > -- > > > @purplecabbage > > > risingj.com > > >
