I am working on a Kiosk Touch Screen application and using the JQuery.keypad plugin and noticing some major performance issues. If you click a number of buttons in rapid succession the CPU gets pegged, the button clicks don't keep up with the clicking and some button presses even get lost. On my dev machine this isn't as noticeable, but on the Kiosk itself with 1 gig of ram it's painful.
Trying the demo keypad at http://keith-wood.name/keypad.html#inline the one with multiple targets (which is the case with mine) has the exact same issues.
Does anyone have any suggestions on how we might be able to improve this? The Kiosk runs in Firefox only so something specific to that would work. I'm using v1.2.1 of jquery.keypad and just upgraded to v1.4.2 of jquery.
Looks like Keith Wood came through on the jQuery forums.
http://forum.jquery.com/topic/jquery-keypad-performance-issues
What was happening is on focus of the input the keypad kept being recreated. The very simple solution is to only recreate the keypad if the keypad target changes.
With code like this:
$('.inlineTarget').focus(function() {
keypadTarget = this;
$('#inlineTargetKeypad').keypad('change', {target: this});
});
Should be changed to the following to fix the issues:
var keypadTarget = null;
$('.inlineTarget').focus(function() {
if (keypadTarget != this) {
keypadTarget = this;
$('#inlineTargetKeypad').keypad('change', {target: this});
}
});
Leave an answer Keith and the points go to you.
Related
i want disable browser back button and refresh button. in angular
example my source
page source :
"use strict";
.controller("wizardSecondController", function($scope, $state, $stateParams, wizardManager) {
$scope.$on("$viewContentLoaded", function(event, data) {
});
i want prevent browser back and refresh .
please answer .
If you want to disable browser back button in angular, please try out the following code. It may help.
$scope.$on('$locationChangeStart', function(event, next, current){
event.preventDefault();
});
It's not a very straight forward thing in Angular.js but you can use JavaScript function - window.onhashchange to disable to back button.
Take a look at this link, you might get better ideas.
Use javascript event
window.onbeforeunload = function(e) {
var dialogText = 'Dialog text here';
e.returnValue = dialogText;
return dialogText;
};
refer
I shall give you advice as to disabling the back button:
Strictly speaking it isn't "possible" if using standards, but there are workarounds.
There is the window.history object which includes a small API.
But it doesn't allow you to double check for states/pages before the user surfed to your site. Obviously for security reasons and not by accident or missing implementation.
There's various checks for the usage of navigating back in the history and several posts about that topic, but none is helpful as to when it comes to the point the user leaves your page and goes beyond your accessible history.
As to that, check on the events
onhashchange
onpopstate (be aware IEs implementation thereof is half-baked, even in IE11 --> in my case it didn't respond to mouse interaction, only to js history.*()
If you want to catch the user on your site for some hopefully incredibly good purpose:
Create a duplicate entry of your home page on the first homepage-hit via window.history.pushState and instantly window.history.forward() --- (this works especially well and unnoticable on SPAs)
Reiterate that procedure every time the user navigates to your homepage/lowest_level_parent_state ...
Et voila ...
In my case I can't even escape our page if I hold down the backspace button ...
Another convenient option would be to put the page into fullscreen mode if feasible :)
Cheers, J
Bounce Exchange has figured out an almost perfect way of detecting if a user will leave the website. They do this based on tracking mouse gestures, mouse velocity, and breaking of the browser plane. If they detect someone is leaving they fire off a popup on a lightbox.
I can poorly emulate this, by the following:
$("body").mouseleave(function() {
jQuery('#avoid-bounce').show();
});
The only problem is this is rather annoying. Even if it captures someone, the moment they leave the body it fires again.
How probable would it be to factor in mouse speed and allow the event to fire only once? I'm still fairly new to JavaScript and jQuery, but I'm learning.
This is exactly what .one() is for:
$("body").one('mouseleave', function() {
jQuery('#avoid-bounce').show();
});
You can add a flag to your code:
$("body").mouseleave(function() {
if ( jQuery('#avoid-bounce').data('shown') != true ) {
jQuery('#avoid-bounce').data('shown', true).show();
}
});
Creating a flag will make sure the show() code will not be called the second time.
Or you can try OuiBounce,the bounce exchange alternative: https://github.com/carlsednaoui/bounce-exchange-alternative
The following code gives me an alert with nothing but a # symbol inside it. Why?
EDIT: I should note that the code is inside a jQuery .click event...if I place it outside of that, it works properly. Here is the fuller code:
$('#continue').click(function(){
var _href = $("#continue").attr("href");
alert(_href);
});
Continue
EDIT2: This all works fine in jsfiddle. But in the xcode iphone simulator I just get #.
Judging by only the code you typed, probably the code runs too early. Try wrapping the JS in
$(function() {
// your code here
});
Or
$(document).ready(function(){
// your code here
});
Update:
Well, since it's an iPhone simulator, it changes things. Remember, nobody can help you unless you give all the details of the problem, no matter how much experience they have.
Did you try the touchstart / touchend / tap events instead of click? As far as I know, Apple has been having problems with the click events. Also, click events on mobile devices will have a slower response (a delay of approx 300ms if I remember well) so you're better just using touch specific events.
What are you building? Is it a mobile web app or? Will it run in a standard mobile browser or something like PhoneGap etc?
Update2:
Ok. It works as long as the code is not called on Click. This eliminates the possibility of another piece of code replacing your "href" with another value because that code would have to be inside your $('#continue').click(function(){ }); block.
The click event is simulated on a touch phone, that's why the touch events are faster (they are native) and less likely to cause problems. You should also make sure that you return false there and not follow the link, that might be what's replacing your "href".
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js" type="text/javascript"></script>
<script>
$(document).ready(function(){
$('#continue').click(function(e) {
var _href = $(this).attr('href');
alert(_href);
e.preventDefault();
return(false);
/*
the return is legacy code, used by some
browsers to detect if current event handler
is braking default behaviour
the e.preventDefault() function is the jQuery
way to do it
*/
});
});
</script>
Continue
Without this line the link is followed and a refresh occurs killing the current script.
https://github.com/jquery/jquery-mobile/issues/3777
Background: I have a jQuery mobile app (single .htm, multi-jqm pages) where one of the pages contains a listview with a reasonably large number of list items (300-500 say). I'm testing the boundaries of performance here so currently my custom "paging" will use CSS to hide all but 25 of the items at a time. The app is deployed to devices using PhoneGap.
So, to my question.
I've found that when clicking on an item in the list, navigation to the page the list item links to is extremely sluggish on devices when I use the code below. This handles the click, extracts an id from the list item and stores it, then allows the click to perform the page navigation:
$('#largeListView').on('vclick', 'a[href="#subView"]', function (e) {
theSubView.setId($(this).data("id"));
});
However, the code below is much quicker. It stores the id also but then prevents the click causing the navigation and manually changes the page instead:
$('#largeListView').on('vclick', 'a[href="#subView"]', function (e) {
theSubView.setId($(this).data("id"));
e.preventDefault();
$.mobile.changePage('#subView');
});
The only downside of the quicker solution (as far as I know) is that the item does not show any UI feedback that a click occurred.
Does anyone know why I get the vast speed improvement here and if there is a way of speeding up option 1 instead?
I don't like circumventing the design in this way and would prefer to use option 1 if I can get good performance.
Thanks!
Chris.
just a guess but maybe this happens due to the fact that the default browser behavior triggers custom events and invokes some scrolling mechanism whereas the $.mobile call avoids this overhead...
I do not think you can improve that so easily but maybe try to use a small delay to perform this asynchronously
$('#largeListView').on('vclick', 'a[href="#subView"]', function (e) {
var id = $(this).data("id");
setTimeout(function() {
theSubView.setId(id);
}, 0);
});
I've got a problem about onbeforeunload recently that I need to pop up a voting page when users try to close their IE browsers.I did it by using:
<body onbeforeunload="makevote()">
And the main structure of makevote() in javascript is as follows:
function makevote()
{
comet.distruct();
if(csid != null && isvote == null)
{
window.event.returnValue = false
window.event.returnValue='press “cancel” to vote please！'
showComDiv(popvote,"popiframe",400,120,'your vote here','dovote()');
}
}
In last three months this voting function performed so ugly that I got only less than 8,000 votes from more than 4,50,000 vistors.I think the problem is, when the users try to close their browsers,the onbeforeunload property pops up a comfirm box which covered my voting box while most users click the OK button,which means close comfirming is done,as a habit.So my question is how can I control the comfirming box made by onbeforeunload myself? For example if I click the "OK" ,I'll go to the voting box instead of closing my IE.So far what I can do is only defining the message it shows.And is there any other better way to do this?Help would be greatly appreciated!
Regards
Quite simply, you can't.
This is built-in behaviour, designed to only allow very minimal changes for security purposes. It's the same in every browser; FF, Chrome, etc, all will behave the same way.
The primary purpose for the beforeunload is for things like allowing the users the option to save changes before their changes are lost.
Besides, if your users are leaving, it's already too late - they won't want to answer a survey anymore, they're done!