Touch event are very slow to be triggered in iOS devices

[guillaumebadin]

Touch event are very slow to be triggered in iOS devices. This is general in iOs devices. Android devices are ok for the touch latency.


REQUIRED INFORMATION


Ext version tested:

• Sencha Touch 2 RC2

Browser versions tested against:

• safari (iOs)

DOCTYPE tested against:

• N/A

Description:

• Since 2 beta versions of Sencha touch 2 we have a big problem in touch event on iOs devices.
• It seems when we touch a button (List/back button/bottom-bar) the framework wait 300ms before effectively make the action.
• I was shocking that is not the case in Android (Which is better reactive than iOs in this case). I don't think this is our programming problem because the problem is the same on all examples project in sencha touch RC2 folder.

Steps to reproduce the problem:

• Just go to kitchen sink or oreilly application in examples folder.
• Click on the bottom bar (You will see that the latency is very inportant)

The result that was expected:

• foo
• bar

The result that occurs instead:

• The same latency in touch event than in PR3 or in Android version.

HELPFUL INFORMATION


Screenshot or Video:

Debugging already done:

Possible fix:

Additional CSS used:

Operating System:

• iOs (iPhone 4 + iPad)

Thank to sencha team for your work.

[mitchellsimoens]

What I am experiencing is the first time there is a delay but after that it is much more responsive. This is telling me that since the other items are hidden the browser isn't dealing with them until they are shown for the first time.

Either way we will look into it as performance is very important to us.

[guillaumebadin]

Thank you very much.

I'll try to see in source code if I can patch it.

Here there is a way to override the native onClick event for webkit.
http://cubiq.org/remove-onclick-dela...kit-for-iphone

[ilmiacs]

Any progress on this?

We want to build a web application that effectively replaces functionality that normally would be built native. The observed delay, if not solved, would be a show stopper, preventig us from using Sencha Touch.

Possibly the following observations could help resolve the issue:

- The delay is not present in OS X Safari (5.1.4) and the iOS Safari in the iOS-Simulator. It is only present in iOS Safari on the real device (tested on all iPad models).
- Additionally to the Link provided by Guillaume Badin here is how David Kaneda solved the Issue for jQTouch:

http://blog.jqtouch.com/post/2051138...d-the-fast-tap

and here is the FastClick javascript Module by Matt Caruana Galizia also solving the issue:

http://assanka.net/content/tech/2011...or-touch-apps/

- The naive approach to use FastClick together with Sencha Touch does not work.

Any workaround or long term solution for Sencha Touch 2.0 would be highly appreciated.

Many thanks to the Sencha Team for their great work!

Peter

[Jamie Avins]

We do not use click events in Touch 2. We already do something very similar to this so that's going down the wrong rabbit hole. What can help us is if you have a test case or application which can demonstrate the issue and we can look into it further. There are some changes in 2.0.1 which may be addressing some performance issues with layouts/animations which is more likely the root cause of what you are seeing. But without an example of your exact issue we cannot say for sure.

[TommyMaintz]

Guys, just so you don't spend too much time on this. This is NOT related to the onClick event in the browser. We don't listen for that in the event system. We use touchstart and touchend to implement the tap event, which is what we use for buttons and everywhere in the framework. This is exactly what these "fast tap" tricks are.

The delay you see when pressing the back button is the setting up of the transition on the 2 cards. On the actual devices this can take up to 500ms sometimes. Fortunately Jacky has been able to make some really big improvements to the startup time of these animations by using a position absolute "trick". Expect the animations to happen much faster in the upcoming patch release.

Best,
Tommy

[ilmiacs]

Thank you very much for the quick reply!

This makes me more confident. However, I'm a bit confused. The top of the thread reads

"Success! Looks like we've fixed this one. According to our records the fix was applied for TOUCH-2309 in 2.0."

Does this mean, the patch is already applied in the 2.0.0 release or rather that there is a patch and one can expect the fix to appear in the next public release? If so, when can the next public release be expected?

Yours,
Peter

[Jamie Avins]

Unfortunately it doesn't put patch revisions in the forum integration at this time. We expect to release a candidate build for 2.0.1 tomorrow.

[Jamie Avins]

Can any of you with these issues provide an example or test case of the issue? We really want to be sure this is fixed and without a test case we can't be sure.

[ilmiacs]

Hi there,

The same problem seems to be present in the 2.0.1 RC release.

Just grab an iPad (I have 3rd gen.), go to Kitchen Sink -> UI -> Toolbar and watch the response times of the toolbar buttons:

- The segmented buttons behave as expected: Immediate response

- The other buttons behave badly: On an initial tap they rest in a pressed state for a noticeable delay. Subsequent taps on the same button then respond as expected. Sometimes, the buttons hang in the pressed state for an indefinite time, until an other button is pressed. This, however, is not reproducible.

Latency is crucial for our application and we now decided to go native. While Sencha Touch provides a great GUI and has the great advantage of portability, we noticed that browser interpreted javascript is simply not snappy enough just yet for our latency-sensitive application, even for simple interactions. This decision is not solely related to the button latency described above.

Peter