branch, merge

This week I have had less time for SuperSLiM than I imagined, but with the time I've had, I have continued work on the public API and the internal state for the library. Much of the work has been pen and paper documentation and modelling, but much of an example of how to write a data driven app with SuperSLiM has been written as a by-product. For the public API I've settled on using a graph as a proxy to control the output of the library. In the previous post I discussed the section graph and its interaction with the traditional RecyclerView adapter. In the end I decided to go ahead with embedding the adapter into the section graph, which I believe makes working with RecyclerView and SuperSLiM quite simple. Now you simply add, remove, and update sections and items in the graph. There is no need to turn the graph structure into the sequence of views that RecyclerView requires, SuperSLiM does it all in the background. The step after working on the changes to the public API w

In the last post I discussed I was working on the public API for SuperSLiM. This work really concerns the role of RecyclerView.Adapter in the API, that is, if SuperSLiM requires you to create and maintain a section graph, then do you also need to implement an adapter? First, why is it important to explicitly create a section graph? In past versions, SuperSLiM generated a section graph from the adapter. This worked well enough at first, and it was nice that the API was basically the same as a normal layout manager. As it turned out, simply using the adapter and bundling all the side-channel data into layout parameters resulted in a lot of extra work being done to generate the section data. This was most noticeable when views that weren't even to be displayed would be bound multiple times. While caching fixed many of these problems, ultimately this played havoc with image caching and loading, and often resulted in unpredictable performance issues. To solve these problems I decid

This is my first weekly update for SuperSLiM. For the last week I have been primarily been working on the public API for SuperSLiM. I have also worked to finish the modifications of LinearSLM to support nested sections and the new internal API. As I want to ensure the public API is easy to use and understand, I have been experimenting with what it is like to use it in real applications. At the moment my biggest issue with the API is that, at the moment there are two chores to be completed when you have data changes, keeping the section graph up to date, and notifying data changes through the recycler view. I am considering ways to get this down to one task, which may require proxying the notify calls through the section graph, or making the library able to notify section graph changes, from notify calls, back to the client. I am also finding myself consistently writing helper classes to construct and manage the copy of the section graph in the adapter, I think the library could pr

It is time to talk about SuperSLiM, where is it going and how to get there. For the past few months I've been working on a new version that will fix many outstanding problems with the library. Among the changes coming is a new adapter API, a new SLM API, additional controls for headers, support for nested sections and headers, and lots of little fixes and rationalisations that will make SuperSLiM much better. I have also been working on the library to make it easy to test individual parts outside of the Android SDK, this is super important work, and much better than simply running SuperSLiM through Robolectric. Finally, there is the big problem with version 0.4, working with dynamic data is a big pain if you are using SuperSLiM, the new API is the fix for this, and it will be coming with example code and tests to demonstrate the best ways of getting your data changes into SuperSLiM. Well, that was a lot.. sounds good right? Not quite. You see, I have been working on a number of