This wear-specific implementation of LinearLayoutManager provides basic
offsetting logic for updating child layout. For round devices it offsets the children
horizontally to make them appear to travel around a circle. For square devices it aligns them in
a straight list. This functionality is provided by the CurvingLayoutCallback which is
set when constructing the this class with its default constructor
WearableLinearLayoutManager(Context).

To be called only during onLayoutChildren(Recycler, State) to add a view
to the layout that is known to be going away, either because it has been
removed or because it is actually not in the
visible portion of the container but is being laid out in order to inform RecyclerView
in how to animate the item out of view.

To be called only during onLayoutChildren(Recycler, State) to add a view
to the layout that is known to be going away, either because it has been
removed or because it is actually not in the
visible portion of the container but is being laid out in order to inform RecyclerView
in how to animate the item out of view.

onLayoutChildren

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.

Parameters

recycler

RecyclerView.Recycler: Recycler to use for fetching potentially cached views for a
position