Live data from Hacker News

Android KTX: Kotlin Development for Android

android-developers.googleblog.com

41–50 of 75 posts

Re: Android KTX: Kotlin Development for Android

#41
post #7

Earlier quoted context omitted.

Discoverability via autocomplete is much higher in the second one. Extension methods probably seem really strange to anyone coming from a FP background (myself included), but in practice they've ended up being pretty useful when paired with Intellij.

I don't like this because it forces you to use the tool, and even if you do I've seen so many times when IDE breaks down and won't autocomplete, navigates to compiled binary definition on a same solution project reference, fails to find extension methods so you need to Google which namespace to bring in to get it (which isn't always as simple as class.method search, especially when reading code example snippets), etc…

It doesn't force you to use the tool; it's no worse than the alternative even if you want to write your code in notepad.exe.

Re: Android KTX: Kotlin Development for Android

#42
post #36

We've already seen something similar before: when Apple "modernized" many of the their Cocoa Touch APIs to work better with Swift.

I thought that was purely just Swift's own translation layer to make Objective C APIs more Swift-y, not an API change.

There were API changes to make the translation happy, in many cases where conventions weren't being followed strictly.

Re: Android KTX: Kotlin Development for Android

#43
post #28

Earlier quoted context omitted.

Doesn't it get a bit overwhelming to get a huge list of choices with autocomplete? I've never done any serious work with Java or Kotlin, so I'm genuinely curious. As long as you have good docs, I find discoverability is rarely an issue. One of the first things I do when picking up a language is look through its built-in constructs, to familiarize myself with the available options.

Hmm, have you used any of the Java-based autocompletion systems? - IntellJ / Android Studio autocompletion system is context aware and will only list relevant methods (which means that the list is rather short and useful for the context). Which is a stark contrast to many ctags-like autocompletion systems, which will just dump all the symbols on you and aren't very useful in my experience. Using autocompletion means…

Most of my experiences with Java were during college with Eclipse. I just remember finding it rather frustrating to have the autocomplete regularly popping up and showing me dozens of options without an easy way of learning more about em.

At some point I read through the Kotlin docs and found it interesting, but didn't have any projects in mind for it. I might try my hand again along with IntelliJ / Android Studio.

I've happily used other JetBrain products such as RubyMine and WebStorm.

Re: Android KTX: Kotlin Development for Android

#44
post #35

As an alternative to learning Kotlin on Android, you can spend the time learning flutter. Then you get concise code which works on Android and IOS now and on other platforms in the future - including desktops.

I found all the "new" calls rather clunky, does Flutter has something like hyperscript-helpers or JSX?

There's a discussion on github about jsx-alike syntax on Flutter (https://github.com/flutter/flutter/issues/11609), and "new" keyword will be optional in Dart 2.0.

Re: Android KTX: Kotlin Development for Android

#45

> You may notice that Android KTX uses package names that begin with androidx. This is a new package name prefix that we will be using in future versions of Android Support Library. We hope the division between android.* and androidx.* makes it more obvious which APIs are bundled with the platform, and which are static libraries for app developers that work across different versions of Android. Ugh, okay. It's going…

[deleted]

Re: Android KTX: Kotlin Development for Android

#46
post #35

Earlier quoted context omitted.

I found all the "new" calls rather clunky, does Flutter has something like hyperscript-helpers or JSX?

There's a discussion on github about jsx-alike syntax on Flutter ( https://github.com/flutter/flutter/issues/11609 ), and "new" keyword will be optional in Dart 2.0.

ah, the optional new should be enough I think.

Re: Android KTX: Kotlin Development for Android

#47
post #38

Earlier quoted context omitted.

you really wont be, it's like a couple of weeks and you'll be up and running in kotlin.

I don't mind Kotlin, but I don't want to get a big middle finger from Google for choosing to remain with Java for this project I already started in Java.

Kotlin & Java interop really seamlessly, that's one of kotlin's biggest features. Not interops like there's an FFI that is obviously an FFI, but interops like there's not much obvious difference between calling either way.

You won't get the kotlin syntax sugar, of course, but you're not going to be missing any features, either.

Re: Android KTX: Kotlin Development for Android

#48
post #30

Not to be confused with Kotlin Android Extensions, which although handy is really just a convenient way to reference views in XML. https://kotlinlang.org/docs/tutorials/android-plugin.html

Maybe a combo of that and Anko (https://github.com/Kotlin/anko)?

Re: Android KTX: Kotlin Development for Android

#49
post #37

As an alternative to learning Kotlin on Android, you can spend the time learning flutter. Then you get concise code which works on Android and IOS now and on other platforms in the future - including desktops.

And it's made by Google, unsurprinsingly. A big plus for Kotlin is that being a jetbrains project, it has top of the line intellij tooling support right at release date.

Flutter's dev tools are built on intelliJ.

Re: Android KTX: Kotlin Development for Android

#50
post #30

Not to be confused with Kotlin Android Extensions, which although handy is really just a convenient way to reference views in XML. https://kotlinlang.org/docs/tutorials/android-plugin.html

Kotlin Android Extensions is a tad more than that. It's also a View cache that grabs all view references in a single pass. I routinely have to explain to other senior Android developers that findViewById() traverses the entire view hierarchy until it finds that ID each time you call it. This won't be noticeable with simple views, but becomes a bigger problem as complexity increases. Which also results in more wasteful calls to findViewById().

Android Data Binding does something very similar to Kotlin Android Extensions, which is why it also perplexes me to see experienced devs bind a model to a view and then call findViewById() to alter it. I'll see calls to binding.getRoot().findViewById(), which is crazy redundant.

Post reply on HN