Issue with click delay in iOS and Android apps

I search why app performance in ios was slow.So I found it.

"This delay occurs because the operating system is waiting roughly 300ms to see if the user is going to tap the target again (and therefore perform a double-tap)."

https://ccoenraets.github.io/cordova-tutorial/avoid-300ms-delay.html

David,can you add fastclick as normally function in appbuilder?It will solve other ios dev too.thanks.
or it already have it?

ref

https://github.com/ftlabs/fastclick

https://www.youtube.com/watch?v=0_SmLvffT_4

example with fastclick and not (open in mobile browser)

http://ftlabs.github.io/fastclick/examples/layer.html

Hello tin,

Thanks for your research. Please, let me to take a look. I will inform here about any progress. :)

---

Hello tin,

Ok! A little more about this! I know about the "300 ms" issue in the past and for that the AngularJS's Touch module is integrated in the App Builder applications. Taking a look at the module's documentation today I can see a deprecated note about the ngClick directive provided by the ngTouch module: they are now disabled by default, and therefore we need to activate it by ourself.

We can do it, however, AngularJS recommend now the usage of the FastClick library to deal with the 300 ms, so this is what the new App Builder releases does, that is, now our App Builder applications incorporates the FastClick library from the scratch. We no need to do anything, that is, we can continue working like until now, but behind the scene our applications uses FastClick now.

Please, tin, update your App Builder copy and try it. And thanks for your suggestion! :)

---

Wow.thank david.I will test on IOS and will tell you about performance result.
another library that I found is hammer-time.It up to date then fastclick
https://github.com/hammerjs/hammer-time

Hello tin,

Please, let me if the FastClick integration works as expected! On the other hand, I remember trying with Hammer in the past. Certainly I can take a look again. Anyway FastClick is not updated... because probably they no need to be updated! Don't touch the things if everything works well! Seriosly, AngularJS recommend the usage of FastClick, so I think this is the choice now. :)

---

I test it,David.On android performance was better now.
but in IOS 9.02 still laggy. 300 ms problem still there.
I see your code,that you add fastclick in builder.js and attech it in app.js :)

Hello tin,

Since we are talking right now on the support chat, I am not sure about what to say here. :)

Apparently FastClick is running well, since they works in all environments, and also on iOS. Maybe the results is not what you expected... but certainly it's difficult to measure 300 ms of time... In my opinion we no need to worry about this, since we are following the AngularJS instructions to integrate FastClick in our applications.

---

Hi guys,

Have the same issue here. We have an app partly built by Cordova from scratch and leaderboard built by AB. We had that click delay problem in the Cordova part that we fixed by replacing the "click" event with "touch". AB parts however are still a bit laggy. I was wondering, is there a way that we do the same for AB too? so it uses "touch" event rather than click?

This is the part built by AB: https://lingolish.com/global-leaderboard-tips.html

video showing the delay. The starting parts are built directly by Cordova, after second 3, the colourful leaderboard, Timer... are built by AB

By the way, re. FastClick, as we searched, "Note: As of late 2015 most mobile browsers - notably Chrome and Safari - no longer have a 300ms touch delay, so fastclick offers no benefit on newer browsers, and risks introducing bugs into your application. Consider carefully whether you really need to use it." https://github.com/ftlabs/fastclick

Hello Amin,

In principle, AB apps doesn't have the "300ms of delay" problem, that is, we use the appropriate stuff to solve that in the past. Honestly, I don't think that we can do nothing about, except to note somethings, that maybe can enhance the GUI response. Let me to explain a bit.

If we follow the URL that you refer in your post (it's important to do it in avoiding any possible cache, since we can see what I want to explain mainly the first time we visit the URL) we can see a similar delay also in the browsers.

Maybe I am wrong, but, if you click or tap again in the menu items, that is, if you repeat the operation, the items changes faster, that is, more or less as expected. We can see this also in the browsers.

So my suggestion is to take a look at the app's code, and, look if they can be enhanced in some way, for example, if we can change the menu's items colors before the Report's data is trying to load or end to load.

My suggestion, in other words, is to try to change the menu's items before any other thing, seeing if this can do something useful: what we wanted is that the items' colors changes before we try to load the Report or anything else.

Note that do not have any problem to add other possible event or something like that: it's just that honestly I think that AB already does whatever is possible in order to get the best results. Maybe I am wrong and miss something... but this is what I can say right now...

P.D. About the usage of FastClick... I need to investigate it and see if certainly we can avoid their usage or what. However, it's rare that the library interfere in some way if they are not needed... the programmer maybe take this in consideration... but I want to investigate this anyway.

---

Hi David,

Thanks for taking a look and for the tips. Knowing that it has nothing to do with the 300ms delay, actually helps a lot, so now I know where to look for the source of the problem. I agree, changing the sequence of loading may improve the performance. Will try your recommendations and build a test flight for iOS. Will keep you posted on how it goes.

Thanks a mill for your swift response as always :)