I’ve reached Milestone 1 for development on the new version of SuperSLiM. This is a complete rewrite of the library to fix long outstanding problems in the original design. You can see the roadmap for version 5 up on Trello. I expect Milestone 2 to be completed within the next couple of weeks.
Milestone 1
Milestone 1 was pretty much all about getting a good foundation for the library in place. The internal graph and SLM APIs are sorted out with support for a basic layout, predictive animations, and an adapter implementation. The new design is very flexible and makes extending the library very clean and easy.
Kotlin
The library is now written in Kotlin. Kotlin is presently heading for a 1.0 release itself. When that happens, I’ll be doing a code review of the library to identify and address any unnecessary garbage collection or other performance related problems.
What is implemented
SuperSlimAdapter
There is an adapter available. It implements a graph which can store objects for view binding. Making changes to the graph notifies RecyclerView and SuperSlimLayoutManager of the changes, this kicks off the predictive animations.
There is no need to use the provided adapter, you just need to implement AdapterContract on your own adapter and keep SuperSlimLayoutManager notified of, well, a lot of things.
SuperSlimLayoutManager
The actual LayoutManager class is still pretty bare, but the internal graph is very extensive. As RecyclerView works with a single dimension of items as does not bundle additional state with the item change notifications, the logical structure of the section graph is lost. This means the SuperSLiMLayoutManager has to track changes itself by requiring the adapter to notify it directly. These events are later matched up with those reported by RecyclerView. There is some difficulty in that RecyclerView modifies, splits up, and reorders events.
SuperSLiMLayoutManager can now be declared in your XML layout like the built-in LayoutManagers.
<android.support.v7.widget.RecyclerView
android:id="@+id/recycler_view"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:clipToPadding="false"
android:paddingBottom="@dimen/activity_vertical_margin"
android:paddingTop="@dimen/activity_vertical_margin"
app:layout_behavior="@string/appbar_scrolling_view_behavior"
tools:context=".MainActivityFragment"
app:layoutManager="com.tonicartos.superslim.SuperSlimLayoutManager"
/>It also loads the common RecyclerView layout configurations declared in XML.
app:stackFromEnd="true"
app:reverseLayout="true"
android:orientation="horizontal"In the past, instantiating the layout manager was complicated by support for custom SLMs. However, in the new design SLMs are provided by a subclass of the SectionConfig class which means SuperSlimLayoutManager is now as easy to use as LinearLayoutManager.
Section Layout Managers (SLMs)
For the new SectionLayoutManager (SLM) API, I have hidden as much complexity as is possible to make writing new layouts simple.
Each SLM now works in a virtual space and talks to the layout through a helper. The helper, amongst other things, translates actions from the virtual space into real coordinates in the RecyclerView. A part of the coordinate transformation introduces effects from configuration options like stack from end and reverse layout. This allows SLMs to simply work with a logical vertical scrolling view, left-to-right, and top-to-bottom, but have the effect of rendering a RecyclerView interface that is any combination of stack from end, reverse layout, left-to-right, right-to-left, horizontal scrolling, or vertical scrolling.
As SuperSLiM implements a heterogeneous graph the layout helper also hides subsection and item differences behind the Child abstraction. This simplifies SLMs massively.
Predictive animations are also almost completely hidden by layout helper. The only complications is that a SLM must report space that was used by removed views. This is something only the SLM can know so I couldn’t hide that too. The result of this design is that disappearing views, appearing views, and the rest of that will just happen magically without the SLM having to do anything extra.
I still have work to do on scrolling the view. There will be significant changes from this, but I expect these to be mostly extensions of the existing design.
Comments
Post a Comment