Anko – Pleasant Android development in Kotlin(github.com)
github.com
Anko – Pleasant Android development in Kotlin
https://github.com/JetBrains/anko
37 comments
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.
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.
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
http://zserge.com/blog/anvil-2.html
Kotlin is supported as well (http://zserge.com/blog/anvil-kotlin.html)
https://github.com/zserge/anvil
http://zserge.com/blog/anvil-2.html
Kotlin is supported as well (http://zserge.com/blog/anvil-kotlin.html)
Apps like that are a pain. No matter how you reach it you end up on a infinite stream of things you don't care anymore and have to keep pressing back.
I think yelp is written as that. And to add insult when they moved to the material hype the home button on top left became yet another back button... they did add shortcuts on the left now. But it's all breaking stuff and adding bandaids on top of bandaids
I think yelp is written as that. And to add insult when they moved to the material hype the home button on top left became yet another back button... they did add shortcuts on the left now. But it's all breaking stuff and adding bandaids on top of bandaids
Looks really promising, thanks for the hint. It's on my to-evaluate list along with:
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.
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.
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.
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.
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.
Anvil looks really promising. I wonder why doesn't it use "linearLayout {}" instead "v<LinearLayout> {}" syntax?
I'd guess because Anvil began as a Java project, and Kotlin is what provides the sugar that allows Anko to provide a nice DSL.
Almost correct. I never thought of this kind of syntax sugar initially. But technically (and people posted an issue about it) it's possible to generate functions like linearLayout() etc from android.jar for Anvil/Java. This will work with Anvil/Kotlin as well.
I plan to keep v<Class> anyway because it works nice with custom views when there is no generated syntax sugar.
I plan to keep v<Class> anyway because it works nice with custom views when there is no generated syntax sugar.
>At least, that's what happens if activities are used as intended.
Activities are indeed the piece of the framework I would be most eager to see removed/revamped. I have seen many devs (even supposedly experienced ones) use/encourage to use patterns that lead to leaking the Activity context (like retaining everything, especially the UI). There will always be people writing awful code, but Activities may too hard to grok for many devs (and that's not their only issue by far).
Activities are indeed the piece of the framework I would be most eager to see removed/revamped. I have seen many devs (even supposedly experienced ones) use/encourage to use patterns that lead to leaking the Activity context (like retaining everything, especially the UI). There will always be people writing awful code, but Activities may too hard to grok for many devs (and that's not their only issue by far).
My first candidate for removal would be fragments. They don't help to componentize apps at all (at least not better than plain old viewgroups), but they can make life much harder with weird hidden bugs.
There is brilliant article from Squareup about that - https://corner.squareup.com/2014/10/advocating-against-andro...
In Anvil I try to follow Square's approach, e.g. keep components as viewgroups and use a custom backstack to manage them as needed (e.g. back/home navigation, multi-pane layouts etc). Then you get just one activity per application and it's a big relief.
There is brilliant article from Squareup about that - https://corner.squareup.com/2014/10/advocating-against-andro...
In Anvil I try to follow Square's approach, e.g. keep components as viewgroups and use a custom backstack to manage them as needed (e.g. back/home navigation, multi-pane layouts etc). Then you get just one activity per application and it's a big relief.
I am not really convinced. Fragments are not very helpful indeed but all the Android engineers I work with know their lifecycle pretty well and I don't even remember the last time I have seen a prod bug coming from them.
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.
> 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 "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...
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!
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 "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...
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!
Actually resources.arsc only contains the resource table (think stuff in values/ folders, like strings.xml). The layouts still have their own xml files in res/layout. It is in Android's XML chunk format though, not plain-text xml.
Interesting point - the resource table still has references to the XML files for configuration-resolving purposes, but they are only strings. E.g. getString(R.layout.main) will actually work and return "res/layout/main.xml" or "res/layout-land/main.xml" depending on the device configuration (and assuming one has the layout-land version). Vice-versa, if you have a string resource with the value "res/layout/main.xml" and say, name foo, then calling setContentView(R.string.foo) actually works.
Interesting point - the resource table still has references to the XML files for configuration-resolving purposes, but they are only strings. E.g. getString(R.layout.main) will actually work and return "res/layout/main.xml" or "res/layout-land/main.xml" depending on the device configuration (and assuming one has the layout-land version). Vice-versa, if you have a string resource with the value "res/layout/main.xml" and say, name foo, then calling setContentView(R.string.foo) actually works.
> 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.
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.
So, Anko builds views up dynamically in Java only? Interesting - is there any stats on how much faster this actually is?
> resources.arsc: a file containing precompiled resources, such as binary XML for example
yes, SO answer: http://stackoverflow.com/a/6646113
yes, SO answer: http://stackoverflow.com/a/6646113
[deleted]
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.
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.
- 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.
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
It looks good unless you actually use layout qualifiers frequently. Then it becomes a pain, because you now have to keep consistency among all your layout variations and with Java code. Moreover, there's no tool in Android SDK nor in Android Studio that could help you sort it out.
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.
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).
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.
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.
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.
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.
I've had my eye on Kotlin for a while. I'm looking forward to seeing where this goes!
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.
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.
I have a relatively medium implementation of a layout in anko here: https://github.com/burntcookie90/KotMeh/blob/master/app/src/...
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.
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.
Using Japanese common words for projects is becoming almost cliche these days among software developers. What's next, Kuruma ? Madoguchi ? Unko ?
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.
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.
> First of all, it is a platform name (Android) and a language name (Kotlin),
Alright. I guess it makes sense here.
Alright. I guess it makes sense here.