
Kotlin for Android Developers - ingve
http://www.javaadvent.com/2015/12/kotlin-android.html
======
zserge
Kotlin is a very nice language especially from the Android developer
perspective. It's so concise that you may not even use an IDE having only a
text editor instead.

In addition to Anko, there is also a similar (but much smaller) library that I
maintain - [https://github.com/zserge/anvil](https://github.com/zserge/anvil)

It is also a DSL for defining view layouts in code, much like Annko. The major
difference is that Anvil supports data binding and has reactive nature (think
of it as of react.js for android).

~~~
kcorbitt
Huge "+1" for Anvil (and thanks so much for developing it). I've written a
fairly large app in production using Anvil+Kotlin, and developing with it
feels more like React than the traditional Android imperative slog. At the
same, the library gives you the flexibility to easily drop down and access any
Android APIs that don't fit into its paradigm.

I've been working more with React Native recently because I'm working on a
cross-platform project, but for Android-only development the combination of
Kotlin and Anvil gives you pretty much the same level of declarativeness and
conciseness while still enforcing a decent type system and not being so far
removed from the platform.

~~~
zserge
Just made a big push to Anvil repository - it can now inflate layout from
XMLs! This means you may use your favourite IDE to design layouts, then use
Anvil to bind data and event listeners to make your UI reactive:

    
    
        public override fun view() {
          // A designer gave us an XML with some fancy layout:
          // a viewgroup with a button and a progress bar in it
          xml(R.layout.my_layout) {
            backgroudnColor(Settings.bgColor) // will modify root layout view color
            
            withId(R.id.my_button) {
              // button state may depend on some variable
              enabled(isMyButtonEnabled)
              // button click listener can be attached
              onClick { v ->
                ...
              }
            }
    
            withId(R.id.my_progress_bar) {
              visible(isMyProgressBarShown)
              progress(someProgressValue)
            }
          }
        }
    

I know many people are opposed to defining layouts in code, so this can be a
good compromise for them. Also, it's very helpful if you have a large project
made with XMLs and want to refactor it.

~~~
habosa
That's fantastic! Can you upgrade the README with a little detail on this?

~~~
zserge
Done. I will try to cover more within the next few days, hopefully I will add
an example to `anvil-examples` repository and make a blog post tell more about
recent changes in Anvil.

------
georgemcbay
Big fan of Kotlin and would love to see it used more on Android.

I'm still kind of flabbergasted that Google has no official (publicly known)
plan to start moving away from Java given the lawsuits, general disregard for
Java (keep in mind I say this as someone whose day job is Android development
in Java), warm reception of Swift, etc.

I was hoping that the Android Studio/JetBrains connection would result in some
sort of officially-blessed move towards Kotlin, but disappointed on that front
so far.

Not that you need Google's official blessing to use Kotlin -- it works great
today, but there's often political pressure not to use "fringe" languages when
working on projects at most companies which is a pain to deal with and which
is still forcing a lot of people to use shitty old Java 6.

~~~
sandGorgon
I think its gonna be Dart.The engine’s C/C++ code is compiled with Android’s
NDK, and the majority of the framework and application code is running on the
Dart VM. For Flutter - The Dart VM generates JIT-compiled optimized native
code on the device. (In other words, the Dart VM is not an interpreter.)

[https://news.ycombinator.com/item?id=10521258](https://news.ycombinator.com/item?id=10521258)
[http://flutter.io/faq/](http://flutter.io/faq/)

~~~
PeCaN
Dart always seemed like it was better suited for Android development than for
web applications. Snapshots work particularly well, since the OS could manage
persistence basically for free.

~~~
incepted
Dart's optional typing and performance makes it a non starter as a replacement
for Java.

Make no mistake: if Java is ever replaced as the main language on Android, it
will be by a language that's at least as fast (which kind of implies that
language has to be statically typed, at the very least).

~~~
PeCaN
Dart's performance is pretty good; its authors are VM geniuses.

If it doesn't already[1], it could leverage the optional typing for block
versioning on initial compilation, and assume that version is correct most of
the time (generating the most-optimized version initially because you expect
to not bail out of this block version). This way you wouldn't have to warm up
for type inference. If the program type-checks you can get almost static type
performance.

Dart also has an advantage in app startup time since you can just load your
snapshot.

\--

1: I'm not familiar with the internals of the Dart VM, but I don't believe it
leverages block versioning[2] at the moment. That seems like a low hanging
fruit when you already have type hints. Your initial baseline compile can
generate a specialized version from the get-go then lazily add other blocks if
the type hints are wrong.

2: [http://arxiv.org/abs/1411.0352](http://arxiv.org/abs/1411.0352)

~~~
incepted
The Dart authors are geniuses but even they can't violate the laws of physics.

Dart is between two and five times slower than Java, as of six months ago [1].

It's not clear whether Dart can close that gap since Java is not standing
still either, so I remain completely unconvinced that Dart will ever be the
replacement of Java on Android.

[1]
[http://benchmarksgame.alioth.debian.org/u32q/dart.php](http://benchmarksgame.alioth.debian.org/u32q/dart.php)

~~~
PeCaN
It's not in any way a physical limitation that Dart is slower than Java. It's
just somewhat harder to make fast, and even then, some of Dart's design is
motivated by being able to implement the language efficiently. [1]

Dart could even in theory have a compiler that assumes all your type
annotations are correct and simply AOT compiles your code. (So your workflow
would be: develop -> fix type errors -> run in regular VM -> loop -> AOT
compile -> deploy.) Whether that would be useful is another matter, but it
could certainly be possible (some Common Lisp implementations in fact do
exactly this [2]).

\--

1: [https://www.dartlang.org/support/faq.html#q-why-
dart](https://www.dartlang.org/support/faq.html#q-why-dart)

2: [http://www.sbcl.org/1.0/manual/Declarations-as-
Assertions.ht...](http://www.sbcl.org/1.0/manual/Declarations-as-
Assertions.html)

------
mwcampbell
Kotlin looks like a very nice language. I wonder if the Kotlin developers have
considered adding an ObjC backend, or alternatively, an LLVM-based native code
backend for Apple platforms that sits atop the ObjC runtime, uses reference
counting instead of garbage collection, where every Kotlin object is an
NSObject, etc. That would enable an app developer to target Android, the web,
and iOS with some code sharing across platforms and minimal overhead on each
platform.

------
SwellJoe
The brevity of Kotlin vs Java is astonishing (or maybe the verbosity of Java
vs Kotlin is astonishing). The worst part of Android development, so far, for
me, has been just how much code it requires to do _anything_.

Even with a relatively nice and declarative development API (which Android
provides), the amount of code to put anything on the screen, much less
accomplish any useful work, has always put me off of building anything of note
on the platform. My brain turns off when there's so much reading to be done to
derive any meaning from a function; e.g. "What does this do?"...three dense
pages of code later..."Ah, it saves the current state to storage."

In short, I'm pretty excited about Kotlin. Maybe I'll finally start working on
Android apps, beyond mere tinkering.

------
mythz
Kotlin and Java are from different era's, Java's one of the most verbose and
limited modern typed languages for functional programming whilst Kotlin's one
of the best and both have great tooling support for developing Android Apps
courtesy of JetBrain's tooling prowess, where to enable Kotlin support in
Android Studio you just need to enable the Kotlin plugin:
[https://kotlinlang.org/docs/tutorials/kotlin-
android.html](https://kotlinlang.org/docs/tutorials/kotlin-android.html)

And configure your project to support Kotlin with a find action or a `Tools >
Kotlin > Configure in Project` Menu item click. From there you can mix and
match Java and Kotlin classes in the same project with great interoperability
for calling code between each. The Kotlin plugin also has a nice feature (Ctrl
+ Alt + Shift + K) to convert a Java class into idiomatic Kotlin which is a
great way to explore Kotlin features.

Even whilst the plugin has stability issues, I don't see myself developing
another Android App with vanilla Java 7 - Kotlin's just so much a more
productive and enjoyable dev experience, that Android Studio should have the
Kotlin plugin enabled by default.

------
rtpg
Similarly for those looking for modern languages for android dev, Scaloid lets
you work with Scala and offers a similar DSL

~~~
incepted
Scala's runtime is so big that it doesn't leave much room except for toy apps
on Android.

Also, Scala will soon only support Java 8, which Android doesn't support.

Kotlin has neither of these problems.

------
hyperpallium
This should also compile on-the-device. It only needs java 1.6, there's a
command-line compiler, and its scripts just run some jars:

[https://github.com/JetBrains/kotlin/blob/build-1.0.0-beta-35...](https://github.com/JetBrains/kotlin/blob/build-1.0.0-beta-3595/compiler/cli/bin/kotlinc)

------
guelo
Why is that so many of the newer languages put the type after the name? I know
it's just something to get used to but it feels clunkier to me. At first
glance this looks like the 1 is getting assigned to Int:

    
    
        var i: Int = 1

~~~
mythz
This is the most logical way to add optional typing:

    
    
         var i = 1      //Type inference
         var i:Int = 1  //Explicit type
    

i.e allowing you to optionally enhance existing code with explicit type info
without changing the existing definition.

~~~
hyperpallium
Logical, but assuming Int is reserved, I can't see why type-first would give
the parser or developer any problems:

    
    
      var i = 1      //Type inference
      var Int i = 1  //Explicit type
    

But it seems a common convention for optional typing. Maybe it suits dynamic
developers?

~~~
PeCaN
Personally I just consider that uglier.

Also you can parse var i: Int = 1 unambiguously without backtracking, while
you have to backtrack on var Int i = 1 (unless you enforce some constraint
like type names must start with capitals, in which case you may as well just
do Int i = 1).

------
enobrev
I highly recommend this incredibly enlightening video about kotlin for android
by Jake Wharton: [https://youtu.be/A2LukgT2mKc](https://youtu.be/A2LukgT2mKc)

------
andretti1977
I'm honestly curious: i love groovy (and grails) so i would like to know why
java devs should prefer kotlin to groovy, since it seems to me that groovy has
every good feature and advantage that kotlin has.

~~~
incepted
Two main reasons for me:

\- static typing (non negotiable)

\- performance (Kotlin is on par with Java, Groovy is... still very slow,
which is especially a big deal on Android)

