> 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 to be a blast refactoring all my existing code and custom tools to reference this new package.

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.

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)

It's worth noting that one of the great features of Kotlin is how it simplifies deprecating code and writing quick fixes. This is why Google scrapped Java for writing Lint rules entirely. I expect a simple Option-Enter may resolve these kinds of issues across an app.

https://www.youtube.com/watch?v=p8yX5-lPS6o&list=PLQ176FUIyI...

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.

If it's made by Google, shouldn't we avoid it as it's likely to be discontinued in a few months?

About half of all tech on the internet today originated by google open sourcing it. Your and other google hate does not take into account the fact that many things that exist on the internet and tech is because of google I cant believe you guys are still crying about reader. Personally I think it was bad move on their part but I really don't get all the crying you guys do for something that shutdown 5 year ago.

Flutter will be official development platform for Google Fuchsia, their next big OS*. Google is supporting Android and iOS with flutter So that they can have plenty of apps available already when Fuchsia is launched.

With the big investment they are doing in Fuchsia it seem unlikely they will abandon it soon.

Big investment? Their next big os?

Please give us some sources, as to me it's just a project a team there is developing, and so far it can just as well be an experiment with no future.

Flutter's dev tools are built on intelliJ.

Except Dart is a worse language than Kotlin.

I am just asking here and not contradicting, but then isn't React Native too an alternative to learning Kotlin?

Can you point to any apps in the App Store using flutter ? Would be nice to see some real work examples in action.

Flutter is definitely on my watchlist but i’m still waiting for them to solve the map and videoplayer issues to bet my future on it.

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.

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.

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

Still working in Java on Android. Have a feeling that I will be left behind soon.

Same here. On my my most recent project the client requested we use Java, since after they take over they can use devs with Java knowledge.

It will take a week or two to convert experienced Java devs to Kotlin.

Yea I agree. I like Kotlin a lot and found the transfer from Java to Kotlin fairly straightforward.

Just not all clients are open to one more thing for their devs to do/learn. In the specific case for us, the devs were new to Android so they wanted to use a language they were comfortable in.

If they are new to Android how are they comfortable in Androids' take on Java? Trying to use paradigms from enterprise/server side Java in Android is going to backfire hard on all but the most trivial projects.

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.

I’ve used Kotlin enough to be comfortable but Java is still my go to for personal projects.

Java + StreamSupport + RxJava (and formerly + Retrolambda) is a very modern feeling language.

Heavy use of Optional makes the null safety issues a little less worrying and all my apps are built around AutoValue objects which are a bit like Kotlin data classes.

And apparently Java 10 has ,`var` keyword. It won't be long before Java has all the goodness.

Curious, is anyone inside of Google using Kotlin for their Android apps, or is this all for third party developers?

I heard the Android data binding compiler was written in Kotlin. At KotlinConf, they announced that Google had dropped Java altogether for writing Lint rules because of Kotlin's much greater capabilities for handling deprecated code and IDE quick fixes.

Wasn't the linter thing just about moving the lint rules (for checking proper Android API usage) to a language-independent format so that they could be shared by Java and Kotlin? Previously they only worked for Java code.

You can watch the KotlinConf session video by Tor Norbye. It was what you said and more. To clarify, I meant they dropped Java internally for their own lint rules, not that they dropped support.

https://www.youtube.com/watch?v=p8yX5-lPS6o&list=PLQ176FUIyI...

I know of one app for sure, but I don't know if I can tell :)

Director of project management, Android, said of Kotlin last July: "we're already using it ourselves to write code in Android Studio which gives us more ideas for making our support even better." https://adtmag.com/articles/2017/07/20/android-ama.aspx

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#

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.

That's the IntelliJ's magic (android studio is based on it), and that's also why Kotlin is feeling so great compared to other similar language that try to do the same(at least to me); being a jetbrain's made language it has perfect support by their tooling.

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.

Not true, it's very misleading - makes you believe the method is defined inside class body.

Also with functions you know they can't access private members, with extension methods you confuse them with real methods and have to think they can.

It's only the same thing if you know about it and without a tool you can't know, even with tool it takes some inspection.

Extension functions are syntax sugar for static methods that receive the class instance as this. They do not access private members.

Also, you need to specifically import the namespace of the extension function in order to use it, making it very clear to the reader of what is going on. It is not some hidden IDE magic, it's built into the core language.

I never said otherwise.

I said it was misleading syntax sugar because it implies that static functions defined in any namespace (extension methods) are the same as methods - which have access to internal members and are defined within class hierarchy.

If you know something is an extension method then you know it's just syntax sugar, but you can't determine that just by looking at the code.

I suspect the design of a class, if I have to worry about whether a method I'm calling is able to access private members or not.

Sure, but I've been stuck maintaining a codebase a couple of years back written by someone on fluent API hype train - exploring that codebase was a major PITA thanks to VS bugs and extension methods.

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.

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.

With autocomplete open in IntelliJ, you can press F1 to view the docs for that currently highlighted autocomplete method inline. Works really well.

Typing a couple characters is generally enough to cut out most of the noise, so long as you know vaguely what you're looking for and the methods are sensibly named.

I don't think it's the built-in constructs which are hard to find. In JVM-land, it's sifting through often verbose library interfaces that makes discoverability a huge win. Looking in Javadoc for that single function to convert from Type A to Type B properly can be a real pain.

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.

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.

I was about to post the same thing. The first one makes way more sense to me.

It’s weird watching old things become new again.

I know C# didn’t do it first, but I’m only old enough to remember C# doing it... and watching people learn the hard way that extension methods pollute the global namespace very easily.

This would be a textbook example of what not to use extension methods for, adding a very specialized extension to a basic type where a simple static utility method would suffice.

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

Can you elaborate on what we have seen? Modernization in quotes suggests that Apple wasn’t successful.

I put modernization in quotes because in most cases it was really a shim placed ontop of the existing Objective-C API that changed some names or parameter types; so, in this case it wasn't quite as extensive as a Java->Kotlin transition would be since Objective-C already supports many "modern" features such as closures.

What does "already seeing this" have to do with any meaningful input on the subject?

I was providing a parallel from my experience, which I thought might foster discussion on how such an API improvement might proceed based on historical anecdotes. Was this not a welcome addition?

i think people are interested in the lessons learned in the past. are you sceptical or hopeful? how did apple's stab at this work out in the past? is it fundamentally flawed or deeply overdue.

I think Apple did a pretty good job in most cases when getting their code to work well in Swift. I'm hopeful that this will also be the case with Android, but the hitch is that a lot will have to change. Swift's closures, extensions, etc. already had Objective-C counterparts which were not difficult to translate; but Java, on the other hand, doesn't provide many of the features that Kotlin does (hence the drastic reduction of boilerplate we can see in the blog post).

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.

Laughed when I saw this Apache Groovy code slinking away at the bottom of the article:

> To start using Android KTX in your Android Kotlin projects, add the following to your app module's build.gradle file:

  repositories {
    google()
  }

  dependencies {
    // Android KTX for framework API
    implementation 'androidx.core:core-ktx:0.1'
    ...
  }

Yes - that's Gradle's language de jour right now, though there is a ton of effort being put into supporting Kotlin as an alternative scripting language for it. I think you could use it right now actually.

Florina killed it again! go go girl (She's a genius)

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.

There's more chance for human error at a large company.

Looks like it could be fixed by adding a CSS "white-space: pre-wrap" to the <pre> elements they're using to display this code.