incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: capabilities api
Date Sat, 20 Oct 2012 00:52:15 GMT
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 <purplecabbage@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 <shazron@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 <shazron@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 <purplecabbage@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 <fil@adobe.com>
wrote:
>>>>>>> Hmm so then standardizing the .capabilities object becomes the
hard part?
>>>>>>>
>>>>>>> On 10/19/12 4:56 PM, "Shazron" <shazron@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 <fil@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

Mime
View raw message