LinearLayoutManager

LinearLayoutManager(context: Context!)

Creates a vertical LinearLayoutManager

LinearLayoutManager(
    context: Context!,
    attrs: AttributeSet!,
    defStyleAttr: Int,
    defStyleRes: Int
)

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

fun assertNotInLayoutOrScroll(message: String!): Unit

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

fun collectAdjacentPrefetchPositions(
    dx: Int,
    dy: Int,
    state: RecyclerView.State!,
    layoutPrefetchRegistry: RecyclerView.LayoutManager.LayoutPrefetchRegistry!
): Unit

Gather all positions from the LayoutManager to be prefetched, given specified momentum.

If item prefetch is enabled, this method is called in between traversals to gather which positions the LayoutManager will soon need, given upcoming movement in subsequent traversals.

The LayoutManager should call addPosition for each item to be prepared, and these positions will have their ViewHolders created and bound, if there is sufficient time available, in advance of being needed by a scroll or layout.

fun collectInitialPrefetchPositions(
    adapterItemCount: Int,
    layoutPrefetchRegistry: RecyclerView.LayoutManager.LayoutPrefetchRegistry!
): Unit

Gather all positions from the LayoutManager to be prefetched in preperation for its RecyclerView to come on screen, due to the movement of another, containing RecyclerView.

This method is only called when a RecyclerView is nested in another RecyclerView.

If item prefetch is enabled for this LayoutManager, as well in another containing LayoutManager, this method is called in between draw traversals to gather which positions this LayoutManager will first need, once it appears on the screen.

For example, if this LayoutManager represents a horizontally scrolling list within a vertically scrolling LayoutManager, this method would be called when the horizontal list is about to come onscreen.

The LayoutManager should call addPosition for each item to be prepared, and these positions will have their ViewHolders created and bound, if there is sufficient time available, in advance of being needed by a scroll or layout.

fun computeHorizontalScrollExtent(state: RecyclerView.State!): Int

Override this method if you want to support scroll bars.

Read computeHorizontalScrollExtent for details.

Default implementation returns 0.

fun computeHorizontalScrollOffset(state: RecyclerView.State!): Int

Override this method if you want to support scroll bars.

Read computeHorizontalScrollOffset for details.

Default implementation returns 0.

fun computeHorizontalScrollRange(state: RecyclerView.State!): Int

Override this method if you want to support scroll bars.

Read computeHorizontalScrollRange for details.

Default implementation returns 0.

fun computeScrollVectorForPosition(targetPosition: Int): PointF!

Should calculate the vector that points to the direction where the target position can be found.

This method is used by the LinearSmoothScroller to initiate a scroll towards the target position.

The magnitude of the vector is not important. It is always normalized before being used by the LinearSmoothScroller.

LayoutManager should not check whether the position exists in the adapter or not.

fun computeVerticalScrollExtent(state: RecyclerView.State!): Int

Override this method if you want to support scroll bars.

Read computeVerticalScrollExtent for details.

Default implementation returns 0.

fun computeVerticalScrollOffset(state: RecyclerView.State!): Int

Override this method if you want to support scroll bars.

Read computeVerticalScrollOffset for details.

Default implementation returns 0.

fun computeVerticalScrollRange(state: RecyclerView.State!): Int

Override this method if you want to support scroll bars.

Read computeVerticalScrollRange for details.

Default implementation returns 0.

fun findFirstCompletelyVisibleItemPosition(): Int

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.

fun findFirstVisibleItemPosition(): Int

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). 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.

fun findLastCompletelyVisibleItemPosition(): Int

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.

fun findLastVisibleItemPosition(): Int

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). 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.

fun findViewByPosition(position: Int): View!

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.

fun generateDefaultLayoutParams(): RecyclerView.LayoutParams!

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 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).

fun getInitialPrefetchItemCount(): Int

Gets the number of items to prefetch in collectInitialPrefetchPositions, which defines how many inner items should be prefetched when this LayoutManager's RecyclerView is nested inside another RecyclerView.

fun getOrientation(): Int

Returns the current orientation of the layout.

fun getRecycleChildrenOnDetach(): Boolean

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

fun getReverseLayout(): Boolean

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

fun isAutoMeasureEnabled(): Boolean

Returns whether the measuring pass of layout should use the AutoMeasure mechanism of RecyclerView or if it should be done by the LayoutManager's implementation of onMeasure.

This method returns false by default (it actually returns the value passed to the deprecated setAutoMeasureEnabled) and should be overridden to return true if a LayoutManager wants to be auto measured by the RecyclerView.

If this method is overridden to return true, onMeasure should not be overridden.

AutoMeasure is a RecyclerView mechanism that handles the measuring pass of layout in a simple and contract satisfying way, including the wrapping of children laid out by LayoutManager. Simply put, it handles wrapping children by calling onLayoutChildren during a call to onMeasure, and then calculating desired dimensions based on children's dimensions and positions. It does this while supporting all existing animation capabilities of the RecyclerView.

More specifically:

1. When onMeasure is called, if the provided measure specs both have a mode of EXACTLY, RecyclerView will set its measured dimensions accordingly and return, allowing layout to continue as normal (Actually, RecyclerView will call onMeasure for backwards compatibility reasons but it should not be overridden if AutoMeasure is being used).
2. If one of the layout specs is not EXACT, the RecyclerView will start the layout process. It will first process all pending Adapter updates and then decide whether to run a predictive layout. If it decides to do so, it will first call onLayoutChildren with isPreLayout set to true. At this stage, getWidth and getHeight will still return the width and height of the RecyclerView as of the last layout calculation.

   After handling the predictive case, RecyclerView will call onLayoutChildren with isMeasuring set to true and isPreLayout set to false. The LayoutManager can access the measurement specs via getHeight, getHeightMode, getWidth and getWidthMode.

3. After the layout calculation, RecyclerView sets the measured width &height by calculating the bounding box for the children (+ RecyclerView's padding). The LayoutManagers can override setMeasuredDimension to choose different values. For instance, GridLayoutManager overrides this value to handle the case where if it is vertical and has 3 columns but only 2 items, it should still measure its width to fit 3 items, not 2.
4. Any following calls to onMeasure will run onLayoutChildren with isMeasuring set to true and isPreLayout set to false. RecyclerView will take care of which views are actually added / removed / moved / changed for animations so that the LayoutManager should not worry about them and handle each onLayoutChildren call as if it is the last one.
5. When measure is complete and RecyclerView's onLayout method is called, RecyclerView checks whether it already did layout calculations during the measure pass and if so, it re-uses that information. It may still decide to call onLayoutChildren if the last measure spec was different from the final dimensions or adapter contents have changed between the measure call and the layout call.
6. Finally, animations are calculated and run as usual.

fun isLayoutReversed(): Boolean

Query if the layout is in reverse order. This will affect, for example, keyboard navigation via page up/page down. The default implementation returns false.

fun isSmoothScrollbarEnabled(): Boolean

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

fun onDetachedFromWindow(view: RecyclerView!, recycler: RecyclerView.Recycler!): Unit

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

LayoutManager should clear all of its View references as another LayoutManager might be assigned to the RecyclerView.

If the RecyclerView is re-attached with the same LayoutManager and Adapter, it may not call onLayoutChildren if nothing has changed and a layout was not requested on the RecyclerView while it was detached.

If your LayoutManager has View references that it cleans in on-detach, it should also call requestLayout to ensure that it is re-laid out when RecyclerView is re-attached.

Subclass implementations should always call through to the superclass implementation.

fun onFocusSearchFailed(
    focused: View!,
    direction: Int,
    recycler: RecyclerView.Recycler!,
    state: RecyclerView.State!
): View!

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, if a focusable view in the given direction is found. Otherwise, if all the existing (or the newly populated views) are unfocusable, it returns the next unfocusable view to become visible on the screen. This unfocusable view is typically the first view that's either partially or fully out of RV's padded bounded area in the given direction. The default implementation returns null.

fun onInitializeAccessibilityNodeInfo(
    recycler: RecyclerView.Recycler,
    state: RecyclerView.State,
    info: AccessibilityNodeInfoCompat
): Unit

Called by the AccessibilityDelegate when the information about the current layout should be populated.

Default implementation adds a androidx.core.view.accessibility.AccessibilityNodeInfoCompat.CollectionInfoCompat.

You should override getRowCountForAccessibility, getColumnCountForAccessibility, isLayoutHierarchical and getSelectionModeForAccessibility for more accurate accessibility information.

fun onLayoutChildren(
    recycler: RecyclerView.Recycler!,
    state: RecyclerView.State!
): Unit

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 #getItemAnimator() 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, , 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, LayoutParams#isItemRemoved() 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.

fun onLayoutCompleted(state: RecyclerView.State!): Unit

Called after a full layout calculation is finished. The layout calculation may include multiple onLayoutChildren calls due to animations or layout measurement but it will include only one onLayoutCompleted call. This method will be called at the end of layout call.

This is a good place for the LayoutManager to do some cleanup like pending scroll position, saved state etc.

fun onRestoreInstanceState(state: Parcelable!): Unit

Called when the RecyclerView is ready to restore the state based on a previous RecyclerView. Notice that this might happen after an actual layout, based on how Adapter prefers to restore State. See getStateRestorationPolicy for more information.

fun onSaveInstanceState(): Parcelable!

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.

fun prepareForDrop(view: View, target: View, x: Int, y: Int): Unit

Called by the after a View is dropped over another View.

A LayoutManager should implement this interface to get ready for the upcoming move operation.

For example, LinearLayoutManager sets up a "scrollToPositionWithOffset" calls so that the View under drag will be used as an anchor View while calculating the next layout, making layout stay consistent.

fun scrollHorizontallyBy(
    dx: Int,
    recycler: RecyclerView.Recycler!,
    state: RecyclerView.State!
): Int

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

fun scrollToPosition(position: Int): Unit

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 or setSelectionFromTop, use scrollToPositionWithOffset.

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

fun scrollToPositionWithOffset(position: Int, offset: Int): Unit

Scroll to the specified adapter position with the given offset from resolved layout start. Resolved layout start depends on getReverseLayout, getLayoutDirection 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.

fun scrollVerticallyBy(
    dy: Int,
    recycler: RecyclerView.Recycler!,
    state: RecyclerView.State!
): Int

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

fun setInitialPrefetchItemCount(itemCount: Int): Unit

Sets the number of items to prefetch in collectInitialPrefetchPositions, which defines how many inner items should be prefetched when this LayoutManager's RecyclerView is nested inside another RecyclerView.

Set this value to the number of items this inner LayoutManager will display when it is first scrolled into the viewport. RecyclerView will attempt to prefetch that number of items so they are ready, avoiding jank as the inner RecyclerView is scrolled into the viewport.

For example, take a vertically scrolling RecyclerView with horizontally scrolling inner RecyclerViews. The rows always have 4 items visible in them (or 5 if not aligned). Passing 4 to this method for each inner RecyclerView's LinearLayoutManager will enable RecyclerView's prefetching feature to do create/bind work for 4 views within a row early, before it is scrolled on screen, instead of just the default 2.

Calling this method does nothing unless the LayoutManager is in a RecyclerView nested in another RecyclerView.

Note: Setting this value to be larger than the number of views that will be visible in this view can incur unnecessary bind work, and an increase to the number of Views created and in active use.

fun setOrientation(orientation: Int): Unit

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

fun setRecycleChildrenOnDetach(recycleChildrenOnDetach: Boolean): Unit

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 available to other RecyclerViews immediately.

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

fun setReverseLayout(reverseLayout: Boolean): Unit

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, use setStackFromEnd

fun setSmoothScrollbarEnabled(enabled: Boolean): Unit

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.

fun setStackFromEnd(stackFromEnd: Boolean): Unit

Compatibility support for setStackFromBottom

fun smoothScrollToPosition(
    recyclerView: RecyclerView!,
    state: RecyclerView.State!,
    position: Int
): Unit

Smooth scroll to the specified adapter position.

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

fun supportsPredictiveItemAnimations(): Boolean

Returns whether this LayoutManager supports "predictive item animations".

"Predictive item animations" are automatically created animations that show where items came from, and where they are going to, as items are added, removed, or moved within a layout.

A LayoutManager wishing to support predictive item animations must override this method to return true (the default implementation returns false) and must obey certain behavioral contracts outlined in onLayoutChildren.

Whether item animations actually occur in a RecyclerView is actually determined by both 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 only "simple item animations" will be enabled in the RecyclerView, in which views whose position are changing are simply faded in/out. If the RecyclerView has a non-null ItemAnimator and this method returns true, then predictive item animations will be enabled in the RecyclerView.

protected fun calculateExtraLayoutSpace(
    state: RecyclerView.State,
    extraLayoutSpace: IntArray
): Unit

Calculates the amount of extra space (in pixels) that should be laid out by LinearLayoutManager and stores the result in extraLayoutSpace. extraLayoutSpace[0] should be used for the extra space at the top/left, and extraLayoutSpace[1] should be used for the extra space at the bottom/right (depending on the orientation). Thus, the side where it is applied is unaffected by getLayoutDirection (LTR vs RTL), getStackFromEnd and getReverseLayout. Negative values are ignored.

By default, LinearLayoutManager lays out 1 extra page of items while smooth scrolling, in the direction of the scroll, and no extra space is laid out in all other situations. You can override this method to implement your own custom pre-cache logic. Use hasTargetScrollPosition to find out if a smooth scroll to a position is in progress, and getTargetScrollPosition to find out which item it is scrolling to.

Note:Laying out extra items generally comes with significant performance cost. It's typically only desirable in places like smooth scrolling to an unknown location, where 1) the extra content helps LinearLayoutManager know in advance when its target is approaching, so it can decelerate early and smoothly and 2) while motion is continuous.

Extending the extra layout space is especially expensive if done while the user may change scrolling direction. In the default implementation, changing direction will cause the extra layout space to swap to the opposite side of the viewport, incurring many rebinds/recycles, unless the cache is large enough to handle it.

protected fun getExtraLayoutSpace(state: RecyclerView.State!): Int

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.

Note:Laying out invisible elements generally comes with significant performance cost. It's typically only desirable in places like smooth scrolling to an unknown location, where 1) the extra content helps LinearLayoutManager know in advance when its target is approaching, so it can decelerate early and smoothly and 2) while motion is continuous.

Extending the extra layout space is especially expensive if done while the user may change scrolling direction. Changing direction will cause the extra layout space to swap to the opposite side of the viewport, incurring many rebinds/recycles, unless the cache is large enough to handle it.