We could always give it a go as a non-core plugin (incubation?), then
once it matures we can graduate it to core.
On Mon, Oct 22, 2012 at 2:39 PM, Andrew Grieve wrote:
> Haven't tried it yet, but it looks like you can see if various things exist
> without having Camera permission on android using
Haven't tried it yet, but it looks like you can see if various things exist
without having Camera permission on android using:
http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_CAMERA
If things do require permissions, then I think it would be reasonable to
use a
capabilities api is lower level than plugins that would leverage it.
(there could be MANY camera plugins for example...and there are.)
think of it as a runtime introspection concern. it should be core, and
not a separate thing, like whitlisting or whatever
On Mon, Oct 22, 2012 at 2:03 PM, Filip
It could get populated/updated by the plugins in charge. The purpose is
informational. If a capability is disabled/not present then the
capabilities object will just have that info.
I like the one object approach myself. I would include it as a device
property though. Something like: device.capabil
I would take it one step further and have it be the responsibility of the
plugin in the first place to track the capability.
I don't like a flat `capabilities` object that is decoupled from the
plugin in charge of it in the first place. How would this even fit in a
fully-pluginable Cordova environ
I like device.capabilities or directly on device.
Maybe a naming convention would be a good idea for the different types of
things?
Figuring out the properties might take some time. e.g. we may not need a
bool for frontFacingCamera, but instead:
capabilities.cameras = [ { direction = {'front'/'r
The longer view would seem that we would want to think this through
more and give a unified API for any kind of device hardware/sensor
inquiry. I'm a fan of keeping that decoupled from interacting w/ the
objects of introspection too---this should be a core part of the
platform.
window.device.capab
For his specific requirement "I need to know if there's a camera", certainly
the camera API could choose not to be available if there's no camera, and
merely:
window.device.camera == false ?
or wherever cordova puts the camera.
A capabilities API is absolutely overkill for his requirements.
(
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 ha
+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 to
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
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 cod
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:
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
http://www.youtube.com/watch?v=Drkh0YLF8rI
On Fri, Oct 19, 2012 at 5:24 PM, Shazron wrote:
> I would think all the properties would return a boolean?
>
> So for example, an iPhone 3GS would be:
>
> window.device.capabilities.frontcamera == false
> window.device.capabilities.backcamera == true
> w
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 wro
I would think all the properties would return a boolean?
So for example, an iPhone 3GS would be:
window.device.capabilities.frontcamera == false
window.device.capabilities.backcamera == true
window.device.capabilities.flash == false
window.device.capabilities.compass == true
window.device.capabil
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("h264r
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 wrote:
> Hmm so then standardizing the .capabilities object become
Hmm so then standardizing the .capabilities object becomes the hard part?
On 10/19/12 4:56 PM, "Shazron" 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:5
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 wrote:
> I dunno, I think this is independent of the current APIs. (More than
> one API we have deal
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 b
Tack on a .yep boolean onto every API surface?
On 10/19/12 2:25 PM, "Brian LeRoux" 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 qu
23 matches
Mail list logo
