All rights reserved.Menus Icon Bar Menu Icon Accordion Tabs Vertical Tabs Tab Headers Full Page Tabs Hover Tabs Top Navigation Responsive Topnav Split Navigation Navbar with Icons Search Menu Search Bar Fixed Sidebar Side Navigation Responsive Sidebar Fullscreen Navigation Off-Canvas Menu Hover Sidenav Buttons Sidebar with Icons Horizontal Scroll Menu Vertical Menu Bottom Navigation Responsive Bottom Nav Bottom Border Nav Links Right Aligned Menu Links Centered Menu Link Equal Width Menu Links Fixed Menu Slide Down Bar on Scroll Hide Navbar on Scroll Shrink Navbar on Scroll Sticky Navbar Navbar on Image Hover Dropdowns Click Dropdowns Cascading Dropdown Dropdown in Topnav Dropdown in Sidenav Resp Navbar Dropdown Subnavigation Menu Dropup Mega Menu Mobile Menu Curtain Menu Collapsed Sidebar Collapsed Sidepanel Pagination Breadcrumbs Button Group Vertical Button Group Sticky Social Bar Pill Navigation Responsive Header
The source code for this article is available here.
That concludes our dive in to the scrolling behaviour of LinearLayoutManager, but in the next short series we’ll have a look at an alternative approach in terms of UX which may eliminate the need to use smoothScrollToPosition(). Please bear in mind that all of the ideas outlined within this article are specific to the default behaviour of LinearLayoutManager and if you’re using another LayoutManager the scrolling behaviour will be different and may require a different approach. So as the scroll is in progress the Adapter is learning as it goes, and can provide an increasingly more accurate average size as the scroll progresses. When a smoothScrollToPosition() is invoked, the Adapter calculates an average item size based upon the items it has bound (an therefore knows the size of).
As each list item is bound its size is added to the sparse array. In this case you may experience slight variations in the total scroll duration, but overall you should still be able to ensure that a scroll over a long distance does not keep the user waiting for too long.įor really complex lists one approach may be to hold a sparse array full of sizes for each list item within the Adapter. If all of the header items are of a fixed size, and the contact items are also of fixed but different size to the header items then given a start and end position the Adapter should be able to calculate to total scroll distance in pixels.įor non-uniform list item sizes it should be possible to give an approximate average value (which you should be able to make a guess at by understanding how your layouts will work).
The Adapter contains two distinct View types: The first for individual contacts within the list, and the second for header lines which appear at points where the initial letter changed.
This is all well and good if we know that our list items are a fixed height, but what about if we have multiple different view types within the Adapter, or we know that our View sizes will vary? The key to how to solve this becomes a matter of understanding how your views will work, and perhaps putting some of the logic determining relative pixel distances between two list items in to the Adapter itself.įor example, consider a contacts list with header items marking each different letter.