I'm developing an app that has no use for taphold events, long-presses, and I want to remove them entirely.
The actual problem is the delay that jQuery Mobile UI introduces to allow it to distinguish between tap and taphold events, which causes taps to delay noticeably, making the app feel laggy. Long presses are not needed in many apps, so the delay is often useless.
Note that treating ontouch events as taps just makes it impossible to scroll.
I'm happy to patch the library if necessary, so answers along those lines are welcomed.
How do you remove the delay?
If removal is all you need that it can be achieved easily. One way would be to remove this functionality all together but it can be done through jQuery Mobile global configuration.
Also I can see this is an old question and jQuery Mobile has moved to version 1.3.1 so my answer is created to work in last version but from my knowledge it will work also on older versions.
All you have to do is change glabal parameter:
$.event.special.tap.tapholdThreshold
It is used to tell (in ms) how much time is needed for tap to be calculated as taphold.
We can rid off taphold if this parameter is set to some huge number.
I made you a working example: http://jsfiddle.net/Gajotres/U4prb/
$(document).bind("mobileinit", function(){
$.event.special.tap.tapholdThreshold = 10000000000;
});
Also be warned mobileinit MUST be initialized before jQuery Mobile initialization. Just take a look at my example and everything will be clear.
Related
I'm trying to build a Point of Sale app for ChromeOS using HTML5 and JavaScript. I'm using Materialize and jQuery for front end. When I try typing a number very quickly using the on-screen number pad, sometimes numbers are skipped. A good example would be trying to type 1752703, since it's my employee ID at my current job. Even though the CSS effect engages to show I pushed all the numbers (the ripple effect), I may end up with something like 17203 instead of the full number.
Is there any way I can improve touch performance? Is it the type of screen I'm using? What could be causing this to happen? If it's because my Chromebook is capacitive, it's not a big deal, because I could deploy this on any device I could get Chromium OS to run on. But if it's something programmatical that I can improve, that's the first step I'd like to take.
Here is the basic code I'm using for just punching in a whole number:
$(".numBtn").click(function(){
input(Number($(this).text()));
});
And here is an example of it in action (apologies for lack of styling):
Live Demo
First
The problem seems not to be the device itself, but rather the effect of having a touch-enabled device which supports pinch zooming.
On most of these devices, by default, there is a 300-350 ms on-click delay which allows most of the users to double click, or as mentioned, pinch zoom.
Google has brought a solution for this issue in 2014, when they have removed this delay by still keeping the pinch zoom function on.(1)
The quick fix for this is only one line of code in the <head>
<meta name="viewport" content="width=device-width">
This meta tag is going to disable pinch zoom for your website only by telling the browser "this is how I need to be displayed, so there's no need for zooming in the page". The purpose of it is mainly to allow a better user experience in websites with responsive design.
I have tested your website with the new meta tag and the delay seems to disappear. There is still a very small delay when you tap very fast, but the most of the users won't be able to do it such quickly.
Second
Another potential solution is to use a plugin called Tappy which replaces the click event with a tap one, promising "that it will allow you to execute code immediately on touch devices, eliminating the 300ms delay that click events have(2)."
The plugin repository can be found [here][3], where you can also look at the implementation instructions - especially at this one, which is a modified version that binds the tap event to all <a> elements:
$(document).ready(function(){
$("a").each(function(){
$(this).bind("tap", function(){
window.location.href = this.href;
});
});
});
Note that you will need jQuery to use this plugin. In case you don't use jQuery, write a comment and I will provide a vanilla JavaScript (potential) solution.
References
(1): https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away
(2): https://github.com/filamentgroup/tappy/#why
I'm developing a website for someone who requested a dynamic sliding page when you scroll (i.e. like this). At first I was thinking it was something I could use CSS transitions for, but then I realized there might be a JS tool out there which could make it work.
I discovered this page of dynamic movement examples with an associated library on github, but I'm not quite sure how to make it work. Basically, I'd like the page to listen for the event of a scroll, and then slide up a section of the page in the same way as the example above. When looking through the code for the dynamic movement examples, it seems like it's a a bunch of cases in the JS file that get used somehow in the event of a button press.
Please, if anyone is familiar with building something like this, please let me know how it might be done.
I would encourage you to make use of fullPage.js.
It is nowadays the most popular library for single scrolling pages. It has plenty of options, methods and callbacks and you can almost do whatever you think of with it.
Compatible with old browsers, kinetic scrolling (Apple laptops) and touch devices.
I'm working on a three.js project in which I am using TrackballControls to enable touch events. But I found that my code were not working properly. I also evaluated some working examples like http://threejs.org/examples/canvas_geometry_cube.html and found at start there is a small delay of 300 ms. But it do affect a lot in my project. How could I remove this 300 ms delay?
Note : I uses both single and multi touches in my project.
I went through the concept of fastclick ( https://github.com/ftlabs/fastclick ), but for me it doesn't seem to support multi touch. If I'm wrong, please correct me.
I remember hearing something about this: http://code.google.com/p/chromium/issues/detail?id=133391
According to the linked issue, in Chrome for Android the reason for the 300 ms delay is to recognize a double-tap zoom gesture. With the change made there (in October 2012), the delay will not be imposed if the page cannot be zoomed. So, at least in this case, what you need to do is set your page meta viewport options so that the page fits the device screen and doesn't zoom.
(Disclaimer: I've never tried this myself; I just heard about it once. I have no idea if this behavior is in current released Chrome for Android, and I don't know whether other mobile browsers, such as the stock Android browser, do the same.)
(Other disclaimer: I work for Google, but I don't work on Chrome, and I am not answering on behalf of Google here.)
Finally I found a way... I was using touch to drag and drop an object in the scene... The actual problem was as follows... The 300 ms delay of touch events get combined to form a large delay... In order to overcome this, I gave a condition so that touch move events are taken with a delay of 300 ms... i.e if one event is taken, the next event taken will be the event after 300 ms... and its working quite fine...
My team is in the process of prototyping an application with a rather complex UI. One common feature of the application is a number of tools which pop up above the main app and allow users to perform some complex operations.
Currently a consultant has wrote some custom code that displays the dialog and blocks the background UI. It works fairly well however we have hit bugs which have taken time to fix. Since we have had some down time we have investigated "better" ways of achieving our desired functionality. I have investigated Jquery UI and was able to establish the same functionality in about an hour. One issue I have had with Jquery UI is constraining tabbing to the dialog box displayed in IE. In IE the the tab index jumps to the background UI and I believe this issue is recognized in Jquery UI. http://bugs.jqueryui.com/ticket/3768
I was able to find a small plugin that fixed this issue for IE, however it broke the tab constraining in Firefox. I was able to make this work by putting a conditional IE check in my JS and only applying the plugin when the browser is IE. Under our current approach we do not handle tab constraining, however our consultant believes we can easily accomplish this.
My question is, which is the better approach, create our own custom solution or use Jquery UI + the plugin + the hack? When are IE hacks acceptable?
I'd go with jQuery UI because at least they'll maintain the library for you, and perhaps eventually release a fix for the issue you're talking about, and then you can remove the hack. Sometimes hacks are necessary. It beats having to maintain an unthoroughly tested custom library.
Writing a framework from scratch is always more difficult and time consuming than hoped because you will run into many issues that you simply cannot account for ahead of time.
That said, I would suggest creating a custom facade over the Jquery UI + the plug in + the hack. This would give you consistent API that meets your project's needs, the use of an established and well-maintained framework and hide some of the peculiarities between browsers. (IE hacks are unavoidable.)
I'm wring a custom jQuery plugin based on the awesome jGrowl plugin. I just need it to do a few more things than it already does.
Basically everything is working as I need it to (only tested in Firefox so far) except that if you call the plugin too many times too fast it stops and breaks everything
http://jsbin.com/ofejo/edit
Any ideas about what might cause this?
sounds like you need to implement a callback feature and put the additional calls into callbacks to ensure that the plugin processes before other executions occur.
It's rendering and trying to calculate where to place the block but failing because there's an animation already taking place. (often an animation changes the type of display style being used in order to create the effect and this causes oddities with calculations such as these)
You need to queue the effect, but I'm not precisely sure how you would go about it because you're creating new elements, and there's more source code than I am willing to look through at the moment. Let me know if this helps.
http://docs.jquery.com/Effects/queue