incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <alu...@gmail.com>
Subject Re: capabilities api
Date Sat, 20 Oct 2012 01:04:10 GMT
+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