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);
});
Related
Point
The code I have here is from my "operating system" I'm trying to create inside a browser by putting iframes in AppWindows with PHP code as the backend or the (main program process).
Now in every GUI system you have the ability to move windows, stack one on top of each others and such, but I'm not able to do efficiently in HTML using jQuery & jQuery-UI.
I'm using draggable() and some tricks I've found on StackOverflow to be able to bring the div AppWindow on top.
The problem
The code for bringing the **AppWindow** on top works fine but the problem is the iframe inside that window gets reset, because what this code is doing is that it stacks the current div as the first div above all the others inside the parent container.
If you notice the AppWindow 1 iframe blinks when you click on that window, I don't want that.
Code (jQuery)
$(function() {
// Don't know what I'm doing with iframe here...
$('.AppWindow iframe').click(function(){
$(this).parent().child.parent().append(this);
});
$('.AppWindow').click(function(){
$(this).parent().append($(this));
});
$('.AppWindow').draggable({handle:".DragHandle"});
});
Conclusion
If there is a way of preventing this from happening feel free to write an answer below. If you have a better way such as "JavaScript OS UI Framework" or something like that you're even more free to write below.I want something like **os.js** or **windows93.net** type of thing. All I need is a working taskbar, working window and a way to easily embed a PHP page inside that window that will mimic the work of the application.
I don't think it's possible. Take a look at here.
But
why do you reorder windows by change their positions in the dom in the first place? You could simply work with z-index. A basic example where you just set an active class of the targeted frame.
$(function() {
$('.AppWindow').draggable({
handle:".DragHandle",
drag: function(event, ui){
updateActiveWindow(event.target);
}
});
$('.AppWindow').on('click', function(){
updateActiveWindow(this);
});
function updateActiveWindow(el) {
$('.AppWindow').removeClass('active');
$(el).addClass('active');
}
});
with following css changes
.AppWindow.ui-draggable-dragging,
.AppWindow.active {
z-index: 1;
}
Edit: optimized the js a bit so that the window turns active once you start dragging.
The Feature I Want:
I want to give a user a link like mysite.com/foo#bar so when they hit this link they land on the page foo and are scrolled half way down the page to the content with the id bar. It should be noted that this link will always be clicked from off site or typed into the address bar manually, the user will not already be on the page with all assets loaded.
Also fyi I am using angular and the page in question each bit of content is in an element directive, and in each directive template there are images
The Issue:
Easy enough right? Well I'm running into some problems, most of the time it works, but maybe 40% of the time it doesn't and the user lands above the content, I believe this is because the browser scrolls to the correct point on the page, but then slightly afterward images are loaded in above it pushing the rest of the page down, leaving the user in a random unintuitive spot. (For some reason the failure rate seems to be worse on iPhones...)
What I've Tried So Far:
In a run function I look for a hash fragment on any route and scroll to it if it exists.
if($location.hash()) {
$anchorScroll();
}
I've tried:
Wrapping it in a timeout
This works sometimes but is obviously not consistent, sure I can set it to 500ms and on a great wifi connection it's fine, but not on a mobile with poor signal
listening for $viewContentLoaded
Too fast, ui-router seems to fire this event way before the page is rendered
Emitting an event in each post-link function for all directives on the page.
link: function ($scope) {
$scope.$emit('loadingFinished');
Then picking that up again in the run function
$scope.$on('loadingFinished', function () {
$timeout(doAnchorScroll, 500);
}
This raised the success rate but still wasn't foolproof. And I witnessed it leaving the user stranded in weird spots mainly on iPhones.
Can anyone suggest a way of detecting a moment where it is safe to scroll, or perhaps some other way of ensuring landing in the correct spot?
Two things - first is a user-scroll should prevent it - you don't want to be scrolling the view if they've already scrolled. Second is listening for the images to finish loading.
Listening for the images is quite easy:
$("img").one("load", $anchorScroll);
Then in $anchorScroll I'd suggest checking if all images have loaded, and returning immediately if not (bonus points if you only check images above the anchor - but only doing a quick reply):
var scrolled = false;
function $anchorScroll() {
var allLoaded = true;
$("img").each(function() {
if (!this.loaded) {
return allLoaded = false;
}
});
if (scrolled || !allLoaded) {
return;
}
...
The scrolling is possibly slightly harder - you can check for scroll events, but they are slightly different between platforms - and might even get fired for the manual scroll - if you find that happens then simply have a global that says "I'm scrolling here" and ignore it, otherwise:
$(document).one("scroll", function() { // Use ".on" if this gets fired for code...
scrolled = true;
});
Note that you probably don't need to care about failed image loads, or ones that have already loaded, since your initial call to $anchorScroll() will catch them.
After a lot of google'ing and reading forums I've not found a suitable answer.
So far all I have found is something like below:
show loading message
call change page
hide loading message
This would work but I would have to do this every time I call load/change page (which is a lot).
Which would leave me either to make a middle man function like below:
function customLoader(url){
showLoader();
$.mobile.changePage(url);
hideLoader();
}
Is there anyway of binding it to the change page event?
So that it shows from the second changePage is called but hides once changePage is away...
I know the above middle man method would work but would like something more tidy and nicer to implement as there's a lot of html/js files.
Something like this:
$('#index').live('pagebeforeshow',function(e,data){
$('#test-button').live('click', function(e) {
$.mobile.showPageLoadingMsg(true);
setTimeout(function () {
$.mobile.changePage('#second');
}, 1000);
});
});
$("#second").live('pageshow', function () {
$.mobile.hidePageLoadingMsg();
});
Timeout is here only so you can see it's working successfully. This is a light example so transition is fired quickly. Remove it in your real code.
And here's an example: http://jsfiddle.net/Gajotres/arrHd/
Every change page event cycle has a order of events occuring when a page A is transiting to a page B. No matter which action is used to trigger a change page you can always disable it when page B i successfully loaded. If you want to find more about page load order take a look at this link: https://stackoverflow.com/a/14010308/1848600. There you will find a lot about jQM page dynamics.
In case you want to implement this into every page transition use this:
$('[data-role="page"]').live('pageshow', function () {
$.mobile.hidePageLoadingMsg();
});
This will hide a ajax loader (if it is open) every time a different page is successfully loaded and shown.
Maybe it's too much for many, but I found a solution different than the written in the comments of this question.
I use the jquery mobile router and in the 'show' event of a page, I do $.mobile.loading("show");, so when the page appears it does with the loading spinner showing.
I use Jquery Mobile Router for a lot more, but it solved this issue.
Though to hide the spinner, I had to use $('.ui-loader').hide();, which is weird, I know...
(Maybe just listening to the proper event and triggering the spinner would also work, as this is what JQMR does...)
I'm using JQM 1.4.2...
I'll start this off with I have researched a bit, but no solution that solves what seems like it should be a simple JQM modification.
I have a wine review webapp that has the following view user flow:
http://5buckchuck.com/
Wine type > Wine list > Wine Details > Wine review (redirect via django backto ) > Wine Details updated from review
What I want to happen is when the user presses the back button it should go back to the wine list. What currently happens is the the Wine Detail view is reloaded. It takes pressing back three times to get back to the Wine List. :-(
My thoughts to solve this were two:
Splice the last 3 items from the history stack, if the last items in the history stack was Wine Review. I had a hard time trying to introspect the last history object to get the pageURL. I have a feeling that this solution is a bit too fragile though.
var last_hist = $.mobile.urlHistory.getActive();
last_hist.data.pageURL;
The second thought was to override the back button behavior so that the back button from the Wine Detail view would always go back to the Wine list view
$('div#wine_detail').live('pageshow',function(event, ui){
$("a.ui-btn-left").bind("click", function(){
location.replace("/wines/{{wine.wine_type}}/#");
});
});
There is probably a better way to do this, but I'm a bit out of ideas.
Update:
So I continue to hack on this with somewhat negligible results. On thing I have found was this is what I basically need to work: window.history.go(-3)
from the console it does exactly what I need.
So I tried binding it the the back button like such:
$('div#wine_detail').live('pageshow',function(event, ui){
var last = $.mobile.urlHistory.stack.length - 1;
var last_url = $.mobile.urlHistory.stack[last].url;
var review_url = /review/g;
if (last_url.match(review_url) )
{
$('div#wine_detail a.ui-btn-left').bind( 'click', function( ) {
console.log("click should be bound and going back in time...")
window.history.go(-2);
});
}
else
{
console.log('err nope its: ' + last_url);
}
});
No dice, something interupts the transaction...
I'd prefer not to splice/pop/push with the urlHistory. How about redirect on pagebeforechange like so:
$(document).on("pagebeforechange", function (e, data) {
var overrideToPage;
// some for-loop to go through the urlHistory TOP>DOWN
for (var i = $.mobile.urlHistory.activeIndex - 1; i >= 0; i--) {
// this checks if # = your target id. You probably need to adapt this;
if ($.mobile.urlHistory.stack[i].url = $('#yourPageId').attr('id')) {
// save and break
overrideToPage = $.mobile.urlHistory.stack[i].url;
break;
}
// set new Page
data.toPage = overrideToPage;
}
});
This captures your back button changePage call and redirects to the page you want. You could also just set data.toPage = winelist directly of course.
I'm only doing this with #internal pages, but it shoudn't be so hard to set this up with winelist.html etc.
For more info, check the event page in the JQM docs
Why not have a back button in the header section of your page? Something like this:
<div data-role="header">
<a data-direction="reverse" data-role="button" href="#winelist" data-icon="back">Back</a>
<h1>Wine Detail</h1>
</div><!-- /header -->
I wrestled with this recently as well. After thinking about it, I realized I could rewrite my JQM application to use Pop Up "windows" for those pages that I didn't want in my history. This ended up being an easier and cleaner fix than mucking around with browser history.
Now users can intuitively use the browser back button, and I don't have to code application back buttons.
The only thing you have to ensure is that the popups don't themselves make it into the browser history, so make sure to set the "history" option to false like so:
$('#some_popup').popup( { history: false } );
Okay so the solution was close to the update I posted. The issue with the previous solution was that there were to many things bind-ed to the "Back" button. While my new bind action may have been working sometimes, the other actions would take place too, I tried unbind() but still no worky.
My solution is a bit of smoke and mirrors. I check to see if the the previous page was the review page and then if so, I swap out the old back button for my new faux button with the history back step like so:
$('div#wine_detail').live('pageshow',function(event, ui){
var last = $.mobile.urlHistory.stack.length - 1;
var last_url = $.mobile.urlHistory.stack[last].url;
var review_url = /review/g;
if (last_url.match(review_url) )
{
$('a.ui-btn-left').replaceWith('<span class="ui-btn-inner ui-btn-corner-all"><span class="ui-btn-text">Back</span><span class="ui-icon ui-icon-arrow-l ui-icon-shadow"></span></span>');
$('#time_machine').bind( 'click', function( ) {
console.log("click should be bound and going back in time...")
window.history.go(-3);
});
}
else
{
console.log('err nope its: ' + last_url);
}
It looks exactly the same, and no one is the wiser. it could probably be improved by using the the jQm method pagebeforeshow so user could never see the swap. Hope this helps someone.
If you have the situation that you want the close button refer to an arbitrary (not the last) page, you could also change first to the target page and open the dialog afterwards. Therefore the close button at the dialog will open the target page.
// First: change to the target page
$.mobile.changePage('#target_page');
Afterwards open the dialog like this.
// Second: change to the dialog
window.setTimeout(
// for some reason you have to wrap it in a timeout
function(){
$.mobile.changePage('#dialog');
},
1
);
Now you can open the dialog and the close button will open #target_page.
Advantages:
solution works for single dialogs rather than removing all close buttons from all dialogs
seamless integration on a single point of code
history manipulation is not needed
I have seen similar issues before when using jquery mobile and it is addressed in the documentation. When setting up your Javascript "at the beginning of your page" use pageinit instead of ready or maybe in your case pageshow. I think this will address your issue without having to workaround the history queue.
I'm working on an ASP.NET Web Project with some AJAX magic. As my GridView's data needs up to 15 seconds to be gathered, I send the page to the client and fire an asynchronous update of an UpdatePanel via jQuery/JScript (see below).
This works well, so far. Now I'd like to skip this step when the user navigates to the next page (e.g. record detail view) and comes back via the "Back" button. Is there a way to get his, and what's the most elegant one?
This one does not work (hasDonePostBack's value isn't kept by the browser):
var hasDonePostBack = false;
function fRefreshAsyncOnce(id, param) {
$(document).ready(function() {
if (!hasDonePostBack) {
__doPostBack(id, param);
hasDonePostBack = true;
}
});
}
Any help would be great!
The reason why this is important: Regetting the data takes another 15 seconds. Moreover, the grid is working with controls and more client script (e.g. checkboxes that can be checked, CSS classes that are toggled, etc.), and all this should be the same after returning.
Cheers,
Matthias
You may want to look at the history point feature; you may be able to take advantage of that for this feature: http://msdn.microsoft.com/en-us/library/cc488548.aspx
However, that is the nature of the beast when triggering client-side operations... the other option is allowing the user to cancel the postback (or try to interpret a way to cancel it yourself) using this technique: http://msdn.microsoft.com/en-us/library/bb398789.aspx