

Anko – Pleasant Android development in Kotlin - ericweyant
https://github.com/JetBrains/anko

======
jarofgreen
> XML is parsed on the device wasting CPU time and battery

It was my understanding the XML was compiled into a binary format for faster
parsing on device, am I wrong on that?

EDIT:
[http://en.wikipedia.org/wiki/Android_application_package](http://en.wikipedia.org/wiki/Android_application_package)
"resources.arsc: a file containing precompiled resources, such as binary XML
for example." Ah yes, I think it does.

> Most of all, it allows no code reuse.

If we are talking code reuse in terms of having one common bit of layout that
is used across several different layouts, actually you can:
[http://developer.android.com/training/improving-
layouts/reus...](http://developer.android.com/training/improving-
layouts/reusing-layouts.html)

Also, the Android view system as it stands is incredible flexible.

You can provide different layouts and style rules for different screensizes
and device configs - an kinda equivalent to the webs responsive design using
CSS media queries.

Also, every view component is just a Java class. As well as allowing you to
create your own class from scratch that you can just use as part of a view,
you can also extend an existing view class and just change one bit of it's
behaviour.

I don't especially mean to have a go at Anko - sorry. It's just that I think
the Android views are actually pretty good, and certainly when I'm working on
Android apps this isn't one of the major problems I have!

~~~
EddieRingle
> It was my understanding the XML was compiled into a binary format for faster
> parsing on device, am I wrong on that?

That's correct, but it still requires the additional overhead of parsing the
compiled resources and using reflection to instantiate Views. Anko
instantiates Views directly.

~~~
jarofgreen
So, Anko builds views up dynamically in Java only? Interesting - is there any
stats on how much faster this actually is?

------
m_fayer
After a quick skim this seems great, but just one piece of a much bigger
puzzle. Android activities, regardless of whether the view is constructed
declaratively or in code, seem to always become an untestable mess that does
way too much. At least, that's what happens if activities are used as
intended. IMO, the bare minimum necessary to fix this is some more elegant
alternative to AXML that, crucially, has some kind of declarative databinding
support. Roll that into Anko and we're on our way to taming the activity.

~~~
zserge
You might like Anvil: it's a declarative react-like UI library for Android. I
personally use it a lot, and I normally write single-activity applications
(e.g. I have my own backstack of views inside a single activity):

[https://github.com/zserge/anvil](https://github.com/zserge/anvil)

[http://zserge.com/blog/anvil-2.html](http://zserge.com/blog/anvil-2.html)

Kotlin is supported as well ([http://zserge.com/blog/anvil-
kotlin.html](http://zserge.com/blog/anvil-kotlin.html))

~~~
m_fayer
Looks really promising, thanks for the hint. It's on my to-evaluate list along
with:
[http://robobinding.github.io/RoboBinding/](http://robobinding.github.io/RoboBinding/)

Also, if you're open to Xamarin, there's a great library there called
MvvmCross that gives you in-AXML databinding and a general feel similar to
Angular.

~~~
zserge
Thanks!

Unfortunately neither of the data binding libraries for Android worked for me,
because they are either too hard to extend or too big/complex.

RoboBinding's idea is nice, but to me it's too implicit. It's really hard to
tell what's happening behind the scenes.

As for the Xaramin - I would like to try it, but I run linux on my development
machine, and it didn't start with Wine.

~~~
m_fayer
The "magic" nature of databinding seems unavoidable. Either it's driven by
reflection and then it's more or less understandable but the performance
suffers. Or, the bindings can be generated through some kind of bytecode
weaving or code generation, which are both opaque to some degree. Either way
it's hard to debug and possible to screw up performance, and I've yet to see
an implementation without such tradeoffs. But in the end I think it's worth it
for the architectural wins.

------
burntcookie90
I have a relatively medium implementation of a layout in anko here:
[https://github.com/burntcookie90/KotMeh/blob/master/app/src/...](https://github.com/burntcookie90/KotMeh/blob/master/app/src/main/kotlin/io/dwak/meh/view/MainActivity.kt)

I'm not sold on using it as a layout DSL, it's just not as easy to format as
XML, and I don't think it looks syntactically _that_ much better. However, I
am sold on using anko as replacement for setters and getters (ie.
`setText("test")` is just `.text = "test"`). Additionally, it's incredibly
easy to add more extensions for other view types, like `RecyclerView` and
custom layouts.

------
spbaar
What does it even mean for an XML layout to be type and null safe? This reads
like a parody. XML resources give you orientation/screen size resolution and
component re use. I haven't drunk the MVP kool aid that's the new hotness, but
this is far too much in the other direction. If you're setting margins in code
you're probably doing something wrong.

~~~
zserge
Let me try to answer it. I'm sure that I won't change your mind, but when I
published Anvil (a similar library for Java) - I got lots of questions like
yours.

\- XMLs are not type safe, I can type any tag name in there, and I can set
almost any value to my attributes - AAPT won't even notice (yes, Android
Studio is much smarter these days, it may give a warning, but it won't be a
compiler warning, so it won't be in your automated build logs. You will also
miss it when using other text editor or IDE). I can put a view inside another
view (not a viewgroup) - and it will pass as well. Since we waste CPU time on
XMLs preprocessing - it would be nice if they also warned us about our errors
at this stage, not crashes in runtime.

\- The file hierarchy is terrible. All XMLs must be in the same folder, no
nested folders. Having a large project makes you have dozens of XMLs on the
same layer of hierarchy. Since we have OS with directories - it would be nice
to use that feature like we use it for java packages.

\- There are some styles, but they are too limited comparing to, say, CSS. If
one ever tried LESS or SASS - he will love the mixing, variables, calculated
expressions etc. It's fast to write, it's easy to read, it's reusable. You
don't have to jump around multiple closely related files to tie it all
together in your head. You have them in one place. Since XMLs are processed -
it would be nice if I could write something like
"android:background=darken(@color/mycolor, 30%)"

\- There is some responsiveness, but it's too limited. If you have 3 nested
views, and the topmost has margin in landscape and no margin in portrait - you
have to have two (almost identical) files. Or three, if you want to use
merge/include. In fact now they are all in different folders, despite they are
very closely related!

\- There is no way to merge with unique ids (child layout will have the
duplicated ids when included twice).

\- There is no mixins or macros. If I have layout with textview+button pairs -
I will end up copying those two tags everywhere. If I have macros - I would
write it once, and then would only type `<TextViewWithButton text="foo"
buttonText="bar">` - that is supposed to be expaded into <TextView
.../><Button ..../> with some texview and button attributes substituded to the
given actual values.

\- There is no data binding.

~~~
spbaar
Thanks for the explanation. I don't really buy the wasted CPU cycles argument
since any dynamic jank after lollipop is caused by inflating views at the
wrong time, not really how they're inflated. The other stuff sound nice but
being able to do simple arithmetic and operations in XML sounds like the major
win

------
EddieRingle
I've been using this since it was still a side project by yanex under the name
of Koan. I'll never go back to writing XML layouts.

~~~
zserge
Oh, so Anko and Koan is the same project? Stupid me, I wondered what happened
to Koan when I saw Anko first (and I didn't think of an anagram).

------
stevebot
This is great, and looks so much easier (as does Scaloid), but I have never
found a commercial project that I can use it on. #1 by choosing Anko or
Scaloid you are isolating future developers to only those familiar to Anko or
Scaloid OR those willing to learn (as well as the fact that Scaloid doesn't
sell very well on resumes IMO; my guess is the same for Anko).

It's a dilemma, as Java+XML is very verbose. still, with the amount of work
Android Studio does, I'm not sure its a big problem for most of us Android
Developers.

~~~
vidarh
It may not be a big problem for most of you Android developers, but for me at
least what makes me not do Android development is how incredibly cumbersome it
feels. I'd like to, but I just can't make myself suffer through it.

I think the kind of developer who dislikes the current Android dev
alternatives enough to avoid it as much as possible is more likely to be the
target audience for most of these alternative tools than you are.

------
da4c30ff
What about layout versions for different screen-sizes, orientations, etc.?

~~~
yanex
You can check it manually or use the provided configuration() function.

------
nbrempel
I've had my eye on Kotlin for a while. I'm looking forward to seeing where
this goes!

~~~
ternaryoperator
Same here. I'd love to start seeing it appear in various projects on HN, so we
can have the discussion of pros and cons as we have had for the last 18 months
on Rust and Go.

The Rust developers have done a fabulous job of posting here and answering
questions in detail, and I hope the Kotlin guys at JetBrains will eventually
start doing the same thing.

------
frik
Kotlin:
[http://en.wikipedia.org/wiki/Kotlin_(programming_language)](http://en.wikipedia.org/wiki/Kotlin_\(programming_language\))

------
harunurhan
I think a detailed performance comparison should be provided to be more
transparent and to make developers start using Anko. I mean I want to see how
it differs in terms of app opening time, apk size, loading another view in app
time etc.

------
karmakaze
Nice job. With the advent of Swift, mobile developers may benefit from
something in a sweet spot between Java and Scala. Looking forward to testing
this out and further developments.

------
ekianjo
Using Japanese common words for projects is becoming almost cliche these days
among software developers. What's next, Kuruma ? Madoguchi ? Unko ?

~~~
yanex
There's actually some sense under the chosen name.

First of all, it is a platform name (Android) and a language name (Kotlin),
joined together and abbreviated. The word "anko" is short and there's no other
library with the same name (at least, I didn't heard of one).

Also, it was created to make Android development sweeter with some synthetic
sugar^Wanko.

Finally, I just love daifuku.

~~~
ekianjo
> First of all, it is a platform name (Android) and a language name (Kotlin),

Alright. I guess it makes sense here.

