Response title
This is preview!
Move this topic
Event handler firing one time only
in jQuery Mobile
•
3 months ago
This is truly odd. I've got an index.html file that uses a pageshow event to register a button handler:
$("#mainPage").live("pageshow",function(event) {
console.log("pageshow for mainPage");
$("#submitButton").one("touchend",function(e) {
This is used to handle login logic. When I run my app, this works perfectly one time. I only return to this page when I logout. I can confirm that when I return that the pageshow log shows up. But the submit button handler isn't registered. I can even do
console.dir($("#submitButton"))
just to confirm it is still in the DOM, and it definitely is. But it is like the one() refuses to register the event. Btw, I tried one() because I thought maybe my on() was registering the event twice.
1
Replies(8)
Re: Event handler firing one time only
3 months ago
It's doing exactly what you asked it to do. .one() automatically de-registers itself after it has fired once. That's why it's called one.
You probably wanted to register it on pageinit.
Again, it's acting exactly as it should. You're registering it on pageshow, so you will register it every time the page is shown. If you show the page twice, now it's registered twice, because you will have received two pageshow events.Btw, I tried one() because I thought maybe my on() was registering the event twice
You probably wanted to register it on pageinit.
Leave a comment on watusiware's reply
Re: Event handler firing one time only
3 months ago
Right, I get that one works once. But if I run it again, after it was fired and removed, is it not true that it should register again? I don't think one means "one time forever", but simply, "No more than one". So after I fired it and it was removed, it should be able to register again.
I tried pageinit too, but I had the same issue.
Leave a comment on cfjedimaster's reply
Re: Event handler firing one time only
3 months ago
Instead of debugging a workaround that didn't work, why don't you tell us just what you're trying to accomplish?
I'm guessing (though I can only guess) that you simply want to fire the callback every time the user presses the submit button. If that's what you want, use this (load in a script called in <head> of every page.)
If you don't need to be quite so efficient, you can shorten it:
(In the second example, the event will bubble up to the document. In the first, the event is fired directly from the button element.)
Notice that I have used classes, rather than IDs. Using IDs is a habit you will have to get out of with JQM. If you duplicate one on different pages, you will get unexpected results. If you don't understand why this is, you don't understand JQM's AJAX model.
I also did not use .live(), since it has been deprecated since jQuery 1.7, and will be removed completely in 2.0. Better to start re-writing your code now.
Finally, I used vclick rather than touchend. touchend limits you to touchscreen devices. The button won't function on a desktop or even on a touch device if using a mouse. (Which is possible, for example, by using a Bluetooth mouse.) vclick gives you the same timing, without unnecessarily losing mouse support.
I'm guessing (though I can only guess) that you simply want to fire the callback every time the user presses the submit button. If that's what you want, use this (load in a script called in <head> of every page.)
- $(document).on("pageinit", ".mainPage", function() {
- var $page = $(this);
- $page.find(".submitButton").on("vclick", function() {
- // This code is run every time the user releases the submit button
- });
- )};
If you don't need to be quite so efficient, you can shorten it:
- $(document).on("vclick", ".mainPage .submitButton",
- function() {
- // This code is run every time the user releases
- // the submit button
- });
(In the second example, the event will bubble up to the document. In the first, the event is fired directly from the button element.)
Notice that I have used classes, rather than IDs. Using IDs is a habit you will have to get out of with JQM. If you duplicate one on different pages, you will get unexpected results. If you don't understand why this is, you don't understand JQM's AJAX model.
I also did not use .live(), since it has been deprecated since jQuery 1.7, and will be removed completely in 2.0. Better to start re-writing your code now.
Finally, I used vclick rather than touchend. touchend limits you to touchscreen devices. The button won't function on a desktop or even on a touch device if using a mouse. (Which is possible, for example, by using a Bluetooth mouse.) vclick gives you the same timing, without unnecessarily losing mouse support.
Leave a comment on watusiware's reply
Re: Event handler firing one time only
3 months ago
Sorry, I should have described the intent first.
In this jQM app, the home page is a login page.
Later on, I have a logout functionality. It does what it needs to to remove authentication, and then does a $.mobile.changePage back to index.html.
That worked fine, but then I noticed that I couldn't login anymore.
As far as I knew, pageinit (which is what I was using at first) was firing. To be sure, I added a console.log(). When I went to the page after logout I saw the log just fine.
Then I thought - maybe something got broken in the DOM and my button handler wasn't firing. So I added a console.log($("#submitButton")) just to ensure it found something. It did.
So for whatever reason, the handler just refuses to fire after the first time. (Btw, I'm ok with touchend as I'm building for a specific touchscreen device and using PhoneGap to wrap the app.)
This is where I am now: https://gist.github.com/cfjedimaster/4968046
Leave a comment on cfjedimaster's reply
Re: Event handler firing one time only
3 months ago
Ok, I've narrowed down the issue. It is definitely *not* a jQuery Mobile issue. I'll share what I've learned, but I certainly don't expect yall to help with a non-jQM issue. The application I'm working on works in conjunction with a RFID scanner. The RFID scanner sends input to the web page like keystrokes. Therefore, my code listens for keystrokes on a 'scan' page. When it gets the right combo (the RFID scanner prepend and appends the input with certain characters) I notice this and add it to the DOM. You click to confirm the scan and go into the real menu of stuff.
So I was testing, and sometimes my login button actually worked, and sometimes it didn't. Then I noticed something.
Our RFID scanner prepends input with a ~ and ends it with a . When I test on my desktop, I'd simply do this on the scan page:
~123.
Sometimes though - just by... I don't know, muscle memory perhaps, I'd hit enter too. Enter is *not* necessary, but I would do it sometimes.
When I hit enter the issue goes away.
So something about my key entry 'confuses' the DOM enough to break my login button.
I've got a slimmed down version of the app up here: http://www.raymondcamden.com/demos/2013/feb/16/
In order to use it, open your console and run startApp(). This is normally run by the PhoneGap deviceready event. On the scan page, enter what I did and try it both with and without a Enter keystroke.
Leave a comment on cfjedimaster's reply
Re: Event handler firing one time only
3 months ago
Um, I'm not sure why my post above is reported spam. If I did something wrong, please let me know.
I have more info to share, although my confidence on this isn't very high.
It now seems if I type too quickly, it breaks the button, versus if I type my input slow, it works right.
To be clear - in both cases I see my input show up ok. The code listening to the keystrokes has no problem with the speed at all.
Re: Event handler firing one time only
3 months ago
Believe it or not, your post contained the letters "real men". It is marked as spam.
JΛ̊KE
JΛ̊KE
Leave a comment on cfjedimaster's reply
Re: Event handler firing one time only
3 months ago
Maybe I can help:
Some time ago I was also wondering why some input element bindings where just working randomly or not at all. I don't know how often I disassembled and assembled my page in scripts in question...
Eventually I settled for this:
So:
#1
Try binding to closest div.ui-btn and see if that works
#2
I just installed Firequery (http://firequery.binaryage.com/) in Firebug... While I have not found element bindings yet (the reason I installed it), its already helpful in showing everything JQM adds to an element, which is not directly visible.
Good luck and let me know if #1 helps.
Some time ago I was also wondering why some input element bindings where just working randomly or not at all. I don't know how often I disassembled and assembled my page in scripts in question...
Eventually I settled for this:
if ( results ) {
results
// only unenhanced elements
.filter(function() { return $(this).jqmData("bound") !== true;}
// lock while in DOM
.jqmData("bound", true)
// my problematic inputs
.find('input.singleLoader')
// get the parent JQM ui-btn...
.closest('.ui-btn')
// bind to this, because this is what the user touches...
.on('vclick', function(){
// do stuff
});
}
Guess... it worked... JQM sets my inputs to ui-btn-hidden, so maybe trying to bind a click or touch handler to an element like this is not the best idea... So:
#1
Try binding to closest div.ui-btn and see if that works
#2
I just installed Firequery (http://firequery.binaryage.com/) in Firebug... While I have not found element bindings yet (the reason I installed it), its already helpful in showing everything JQM adds to an element, which is not directly visible.
Good luck and let me know if #1 helps.
Leave a comment on frequent's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to cfjedimaster's question
Statistics
- 8 Replies
- 552 Views
- 0 Followers
