incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: capabilities api
Date Sat, 20 Oct 2012 01:16:39 GMT
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 <alunny@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 <shazron@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message