Simbul
Events, more events!
Hello,
would it possible to have more baker-relative events sent to the webView that we can subscribe via javascript? I see focus and blur events (#225) but I’m in need of other ones:
- when the index is shown/hidden on double tap
- when the user scrolls
- before/when the user switch the page (swipe left/right)
- when the user taps on top/bottom of the page
Thank you - I love this framework !!
It would definitely be useful, I agree. :)
May I just ask a couple of clarifications?
- Scrolls: you mean vertical scroll? When should this event trigger exactly?
- Switch the page: isn't that the same of #225?
Thanks! :)
Yes, I meant the vertical scroll (when the logs say 'User scroll'). I would like to run some code while the page is scrolling, but the js event doesn't work very well since it doesn't detect the inertia.
Events before switching the page would be useful if we are able to stop them...they should work like the body's load/unload events. Don't think this would be easy to implement though ...
An indexbeforeshow event with data (page name, page position in the book) could useful for the index page. We could use that to highlight the current page in the index.
Hi @benoitchantre that's an excellent suggestion, it's however part of this other issue: #350 :)
We have the focus and blur events that are related to horizontal navigation in the book. One or more event(s) related to vertical pagination would be really useful.
That one already exists, it's onscroll: https://developer.mozilla.org/en-US/docs/DOM/window.onscroll. :)
on scroll doesn't work very well, as i wrote before.
Yes, I meant the vertical scroll (when the logs say 'User scroll'). I would like to run some code while the page is scrolling, but the js event doesn't work very well since it doesn't detect the inertia.
from the Xcode logs i see a better User scroll detection. Thanks
You're right. I did some tests at the time of your previous comment and it seems that when it scrolls the code execution on the page is "delayed". However we need some more tests. He pointed out the "vertical pagination" so I was assuming the paginated version where - maybe - it works better. :)
I thought the scroll event was fired continuously until the end of the scroll, but desktop and mobile browsers doesn't handle to event the same way. That's why I asked for an event that would use less calculation when you listen to it. I should have made a better test before asking for something, sorry.
Right now (without a test in Baker), I have found that the scroll event fires at the end of the scroll as expected. Maybe it's different in Baker? Here's the test page I used. You need to open the console log to see when the scroll event is fired. If you connect an iPad using iOS6, you can open the inspector to see what happen.
I will test that next week in Baker to see what happen. I will test also pageshow and pagehide events, that sounds interesting. Did you test them already in Baker?
As I said, I did just some initial tests on scroll after @bugbot's comment. The problem is that it's a mobile device and not a desktop device, it has a limit on the activities it does concurrently. For example, in three card mode we can't load at the same time the three pages, it just won't do it. Similarly, we have to load the page after the swipe animation complete because if we try to do both, you'll get a stuttering animation AND a slow loading. There are lots of things like that in Baker (and within the UIWebView as well).
In HTML, Baker doesn't do anything different on that side from the native UIWebView provided by the Apple SDK. We are both powered and limited by that. Don't test anything that's provided by UIWebView natively. Even if it didn't work, it's out of our control, so we couldn't do much. We just test what Baker adds on top of it. :)
I have made a test in Baker to see when the scroll event is fired: I have found it's fired when the view stops to move vertically (even with inertia). You can use it with vertical-pagination or not, it works the same way. There's no need for a custom event for vertical pagination as I have requested in this post.
The scroll event doesn't work the same way than in desktop browser where it's fired continuously. It's probably to avoid to overload the cpu of mobile devices with a lot of calculations.
There's an article about scrolling performance on html5rocks.com
About the other events I have mentioned: the pageshow event is fired only once (after the load event) and pagehide is never triggered in Baker.