LinearLayoutManager

Creates a vertical LinearLayoutManager

Constructor used when layout manager is set in XML by RecyclerView attribute "layoutManager". Defaults to vertical orientation.

Checks if RecyclerView is in the middle of a layout or scroll and throws an IllegalStateException if it is.

Query if horizontal scrolling is currently supported. The default implementation returns false.

Query if vertical scrolling is currently supported. The default implementation returns false.

Override this method if you want to support scroll bars.

Read computeHorizontalScrollExtent() for details.

Default implementation returns 0.

Override this method if you want to support scroll bars.

Read computeHorizontalScrollOffset() for details.

Default implementation returns 0.

Override this method if you want to support scroll bars.

Read computeHorizontalScrollRange() for details.

Default implementation returns 0.

Override this method if you want to support scroll bars.

Read computeVerticalScrollExtent() for details.

Default implementation returns 0.

Override this method if you want to support scroll bars.

Read computeVerticalScrollOffset() for details.

Default implementation returns 0.

Override this method if you want to support scroll bars.

Read computeVerticalScrollRange() for details.

Default implementation returns 0.

Returns the adapter position of the first fully visible view. This position does not include adapter changes that were dispatched after the last layout pass.

Note that bounds check is only performed in the current orientation. That means, if LayoutManager is horizontal, it will only check the view's left and right edges.

Returns the adapter position of the first visible view. This position does not include adapter changes that were dispatched after the last layout pass.

Note that, this value is not affected by layout orientation or item order traversal. (setReverseLayout(boolean)). Views are sorted by their positions in the adapter, not in the layout.

If RecyclerView has item decorators, they will be considered in calculations as well.

LayoutManager may pre-cache some views that are not necessarily visible. Those views are ignored in this method.

Returns the adapter position of the last fully visible view. This position does not include adapter changes that were dispatched after the last layout pass.

Note that bounds check is only performed in the current orientation. That means, if LayoutManager is horizontal, it will only check the view's left and right edges.

Returns the adapter position of the last visible view. This position does not include adapter changes that were dispatched after the last layout pass.

Note that, this value is not affected by layout orientation or item order traversal. (setReverseLayout(boolean)). Views are sorted by their positions in the adapter, not in the layout.

If RecyclerView has item decorators, they will be considered in calculations as well.

LayoutManager may pre-cache some views that are not necessarily visible. Those views are ignored in this method.

Finds the view which represents the given adapter position.

This method traverses each child since it has no information about child order. Override this method to improve performance if your LayoutManager keeps data about child views.

If a view is ignored via ignoreView(View), it is also ignored by this method.

Create a default LayoutParams object for a child of the RecyclerView.

LayoutManagers will often want to use a custom LayoutParams type to store extra information specific to the layout. Client code should subclass RecyclerView.LayoutParams for this purpose.

Important: if you use your own custom LayoutParams type you must also override checkLayoutParams(LayoutParams), generateLayoutParams(android.view.ViewGroup.LayoutParams) and generateLayoutParams(android.content.Context, android.util.AttributeSet).

Returns the current orientaion of the layout.

Returns whether LayoutManager will recycle its children when it is detached from RecyclerView.

Returns if views are laid out from the opposite direction of the layout.

Returns the current state of the smooth scrollbar feature. It is enabled by default.

Called when this LayoutManager is detached from its parent RecyclerView or when its parent RecyclerView is detached from its window.

Subclass implementations should always call through to the superclass implementation.

Called when searching for a focusable view in the given direction has failed for the current content of the RecyclerView.

This is the LayoutManager's opportunity to populate views in the given direction to fulfill the request if it can. The LayoutManager should attach and return the view to be focused. The default implementation returns null.

Lay out all relevant child views from the given adapter. The LayoutManager is in charge of the behavior of item animations. By default, RecyclerView has a non-null ItemAnimator, and simple item animations are enabled. This means that add/remove operations on the adapter will result in animations to add new or appearing items, removed or disappearing items, and moved items. If a LayoutManager returns false from supportsPredictiveItemAnimations(), which is the default, and runs a normal layout operation during onLayoutChildren(Recycler, State), the RecyclerView will have enough information to run those animations in a simple way. For example, the default ItemAnimator, DefaultItemAnimator, will simply fade views in and out, whether they are actually added/removed or whether they are moved on or off the screen due to other add/remove operations.

A LayoutManager wanting a better item animation experience, where items can be animated onto and off of the screen according to where the items exist when they are not on screen, then the LayoutManager should return true from supportsPredictiveItemAnimations() and add additional logic to onLayoutChildren(Recycler, State). Supporting predictive animations means that onLayoutChildren(Recycler, State) will be called twice; once as a "pre" layout step to determine where items would have been prior to a real layout, and again to do the "real" layout. In the pre-layout phase, items will remember their pre-layout positions to allow them to be laid out appropriately. Also, removed items will be returned from the scrap to help determine correct placement of other items. These removed items should not be added to the child list, but should be used to help calculate correct positioning of other views, including views that were not previously onscreen (referred to as APPEARING views), but whose pre-layout offscreen position can be determined given the extra information about the pre-layout removed views.

The second layout pass is the real layout in which only non-removed views will be used. The only additional requirement during this pass is, if supportsPredictiveItemAnimations() returns true, to note which views exist in the child list prior to layout and which are not there after layout (referred to as DISAPPEARING views), and to position/layout those views appropriately, without regard to the actual bounds of the RecyclerView. This allows the animation system to know the location to which to animate these disappearing views.

The default LayoutManager implementations for RecyclerView handle all of these requirements for animations already. Clients of RecyclerView can either use one of these layout managers directly or look at their implementations of onLayoutChildren() to see how they account for the APPEARING and DISAPPEARING views.

Called when the LayoutManager should save its state. This is a good time to save your scroll position, configuration and anything else that may be required to restore the same layout state if the LayoutManager is recreated.

RecyclerView does NOT verify if the LayoutManager has changed between state save and restore. This will let you share information between your LayoutManagers but it is also your responsibility to make sure they use the same parcelable class.

Scroll horizontally by dx pixels in screen coordinates and return the distance traveled. The default implementation does nothing and returns 0.

Scroll the RecyclerView to make the position visible.

RecyclerView will scroll the minimum amount that is necessary to make the target position visible. If you are looking for a similar behavior to setSelection(int) or setSelectionFromTop(int, int), use scrollToPositionWithOffset(int, int).

Note that scroll position change will not be reflected until the next layout call.

Scroll to the specified adapter position with the given offset from resolved layout start. Resolved layout start depends on getReverseLayout(), getLayoutDirection(android.view.View) and getStackFromEnd().

For example, if layout is VERTICAL and getStackFromEnd() is true, calling scrollToPositionWithOffset(10, 20) will layout such that item[10]'s bottom is 20 pixels above the RecyclerView's bottom.

Note that scroll position change will not be reflected until the next layout call.

If you are just trying to make a position visible, use scrollToPosition(int).

Scroll vertically by dy pixels in screen coordinates and return the distance traveled. The default implementation does nothing and returns 0.

Sets the orientation of the layout. LinearLayoutManager will do its best to keep scroll position.

Set whether LayoutManager will recycle its children when it is detached from RecyclerView.

If you are using a RecyclerView.RecycledViewPool, it might be a good idea to set this flag to true so that views will be avilable to other RecyclerViews immediately.

Note that, setting this flag will result in a performance drop if RecyclerView is restored.

Used to reverse item traversal and layout order. This behaves similar to the layout change for RTL views. When set to true, first item is laid out at the end of the UI, second item is laid out before it etc. For horizontal layouts, it depends on the layout direction. When set to true, If RecyclerView is LTR, than it will layout from RTL, if RecyclerView} is RTL, it will layout from LTR. If you are looking for the exact same behavior of setStackFromBottom(boolean), use setStackFromEnd(boolean)

When smooth scrollbar is enabled, the position and size of the scrollbar thumb is computed based on the number of visible pixels in the visible items. This however assumes that all list items have similar or equal widths or heights (depending on list orientation). If you use a list in which items have different dimensions, the scrollbar will change appearance as the user scrolls through the list. To avoid this issue, you need to disable this property. When smooth scrollbar is disabled, the position and size of the scrollbar thumb is based solely on the number of items in the adapter and the position of the visible items inside the adapter. This provides a stable scrollbar as the user navigates through a list of items with varying widths / heights.

Compatibility support for setStackFromBottom(boolean)

Smooth scroll to the specified adapter position.

To support smooth scrolling, override this method, create your RecyclerView.SmoothScroller instance and call startSmoothScroll(SmoothScroller).

Returns whether this LayoutManager supports automatic item animations. A LayoutManager wishing to support item animations should obey certain rules as outlined in onLayoutChildren(Recycler, State). The default return value is false, so subclasses of LayoutManager will not get predictive item animations by default.

Whether item animations are enabled in a RecyclerView is determined both by the return value from this method and the ItemAnimator set on the RecyclerView itself. If the RecyclerView has a non-null ItemAnimator but this method returns false, then simple item animations will be enabled, in which views that are moving onto or off of the screen are simply faded in/out. If the RecyclerView has a non-null ItemAnimator and this method returns true, then there will be two calls to onLayoutChildren(Recycler, State) to setup up the information needed to more intelligently predict where appearing and disappearing views should be animated from/to.

Returns the amount of extra space that should be laid out by LayoutManager. By default, LinearLayoutManager lays out 1 extra page of items while smooth scrolling and 0 otherwise. You can override this method to implement your custom layout pre-cache logic.

Laying out invisible elements will eventually come with performance cost. On the other hand, in places like smooth scrolling to an unknown location, this extra content helps LayoutManager to calculate a much smoother scrolling; which improves user experience.

You can also use this if you are trying to pre-layout your upcoming views.