[dojo-contributors] Initial shape of dojo.touch + dojo.gesture

Evan Huang evanhuangwei at gmail.com
Tue Mar 8 09:49:13 EST 2011


Thanks Eduardo,

Please see my comments line.

- Evan

On Tue, Mar 8, 2011 at 4:36 PM, Eduardo Abe <eabe at us.ibm.com> wrote:
> Hello Evan,
>
> Thank you for this preview, and sorry for the delay in responding - only now
> I had the chance to look into your code with more attention.
> My feedback is similar to Emmanuel's, I believe that the auto-mapping should
> be configurable 'per component' as I can imagine scenarios where a mobile
> application will combine 'touch-aware' components with regular
> 'touch-unaware' ones.

Yep, please see my comments on Emmanuel's thread


>
> As expected, with the auto-mapping the touch-and-mouse-enabled components
> will be notified twice.

Well, in most cases we only need to listen to either one of them.


> On the other hand, I have noticed (at least on iPhone) that when the
> auto-mapping is disabled the 'touchend' event will trigger the iPhone
> default mapping (which is a 'mousemove'+'mousedown'+'mouseup'+'click') - I
> wasn't expecting that.

That's due to the native behavior(should be the same both in iPhone
and Andriod) - ontouchxxx and onmousexxx are always being fired at the
same time, so if we dojo.connect(n, 'mousexxx', callback), though auto
mapping is not effective, the native onmousexxx still get fired, so I
think the only way to break the sequence is dojo.stopEvent(e) in
onmousexxx callback.


>
> I do have some remarks concerning your Tap gesture, I believe that the
> 'tapholdcancel' and 'tapstart' are unnecessary. A 'taphold' gesture is
> supposed to last about 800ms, it is just too quick and the great majority of
> users are only expecting in two notifications: 'tap' and 'taphold'.

Agree, 'taphold' is simply cancelled by releasing touch before the
holdthreshhold and not figured out any scenario we need to hook in
something. There shouldn't be a 'tapstart' - the Tap impl was only for
testing how the base dojo.touch/dojo.gesture work, it was simply
reusing stuff in the previous demo.


>
> In the quite unlikely case of the system firing a 'touchcancel' the screen
> will become unresponsive and any 'tap' and 'taphold' gesture that might be
> happening will fail, no listeners will ever know that the user was tap the
> screen - which is the right thing to do.
>
> The same idea also applies for 'Swipe', the gesture should only fire
> 'swipeUp', 'swipeLeft' (or whatever name we decide to call them).
>
>  I have a Tap and Swipe implementation that should do the trick, I'll port
> hem to work with your code - that will cover all the basic gestures that do
> not rely on multi touch  ;-)

Cool, looking forward to that :-)


>
> Thanks,
> Eduardo
>
>
>
>
> From:        Emmanuel Tissandier <etissandier at gmail.com>
> To:        "dojo dev." <dojo-contributors at mail.dojotoolkit.org>
> Cc:        Evan Huang <evanhuangwei at gmail.com>, Eduardo
> Abe/Sunnyvale/IBM at IBMUS, rqruanqi <rqruanqi at cn.ibm.com>, zhongsq
> <zhongsq at cn.ibm.com>, "Emmanuel.Tissandier" <Emmanuel.Tissandier at fr.ibm.com>
> Date:        03/07/2011 03:00 AM
> Subject:        Re: [dojo-contributors] Initial shape of dojo.touch +
> dojo.gesture
> ________________________________
>
>
>
> Thanks Evan for this initial drop, I have tested it with my work on Dojo
> Gauges and it seems to work without requiring any changes on my side.
> I have only one comment about the automatic mapping of mouse handlers to
> touch events (dojo.touch.autoMapping). If a component has already
> implemented a touch support as well as a mouse support, then,  with this
> 'autoMapping' on , depending on the order of the dojo.connect, the touch
> support implemented in the widget may be replaced by the mouse support,
> which is not really what we want.
> I know that this auto mapping can be turned off, but I would prefer that
> this auto-mapping can be done per-component rather than globally.
> For me the best solution would be to add the touch support to the components
> that require some touch interaction...
>
> Emmanuel
>
>
> 2011/3/4 Evan Huang <evanhuangwei at gmail.com>
> Hi Everyone,
>
> Regarding this thread, we've got an initial shape of dojo.touch +
> dojo.gesture, still need more insights to ensure it's the right way to
> go.
>
> Here is the v. 0.1 version -
> http://bugs.dojotoolkit.org/attachment/ticket/12176/touch0.1.patch
> p.s - we shall be reviewing the further versions in a more convenient
> way once I finished setting up my github.
>
> The basic idea is simply intercepting dojo.connect both in
> dojo.touch/dojo.gesture, and here are more details
>
> 1. dojo.touch - usage e.g. dojo.connect(node, 'touchstart |...', callback);
>
> a. Auto mapping for onmouse* <---> ontouch*, so with this:
>   - dijit and dojo.dnd shall work well on mobile without changing the
> original event logic
>   - Mobile widgets can also handle mouse events well when running on
> desktop(since ontouch* will be automatically mapped to onmouse*)
>   - Users can also turn this off by e.d. dojo.touch.autoMapping =
> false, in that way, touch and mouse events are then isolated - this
> might be useful for devices both supporting mouse and touch e.g.BB
> tablet
>
> b. Very basic normalization works for the native touch events
> (including "orientationchange" etc., more work to be done on this with
> testing going on with more devices)
>
> c. Other events(besides the ontouch* | onmouse*...) will be simply
> passed along to the original dojo.connect()
>
> -------------------------------
>
> 2. dojo.gesture (based on dojo.touch) - usage e.g. dojo.connect(node,
> 'taphold |...', callback);
>
> a. Gesture registration
> - Eeah gesture impl(e.g. Tap) will register itself when required via
> dojo.gesture.add('new dojo.gestures.Tap()'); or if we finally choose
> to only support singleton Gesture in the same page, we can then use a
> simper way like dojo.gesture.add("Tap")
>
> b. Gesture listener managing
> - We have a { } Obj wrapping target node and gesture callbacks - this
> is is a similar way as wink does
>
> c. When native events(either ontouch* or onmouse*) triggered, we'll
> invoke start() | move() | end() for gestures that are registered(by
> dojo.connect()) on a given node
>
> d. Ideally in the future many single point gestures(e.g. tap, taphold,
> swipe, press-n-drag) should work well both on desktop and mobile
>
> --------------------------------
>
> Not pretty much to see as a demo at this point except for the
> test_touch.html/test_gesture.html in the patch(only tested on iPhone
> 3, Andriod 2.1):
> 1. test_touch.html
>    - Showing  dojo.connect(node, "touchstart | mousedown |...",
> callback); work well both on mobile/desktop
> 2. test_gesture.html
>    - Showing dojo.connect(node, "tap | taphold | tapholdcancel",
> callback); work well both on mobile/desktop
>
>
> [Open issues]
> 1. Instead of using "start | move | end" as standarlized
> events(mentioned in
> https://docs.google.com/document/pub?id=1OwgSJGNfh6jzAjHvagWj74wBxPmyiZBGishy5F96G48),
> we are now following W3C touch spec(in draft -
> http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html)  though
> it seems a bit iPhone prone
>
> 2. Whether need to support multiple Gesture instances in the same
> page? So that we can have different gesture settings e.g. different
> holdThreshold for two taphold gestures
>
> 3. Gesture bubbling & conflicts
>
> 4. More to come...
>
>
> Thanks!
>
> - Evan
>
> On Thu, Jan 20, 2011 at 11:31 PM, Evan Huang <evanhuangwei at gmail.com> wrote:
>> In case anybody doesn't notice this,  here are some key points we
>> covered during today's IRC on touch:
>>
>> 1. Split the touch stuff into two parts:
>>    a. Touch base - manager + register + [ TBD - most common Tab
>> related gestures ]   ---> put it under dojo, e.g. dojo/touch.js
>>    b. A separate gesture package, e.g. dijit.gestures? - TBD
>>
>> 2. #a - the touch base should be kept independent so that we can reuse
>> it across dijit/dojo/dojox
>>
>> 3. #b - various gestures can be required on demand(pluggable) through
>> define()
>>
>> 4. User can add new customized gestures based on #a, #b
>>
>> 5. [open issue] - how to deal with collisions among gestures during
>> recognizing?
>>
>> 6. [need double check] - onmouse/ontouch will be both fired?
>>    [TBD] - auto-generate mouse events (or nt) for dijit e.g.
>> ondijitclick -> ondijitdown?
>>
>> Thanks!
>> - Evan
>>
>>
>> On Wed, Jan 19, 2011 at 10:14 PM, Evan Huang <evanhuangwei at gmail.com>
>> wrote:
>>> Thanks, Bill,
>>>
>>> Please see my comments inline.
>>>
>>> 2011/1/19 Bill Keese <bill at dojotoolkit.org>:
>>>> Cool, glad you are working on this.   FYI, I checked in support for
>>>> drag-move a week or two ago, same changes as in your patch (although
>>>> that's
>>>> not the main part of your patch).
>>>> Seems like the main idea of your patch is that the user does:
>>>>    dojo.connect(node, "start"/"move"/"end", func)
>>>> and it connects to either touch/mouse as appropriate, massaging the
>>>> event
>>>> object into a normalized form.   Is that right?    It makes sense. I'm
>>>
>>> Yep, the idea of the touch event layer is to:
>>> 1. Make the same code(event related) run well both on mobile and desktop
>>>   - The suggested way is using dojo.connect(node,
>>> "start"/"move"/"end", func), so user don't need to care about which
>>> native events are used
>>>   - If a user still chooses the native onmousexx/ontouchxx, and also
>>> since we want to be compatible with existing dojo.dnd and dijit
>>> widgets, the layer also does the auto mapping work(e.g. from
>>> onmousexx/onMousexx to ontouchxx on mobile), so these code(e.g.
>>> dojo.dnd, dijit) can still run well both on mobile and desktops
>>>
>>> 2. Recognize various gestures and provide unified gesture events(e.g.
>>> onRotate) both on mobile and desktops
>>>
>>>
>>>
>>>> unclear what all those classes are for though, and if the user needs to
>>>> know about them.
>>>
>>> There is an abstract Gesture class and we can inherit it for a certain
>>> gesture, so we may have separate gesture classes for Rotate, Tap,
>>> Flick etc. Instead of hard coding various recognizing logic in a
>>> single class, this way shall provide better flexibility and ease for
>>> customization. We can provide a set of default gestures each supports
>>> corresponding gesture events, so user don't need to know about them,
>>> they can simply do dojo.connect(node, "onRotate", func), except they
>>> want to add a new gesture.
>>>
>>>
>>>
>>>> The other thing is that some blackberrys have both mouse and touch, as
>>>> do
>>>> some high end desktops machines
>>>> (http://www.hp.com/united-states/campaigns/touchsmart/) so I think it's
>>>> safer/easier to just connect to both touch and mouse events in all
>>>> cases.
>>>
>>> Haven't got a chance to try blackberry, I think we still need more
>>> testing for this, connecting both mouse and touch might be a problem
>>> on iPhone since both native mouse/touch will be fired which then
>>> causes double invoking on callback by default.
>>>
>>>
>>>>   If we do need to branch based on whether the device is touch enabled
>>>> or
>>>> not, should be able to do a feature detection (just google for "touch
>>>> event
>>>> detection") rather than testing for iPhone/Android.
>>>
>>> Agree, will have a further look at this.
>>>
>>>
>>>> PS:
>>>> 1) the patch is a strange format, it doesn't list dijit/ or dojox/ or
>>>> dojo/
>>>> in the file names so it's hard to tell what goes where
>>>> 2) the images in your design&impl doc don't show up for me (they are
>>>> just
>>>> blank)
>>>> 3) couldn't see the video on mac but played on windows, nice to see all
>>>> of
>>>> you
>>>
>>> 1). Not sure why, but I've breakdown the patch into three pieces,
>>> please apply them to dijit, dojo and dojox separately
>>> 2). Seems it's due to some weird issue of drawing in the google doc,
>>> should be working now.
>>>
>>>
>>>> On Wed, Jan 19, 2011 at 12:02 AM, Evan Huang <evanhuangwei at gmail.com>
>>>> wrote:
>>>>>
>>>>> So regarding the mobile touch event layer we discussed around DDD last
>>>>> year, we've got some initial progress - a detailed impl design +
>>>>> prototype, would like to get it reviewed with everybody see if this
>>>>> would be the right way to go or there is any parallel threads to
>>>>> leverage?
>>>>>
>>>>> 1. Design & impl doc -
>>>>>
>>>>>
>>>>> https://docs.google.com/document/pub?id=1OwgSJGNfh6jzAjHvagWj74wBxPmyiZBGishy5F96G48
>>>>>
>>>>> 2. Demo video - http://evan.dojotoolkit.org/touch/    - - demo.wmv
>>>>>    - Prototyping the proposal by trying out Rotate and TapHod
>>>>> gestures, also compatible with dojo.dnd and dijit.form.Slider)
>>>>>
>>>>> 3. Live demo (only tested on iPhone v.3GS) -
>>>>> http://evan.dojotoolkit.org/touch/dojox/mobile/gesture/demo.html
>>>>>
>>>>> 4. Source code of the initial prototype -
>>>>> http://bugs.dojotoolkit.org/attachment/ticket/12176/touch.patch
>>>>>    - How to breakdown gesture events is a bit different from the
>>>>> design doc, still in progress to figure out the best approach
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> - Evan
>>>>> _______________________________________________
>>>>> dojo-contributors mailing list
>>>>> dojo-contributors at mail.dojotoolkit.org
>>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>
>>>>
>>>> _______________________________________________
>>>> dojo-contributors mailing list
>>>> dojo-contributors at mail.dojotoolkit.org
>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>
>>>>
>>>
>>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>


More information about the dojo-contributors mailing list