jQuery Forum

..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.

todd@filamentgroup.com

I'll need to finish working on my splitview for a project of ours so i'll get to work on that. will keep you guys posted on the progress... the goal is for people developing on jQmobile to develop only once but get views and interactions automatically render themselves nicely according to user-agent (e.g touch, mouse, and screen-width) 

the momentum scroller you're talking about is in experiments/scrollview/. Am i right? 

bear in mind i still havent done the bindings for hashchange, form submits, resize and orientationchange, but i'll get there soon, and i'll keep you guys posted. Some of the links on the menu seems to not work, but its only coz i'm linking to the same couple of pages across all the demo site, so changePage just ignores it. A list of the coding TODOs can be found in application.js... 

a brief list of features:

1) supports transitions in both 'panel' (defined by a div with data-role="panel")

2) links determine which panel to transition pages in using the data-panel attribute

3) touch scroll when $.support.touch = true

4) in the 'menu' panel, changePage does not affect history

5) the back button now points to the previous page in the menu panel 

still needs work (as listed in application.js)

1) urls with hashed pages still don't render well

2) clicking on the back button or the browser's back button messes things up.

3) a few others as well. 

not the greatest js coding i think, but I'll get better soon. let me know what you guys think. 

right now i'm working on the hashchange event handler. this is some pretty cool stuff you guys did with this. 

the issue with the history stack on a splitview is, at almost every page transition, especially for deep-links and hashchanges, you are practically transitioning two pages. however, only the main panel should have its history tracked - it doesn't make sense for the side menu to have history tracking. this means that there are wasted stack entries. not too sure if its that big an issue, but memory management could get ugly.

will post my latest update soon. thanks for the support!  

now supports the hashchange event, you can deep-link, and you can go back and forward in history

I had to make animation tradeoffs due to isPageTransitioning and pageTransitionQueue messing up page transitions - I have to manually change pageContainer before any changePage, so when transitions are piled up and executed at setTimeout, pages on one panel get changed many times (bcoz I can't change pageContainer in between them), most often until it can't find the page it's supposed to transition to and leaves just a plain white space. there's no error message coz the page is still there, it's just in another panel, so it gets messed up. 

will post more as i go :) 

 

in mobile view, this looks seamless, but in splitview it means that all basic sidebar content and main area content needs to be loaded every time there is an entire html document refresh (a non-ajax call is made). simple enough to code, not sure how to make it easier for folks tho - but it shud be understandable - right? :) 

Asyraf Rahman,
CEO, CS8,
www.cs8.my

will do a more detailed post on what i've learnt, issues i faced and things to think about when working on this post 1.0 for your team. thanks again for the support todd! 

Todd, thanks for including us in your presentation at jsconf :)

ok, so here's what i learned building splitview, and some heads up on the issues you may face when you do:

issues:

1) changePage

changePage currently assumes there is only one pageContainer and one activePage - that's not too big an issue, except when pageTransitionQueue comes into the picture - multiple page transitions on different panels just can't happen, because changePage is not panel aware. I did  a very simple fix to this in my fork by putting in a new parameter for changePage called container, and renaming the 'to' parameter to targetPage (because changePage changes the 'to' var before unshifting it into the queue)

2) persistent footers and headers

Footers and headers - especially persistent ones, dont work with splitview because it is also not panel aware - when you click on a link that's on the menu panel, but you transition a page that's on the main panel, the footers on the menu panel get persisted on the main panel - messes things up. haven't worked on this yet, coz it was a little lower on my priority list. :) 

also, I was checking out apple's mail app on both the iphone and the ipad, and i saw that the footers and headers are pretty much interchangeable. for example, 

you can see that the shortcut buttons sit at the bottom of the page as a footer, but in the ipad:

you can see that the same footer with the same shortcuts (minus the refresh button) is now sitting up top, as a header, probably because it enhances readability, and removes clutter (not too many headers and footers). I believe we should be able to provide the same kind of flexibility for our headers and footers. what if, instead of defining data-role="headers" and "footers", we define a data-role="toolbar" and assign its position by data-position="header, footer, top, bottom" etc? just a suggestion

3) Active buttons

I still haven't quite figured this out yet, but we need to figure out how active buttons will work when dealing with two panels - example, if I put a 'next' and 'prev' button on the main panel, and use that to change pages (for example when looking thru emails) - how would the menu panel's active menu link be changed?

this is also an issue due to the inability to have persistent footers - so navbar buttons will have to be clicked twice before the button has an active class. this isn't too hard to fix tho.

4) Scrolling

I've had some users of the splitview plugin asking me about issues they've had with scrolling. when i pointed them to iScroll4, they came back telling me everything was fixed. How about integrating iScroll4 into jquerymobile? I checked the code size - when you include easing and scrollview, the size is approximately the same as iScroll4 - i could be wrong tho :P (could've forgotten to check min versions)

5) $.mobile.media

I tried to use this to test for screen width when a resize event occurs, but found that for some reason, on the iPad, it generates a lot of fakeBody elements and doesn't remove them after. it practically crashed splitview on the iPad so i went instead to just checking for $window width. 

6) history and transitions

for some reason, when going thru a bunch of pages on the main panel (generating a lot of history entries) - and then when hitting the back button a few times, you'll find that the page transitions, but sometimes in reverse, and sometimes not in reverse. i think this is a small issue, but i haven't debugged it yet. 

Things to think about (heads up)

1) context pages

some pages are just plain related to each other so much so that when you bring one up on the menu panel, the other page needs to appear on the main panel. for example, when you bring your inbox list into view on the menu panel, the first email (or first unread) needs to appear on the main panel. if the main panel doesn't transition, it just wudn't make sense (what if i was viewing a sent message previously?).

in splitview we fixed this by setting a data-context attribute either on the panel, or on the page itself. the data-context value needs to be a jQuery selector that points to an anchor tag in the particular page that's being brought up. 

2) CSS grids and font sizes

I think there are two types of grids that jquerymobile may need. one is the current grid you have - one that scales according to screen width - mainly for buttons, navbars etc. the other one is a grid that drops to one column as the the screen size shrinks - checkout cssgrid.net. this is mostly for content - you have way too many empty space in desktop/tablet view without grids. but the grids need to fallback to a single column for mobile view. the work done by Andy at cssgrid.net is a really good base to start things from. This is what I'm currently working on. 

the other thing is also font and ui element's size - when viewed in desktop, they are just way too big to be optimal for usability. also something I'm working on right now.   

3) crumbs and history tracking

currently, only main panel is tracked in history - seems to work ok for now (tracking history for both panels seemed a little clunky when you actually use it), but one issue i seem to see is context. when i move back in history, only the main panel is changed. the menu panel doesn't, and this puts context at risk. I'm currently unsure of how to do this - haven't thoroughly thought this thru yet. 

maybe in the future, each historystack entry tracks an entire queue of pageChanges? 

also, crumbs - since some pages don't need page history tracking, but you do need some form of traversal, i created the crumb button - which basically changes the back button to a button that references the previous activePage on that panel. 

that's about it from me now - I'll post some more ideas or lessons learned as i develop splitview more. 

Hope this helps. thanks!

Asyraf Abdul Rahman,
CEO, CS8,
www.cs8.my

I've been trying to get persistent headers and footers to work well in splitview - i just doesn't work - especially with context pages - this is due to setTimeout working with only one var - stickyFooter, but two pages change at one go, so setTimeout can only handle one stickyFooter, causing a null to be passed as stickyFooter the second time it gets executed. this is the code below in the pageshow event handler:

2. setTimeout(function(){
3. setTop( stickyFooter.appendTo( $this ).addClass("fade") );
4. stickyFooter = null;
5. }, 500);

Asyraf Abdul Rahman,
CEO, CS8,
www.cs8.my