What's up with Anko?

Android
6

And what is the long-term vision for Anko? Are you at JetBrains convinced this is a good way to do Android development?

I’m asking because I gave it a try on a small UI and saw a number of problems. I generated a new project in IntelliJ based on a tabbed activity template and then did my best to convert it into Anko.

  1. The conversion turned out to be much more difficult than converting every XML tag into a matching function call. There are missing tags and attributes. For example, tabItem function does not accept “text” attribute, and I found no easy way to assign it other than implementing my own tab builder function that does not use tabItem at all. Another example is there are some missing “fooResource” properties to match “foo”, e.g. “Tab.textResource” is missing. Yet another example is the complete lack of support for writing menus in Anko. Finally, I found that Anko doesn’t support the ConstraintLayout.
  2. There is some mess with naming. Anko adds View.topPadding (presumably because Android’s paddingTop is in the same namespace, and it’s a read-only property), but does not add endPadding or startPadding.
  3. There are missing bits of functionality, e.g. support for an equivalent of the “?attr” syntax. I was lucky to find this bit of code to fill that gap: AnkoMaterialSamples/AnkoExtensions.kt at master · fboldog/AnkoMaterialSamples · GitHub
  4. The worst part for me were the side effects of Anko being a DSL on top of Kotlin. Specifically, when you build the GUI by using nested functions, every subsequent nested scope can access higher scopes’ properties. So sometimes you want to set a property of the current scope, and that property isn’t there, but there is a property with the same name higher up in the hierarchy, and you end up setting that one instead! Note that this problem does not exist with Android’s XML layouts, because scoping works differently. Even looking at the declaration of the property often does nothing to tell you it’s in the wrong scope, because it’s all built on extension function magic and difficult to follow. I fell into this trap several times and ended up adding “this.” to every attribute assignment and member function call to make sure I operate in the correct scope.
  5. There is no equivalent of “@+id/foo” syntax. This is compounded by the fact there is no support for ids declared in ids.xml in the DSL.
  6. There are cases of incorrect default behavior. I found experimentally that I had to set “scrollFlags = 0” in tabLayout’s lparams to have it behave the same way as the corresponding XML tag.
  7. Fragment API is still quite cumbersome (of course, it’s extremely cumbersome in Java to begin with).

Note that I ran into all the above problems just trying to convert a stock project generated from template into Anko. But even at this point, I have to say that it crossed my mind that it might be better to use a special DSL not based on a general-purpose programming language to avoid semantics-related problems above (name collision and scoping rules). Furthermore, I believe that in order to support “+@id” attributes and other kinds of metadata processing, as well as allow building of reliable tools (e.g. visual editor), the DSL should be “declarative with optional scripting”, as opposed to “declaratively-looking, but procedural under the hood”. Thoughts?