Anko is a library for Android development in Kotlin. The library provides helper methods that take advantage of Kotlin’s extension functions as a way to reduce the amount of boilerplate the Android SDK requires. Those extension functions make it possible to accomplish common tasks like starting an activity or displaying a toast in a very succinct way.
A big part of the library though, focuses on creating a type-safe builder for creating view hierarchies, as an alternative to the XML-inflated view approach. Some of the benefits of defining a layout with Anko are type-safety, and efficiency, since it’s not necessary to parse the XML.
I decided to take the DSL for a test drive by rewriting the “Navigation Drawer Activity” template from AndroidStudio, replacing some of the XML layouts with the Anko DSL.
We can define an AnkoComponent to create the UI:
And then, use the component to set the content view for the activity instead of using an XML layout:
In contrast with the generated version, the Anko version does require some boilerplate to set dimensions and colors from resources, but has a lot of expressiveness when it comes to bindings. Notice how it’s not necessary to create references to most of the components, since the listeners are added to each view when they are instantiated:
Compare this to the usual code, which incurs in the cost of finding the view (even if it’s a very low cost) and referencing the view id:
The Anko DSL exposes the native API of each View, so it’s only possible to do what Android components can do, with the exception of a few synthetic properties to set text or an image from a resource.
Unfortunately, that means things get pretty rough once we dive into styling and theming. The Android SDK and support libraries contain a lot of hacks that rely on the view being created by a LayoutInflater from the XML, initializing the view with a Context and an AttributeSet. There’s no first-class support for setting the style or theme programmatically, which means it’s not possible to set them when using Anko either.
Anko does provide a way to style a view, but it leaves much to be desired since it requires targeting the different view classes manually, unlike styling in XML where valid attributes are applied automatically.
When it comes to theming, Android uses ContextThemeWrapper internally to override getTheme for a view or its children. Since the current Anko version does not allow to override the context used to create a view inside the DSL, using a theme-wrapped context manually is extremely contrived.
No theming support is a serious limitation, since most components in the design library need a theme to be styled properly.
It should be possible to add support for theming in Anko, but unfortunately theming is just one of many XML-based hacks and workarounds in the SDK.
Adding views with Java code is very cumbersome, so most Java developers will stick to XML, and the SDK and support library will continue to do hacks around XML inflation.
The idea behind the Anko DSL is a very interesting one, but it seems like the Android SDK is not polished enough for Anko to reach its full potential.