branch, merge

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 stor

Before reading on, it is important to note that Android lint checks do not run on Kotlin code. However, it is possible to annotate Kotlin code such that lint can correctly check Java code against the annotated interfaces. There is an issue tracking lint support for Kotlin here . Typedef (Enumerated Annotations) Previously , I wrote about how to get a library written in Kotlin to interoperate with IntDef and StringDef. The method I outlined got the lint check working in a partial state. However, here is what you have to do to get the annotation to work properly. In Kotlin, declare the constants that are the values in the typedef. DatePicker.kt package com.example.datepicker class MyKotlinClass { companion object { const val YEAR = 1L const val MONTH = 2L const val WEEK = 3L const val DAY = 4L } } The actual typedef is must be declared in Java. DatePickedKind.java package com.example.datepicker import android.support.annot

Anko is a library for Kotlin that implements a bunch of DSLs that significantly simplifies and cleans up your Android code. One of the small pieces it offers are some extension functions to selectively execute code based on the current configuration. It looks like this: configuration(screenSize = ScreenSize.LARGE, orientation = Orientation.LANDSCAPE) { // This code will be only executed // if the screen is large and its orientation is landscape } Since it was available I thought it’d be nice to use it to tidy up my code that targets different versions of the Android SDK. configuration(fromSdk = Build.VERSION_CODES.M) { // This code will be only executed // on sdk versions 23 and later } However, this has a problem because I want to target multiple version ranges of the SDK. Fortunately, it turns out the function returns null if the configuration check fails. With the power of Elvis ( ?: ) the null return can distinguish when the closure hasn’t been executed and

Lately I’ve been investing time into Kotlin. Tonight, I was particularly interested in its utility for Android libraries. IntDef Update : Actually, lint doesn’t quite interoperate properly with Kotlin. So, while the following gets IntDefs and the related support annotations working 90%, you have to do things a little different, which I’ve outlined here . First up is how to use the support library’s IntDef annotation in Kotlin. This is especially important for library development since it is considered best practice to avoid enum usage for Android development. I don’t really want to go into the arguments about this practice, this is just how to use it. As it turns out, this is pretty easy. In Kotlin, using IntDef looks like this; companion object { const val YEAR = 1L const val MONTH = 2L const val WEEK = 3L const val DAY = 4L } @IntDef(YEAR, MONTH, WEEK, DAY) annotation class TimePeriod and the same code in Java looks like this: public static final lon

In the past few weeks I should have written a couple of regular weekly updates, but I didn't, and I feel bad about that. Anyway, on to the good things. SuperSLiM has been making good progress with a complete adapter interface, a near complete database backed example app, and a working but not fully tested linear layout. SectionGraphAdapter In testing the new section graph adapter functions well with the stock recycler view layouts and is working with the SuperSLiM LinearSLM. This will resolve version 0.4 issues with dynamic data. At the moment the section graph has to maintain quite a bit of metadata to map items into the flat structure the recycler view expects. This means performing changes to the section graph can perform quite a bit of work at times. For some cases it may be worth using a slightly different implementation which sacrifices access performance from the recycler view side for increased performance when making changes to the graph. Also, I found it trivial to

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