SwipeView is the super simple solution to endless seamlessly loopable carousels for the mobile browser. It’s memory conservative as it uses only three elements at any given time, it’s smooth as velvet since it takes advantage of hardware acceleration, it’s bandwidth friendly with its 1.5kb minified/gzipped footprint.
Last code update: 2012.08.25 – v1.0
Device compatibility: Safari, Firefox, Opera, iPhone/Ipod touch >=4.x, iPad >=3.2, Android >=2.3
QR Code opens demo page.
If this script saved your day and you wish to support future developments you may consider sending some funds via PayPal or Flattr.
Due to memory constraints and limited resources, endless –or very long– carousels are problematic on the mobile browser. A common trick is to use only three switching master pages. Once the user swipes right the first element to the left is placed at the end of the row, the content inside the switched element is cleared and filled with new data. This way you get a virtually infinite loop. The viewport always shows the middle master page, while the pages to the left and right are used as buffer.
On desktop this page switching is so fast that you don’t need to take care of any special issues, on mobile things are a little more complicated.
First of all, any connection to the server –no matter how fast is the connection or small the data to download– interferes with hardware animations. This means that data must be fetched when no animations are executing.
Secondly, the elements repositioning needed by this technique causes little glitches to the mobile engine.
The following is my solution:
slider is the DIV which takes care of the main pan/slide effect and therefore is animated in the hardware layer. The element position is set with
transform:translate3d(x,0,0). When you swipe what is actually moving is the
As soon as the finger is released (
switching pages are rearranged to meet the new location but the new content is not loaded. Only when the slide animation ends or the user stops swiping the new content is fetched and placed inside the pages.
This technique brings 4 key benefits: 1) the animation is smooth and doesn’t lag waiting for new contents to be loaded; 2) the hasty user can swipes very quickly, if a page is not ready a “loading” indicator can be shown; 3) content is loaded only when needed, if you quickly swipe from page 1 to page 10, pages in between are ignored (namely 3-4-5-6-7-8, boundaries pages 2 and 9 are kept as buffer); 4) we don’t need to reset the viewport position at each swipe (no flickering).
You’ll notice that the slider is indefinitely slided in both directions. This leads of course to a minor drawback: there’s a limit to the amount of panning (I cannot position over 134,217,726px). It’s in the order of 420,000 swipes per side, so you can freely swipe 416 times the entire The Lord or the Rings. Please note that this NOT the maximum number of swipes you can perform, but rather the distance you can travel in one direction (eg: you can swipes 420,000 times to the right and then other 840,000 to the left).
How to use it
Please note that now SwipeView is completely general purpose (ie: not just for image galleries). I’ve set up a rudimentary e-reader to prove it.
Follow me Twitter if you wish to receive script updates (I’m often too lazy to update the blog).
More detailed documentation will follow when APIs consolidate, in the meanwhile I suggest you to have a look at the source and enjoy the show (it’s pretty straightforward I believe).
Suggestions are very much welcomed, especially in this preliminary phase. If there will be enough interest I’ll keep updating the script.
Add custom events and callbacks Make it general purpose (not just for galleries) Widen device compatibility