Using Japanese common words for projects is becoming almost cliche these days among software developers. What's next, Kuruma ? Madoguchi ? Unko ?
Anko – Pleasant Android development in Kotlin
31–38 of 38 posts
Re: Anko – Pleasant Android development in Kotlin
#32Using 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.
Re: Anko – Pleasant Android development in Kotlin
#33Using 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),
Alright. I guess it makes sense here.
Re: Anko – Pleasant Android development in Kotlin
#34> 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 reu…
> 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.
So, Anko builds views up dynamically in Java only? Interesting - is there any stats on how much faster this actually is?
Re: Anko – Pleasant Android development in Kotlin
#35After 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…
>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).
Re: Anko – Pleasant Android development in Kotlin
#36After 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…
>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 g…
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.
Re: Anko – Pleasant Android development in Kotlin
#37Earlier quoted context omitted.
>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 g…
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 bac…
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.
Re: Anko – Pleasant Android development in Kotlin
#38I 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.