Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android KTX: Kotlin Development for Android

android-developers.googleblog.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Android KTX: Kotlin Development for Android

#21

Post by jontro »

vesinisa wrote: post #16

> 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…

Hopefully just a couple of simple global search and replaces? Anyways I think the current support library structure is confusing and it's a good thing that they will refactor it.

Re: Android KTX: Kotlin Development for Android

#22

Post by merb »

kornish wrote: post #7
merb wrote: post #4

some examples are fine, but come on... > Uri.parse(myUriString) vs. > myUriString.toUri() I'm not sure if I would prefer the second one...

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.

Well I'm coming from a FP background. But if you're String needs to have a toUri() method, things are already wrong. Uri.parse is just fine, even in scala.

Re: Android KTX: Kotlin Development for Android

#23

Post by Groxx »

TheAceOfHearts wrote: post #9
kornish wrote: 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.

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.

Only when things become ambiguous semantically. E.g. if they had `toUri` and `asUri` and `parseUri` etc then sure.

But even then it's far more discoverable / less overwhelming than "I have a String. I want a Uri. Do I use a UriBuilder, UriParser, Uri, StringConverterFactory, etc?". Not only do you have all classes to choose from, you need to pick the one with the right methods (usually not visible when choosing the class) for the data you have.

Some IDEs can and do improve the helper-classes case a bit by letting you type e.g. `myString.uri` and showing you "uri" methods both on string and static methods anywhere which accept strings... but it's not widespread, sometimes unhelpful (there are far too many "parse" methods), and you're still missing out on the class context which sometimes has important info.

Re: Android KTX: Kotlin Development for Android

#24

Post by rubber_duck »

kornish wrote: post #7
merb wrote: post #4

some examples are fine, but come on... > Uri.parse(myUriString) vs. > myUriString.toUri() I'm not sure if I would prefer the second one...

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. Admittedly this was Visual Studio/C#, never used Kotlin for anything serious.

I see extension methods as an inferior substitute for free functions and piping/chaining operators in C#

Re: Android KTX: Kotlin Development for Android

#25

Post by georgemcbay »

rubber_duck wrote: post #24
kornish wrote: 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…

As someone who had a heavy skepticism of autocomplete from other environments (including Visual Studio, though I admittedly haven't been using that since the VS 2008 era), I have to say I find the autocomplete in Android Studio damn near magical.

It is spooky fast and Just Works, in my rather extensive experience with it. Almost all of my experience with it has been in Java, so I'm not sure the same is true in Kotlin though I would assume it would be similar.

Re: Android KTX: Kotlin Development for Android

#26

Post by izacus »

jontro wrote: post #21
vesinisa wrote: post #16

> 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…

Hopefully just a couple of simple global search and replaces? Anyways I think the current support library structure is confusing and it's a good thing that they will refactor it.

Android Studio handles that pretty well and it'll probably fix most of those in a single "Optimize imports" pass.

Re: Android KTX: Kotlin Development for Android

#27

Post by on_and_off »

jontro wrote: post #21
vesinisa wrote: post #16

> 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…

Hopefully just a couple of simple global search and replaces? Anyways I think the current support library structure is confusing and it's a good thing that they will refactor it.

Absolutely, it sounds like something that tools can handle for us or that would not take long to change even on a large codebase anyway (because you would just do a pattern replace)

Re: Android KTX: Kotlin Development for Android

#28

Post by izacus »

TheAceOfHearts wrote: post #9
kornish wrote: 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.

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 you don't have to leave the editor window and I've found it hugely useful for methods which have several overrides - instead of leaving the editor, you just choose the one you need as you type.

Re: Android KTX: Kotlin Development for Android

#29

Post by dguaraglia »

evancox100 wrote: post #6

Why is it that these large web companies can put out such sophisticated tools, and yet can't make a functional web page? Literally cannot see the content you are trying to show me. https://imgur.com/a/lXY8J And no, there's no scrolling or zooming allowed. Seriously, let's stop the focus on web framework du jour and actually make web sites that work, please.

Well, if you think about it in terms of priority, making better tools that literally millions of engineers will be using to develop apps for billions of people has a higher impact than improving a blogging platform that is used by a handful of people at Google.

That's not to excuse the shitty state of web on mobile, but let's face it: we are talking about completely different teams and priorities.

Post reply on HN