When quickly tapping on buttons (tested in Android 4.4 and IOS simulator), the taps are detected but there’s no visual feedback. In contrast, all clicks done on the desktop request in the buttons being highlighted quickly. The highlight only shows if I tap and hold for ~300ms(?) on mobile, but this isn’t typical user behaviour.
This coupled with the fact that the button actions are laggy in themselves makes the overall mobile experience quite poor/slow and hybrid feeling.
From what I’ve read in the forums/defects, I assumed this problem was solved, but it’s still occurring for me in beta 9.
I see there’s a 80ms delay hardcoded in ionic.js. If I switch this to a small number like 1ms, my app provides the visual feedback to quick taps that I’m looking for. Finally feels native!
Which begs the question, why is the 80ms delay there in the first place? Is this a workaround for another platform/device?
From line 3045 of ionic.js:
// in XX milliseconds, set the queued elements to active
if(e.type === 'touchstart') {
self._activateTimeout = setTimeout(activateElements, 80);
} else {
ionic.requestAnimationFrame(activateElements);
}
Correct, the 80ms is prevent any accidental clicks on items in a list. Way back at beta 1, we had an issue where items were being taped when scrolling. So to prevent this, we check first to see if your scrolling.
Lowing this number could help for your case, but it is not recommended.
Yes. A lower number makes for a much better experience IMO. I hope it works the same on all devices.
On the subject of performance, I’ve had to completely disable Ionic’s scrollbar functionality has it’s super slower when displaying a list of Cards. I’ve gone native. From what I can tell, the downside of native is the scroll position isn’t maintained after navigating back from another view. My short term workaround is to use modal’s where possible to avoid losing the scroll position.
Thank you for highlighting this. My initial reaction to Ionic along with several other people in my office was that it was extremely slow mainly due to this issue. Surprisingly, the total transition time after a quick tap is about the same between a native and Ionic app–a native app also has a substantial delay between tap and view transition, but the button always highlights immediately. I’d say about half the taps never appeared to register in Ionic, although views changed correctly.
When I changed 80 to 10, it suddenly went from feeling like a clunky webapp to a native app, although there were artifacts in scrolling clickable items, as mentioned above.
Even if 80 is a good number to avoid scrolling artifacts, maybe there’s a way to guarantee that a button at least changes to active before any view transitions begin?
When I compare to a native listview, the native view still highlights if I press down on an item and hold still without scrolling for a bit, but the time between motion and unhighlight is extremely short. On Ionic, it takes a bit longer for the item to deactivate after scrolling, so the “mis-highlight” is much more noticeable.
I’m seeing the artifacts now that I’m using buttons in a scrollable view. I’ve changed my solution to use a custom attribute ‘instantActivate’. I explicitly set this on elements/buttons that I want to activate immediately, which I know are not on scrollable views. Hope this helps somebody.
I just want to +1 the suggestion that buttons either default to instant activation or that there is a baked-in attribute/class for this instant-response behavior. I demo’d an Ionic app for work today and this complaint was raised almost immediately on the first screen of my app.
I will do as soon as I get the chance. Adding a data attribute is a good option, like data-instantActive=“true” (false by default)
I would also like to expose two variables, HIGHLIGHT_DELAY and HIGHLIGHT_DURATION instead of hard coded 80ms and 200ms, to be overridden during app.config() according to the developer needs. That will make possible to update Ionic without any problems. Any thoughts?
Thankk you guys for the tips! They speed up my app a bit.
Do you maybe have any idea how to do the same to views changes? Now with the above timeout set to almost zero it is a penny faster, but it still feels not responsive. For example, I’ve got three A tags with ng-href urls. These URLs are different state urls, but the view for each url is shared (the same). The scenario looks like this:
I touch the A tag
~500 ms later click sound is played
another ~500 ms later transition starts
again ~500 ms to finish the transition
The time is different each time, but mostly around ~500 ms per above step. What’s also unwanted is that sometimes after the click sound, a view isn’t changed at all. This is on Android which I mainly target; however on a desktop Chrome a gap between the actions is also perceptible. So, please any ideas?
It’s a smartphone Android 4.0.4 from Sony (SK17i). The same issue but shorter latency (~1/2 of the Sk17 lag) is on a device with Android v4.2.2 (1.2Ghz, DualCore, 512MB). As I said the lag is also noticeable in the desktop Chrome. I suppose there’s still a timeout somewhere in the code that involves navigation between views and transition animations.
Adding nav-clear directive to the A tag which changes states, turns the animation off but there’s no much other gain. Clicking (tapping) the links and waiting for views to load are still the same.
I could understand the time needed to load views, but there’s still the initial latency between tapping and click sound and the rest of actions.
For your information, changing the tap_max_touchtime to a shorter time helps a bit to fight the gap between tap and click sound. It’s been hardcoded as 1/4 sec.
