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 null value when the permission is off.
On Mon, Oct 22, 2012 at 5:23 PM, Brian LeRoux <b...@brian.io> wrote:
> 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 Maj <f...@adobe.com> wrote:
> > 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 environment anyways? A "capabilities" object
> that
> > is part of the cordova "core"? Wouldn't this also force all future
> cordova
> > apps, even without any plugins installed, to require all permissions for
> > platform(s)?
> >
> > On 10/22/12 12:44 PM, "Andrew Grieve" <agri...@chromium.org> wrote:
> >
> >>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'/'rear'/'external'},
> >>'resolution': '1.2MP' }] // an empty array if no cameras
> >>capabilities.frontCamera = ref to the first cameras entry with
> >>direction='front', or null
> >>capabilities.rearCamera = ref to the first cameras entry with
> >>direction='rear', or null
> >>
> >>Other examples:
> >>capabilities.locationSensors = [{type:'gps'},{type:'wifi'}]
> >>capabilities.gps = ref to {type:'gps'}
> >>
> >>
> >>Do we want any information about the current state of sensors? E.g.
> >>bluetooth currently enabled/disabled. My vote would be no, and that this
> >>kind of info should be the responsibility of a bluetooth plugin.
> >>
> >>
> >>
> >>
> >>
> >>
> >>On Mon, Oct 22, 2012 at 2:55 PM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >>> 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.capabilities.* bucket feels right
> >>>
> >>>
> >>> On Mon, Oct 22, 2012 at 9:06 AM, Josh Soref <jso...@rim.com> wrote:
> >>> > 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.
> >>> >
> >>> > (And yes, that W3 RDF monstrosity is too, but that's no reason to
> even
> >>> look at it...)
> >>> >
> >>> > If the requirement is "I want to be able to lazy load the camera
> >>>plugin,
> >>> and only if there's a camera available", that seems to violate the
> >>>plugin
> >>> model, and the response should be "we promise to try to make the camera
> >>> module load/fail quickly if there are no cameras available".
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > This transmission (including any attachments) may contain
> confidential
> >>> information, privileged material (including material protected by the
> >>> solicitor-client or other applicable privileges), or constitute
> >>>non-public
> >>> information. Any use of this information by anyone other than the
> >>>intended
> >>> recipient is prohibited. If you have received this transmission in
> >>>error,
> >>> please immediately reply to the sender and delete this information from
> >>> your system. Use, dissemination, distribution, or reproduction of this
> >>> transmission by unintended recipients is not authorized and may be
> >>>unlawful.
> >>>
> >
>
