I think we should have one per device and we might eventually want to support some keyboard-related ones as well to include differences between real and various on-screen keyboards.

-- Blake Sullivan

On 6/13/11 10:52 AM, Andrew Robinson wrote:
We could have it return constant strings of "none", "single" and "multiple" if that would suit our needs.

So my question is if we want one capability per-human interaction device or multiple?

Option 1, one-per:

   1. touchScreen capability
   2. mouse capability
   3. drawingPad capability

Option 2, one that returns a set
"interactionDevices" capability with "touchScreen", "mouse", "drawingPad", etc.

If using the former, we could have strings returned and not boolean (touchScreen could return "multiTouch", "singleTouch"). Not sure how that would look for option 2 other than a Map<String, String> being returned, but that API seems a bit ugly to me with having to down-cast the capability value to a generic collection.

Thoughts?

On Mon, Jun 13, 2011 at 10:31 AM, Blake Sullivan <[email protected] <mailto:[email protected]>> wrote:

    On 6/13/11 9:22 AM, Andrew Robinson wrote:
    https://issues.apache.org/jira/browse/TRINIDAD-2108

    I am proposing to add a new Agent capability for touch devices.

    It would involve adding:
      static public final CapabilityKey CAP_TOUCH_SCREEN =
              CapabilityKey.getCapabilityKey("touchScreen", true);

    To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And
    also adding the code to add this for the Andoid and iOS devices.

    Any comments? Name of the key sound reasonable to everyone?

    Thanks,
    Andrew
    I think that we want to consider the cases where the device
    supports both touch gestures and other input devices at the same
    time.  So, it depends on the expected usage.  Are consumers of
    this api supposed to use it to query whether the device could send
    them touch events, or are they expected to use it to determine
    whether the device is primarily touch?  If it is for the first
    case, then I think we should expand the values to encompass the
    quality of the touch events.  For example, is multi-touch
    supported? Anyway, we know from experience that we really don't
    want to ever add any boolean values.

    -- Blake Sullivan



Reply via email to