Better Android Development with Kotlin & Gradle

Ty Smith

Recorded at GOTO 2016


Get notified about Ty Smith

Sign up to a email when Ty Smith publishes a new video

thanks Simon
as developers we get the best work done
when we just have the opportunity to sit
down undistracted and get into the flow
context switching greatly reduces our
efficiency and it can cause us a lot of
frustration how many of you would love
to work in a world where you get to work
in a consistent expressive concise and
fun programming language all day both
for the app development you do as well
as the tools to build it
I know I would when it comes to building
Android we may use a mix of languages in
the app source and the build tool source
everything from Java
groovy XML JavaScript if there's any web
stuff native code could be in C C++
there's a lot of stuff going on here and
it can really slow us down and inhibit
new developers to the code base I'm ty
and I'm an Android developer at uber
working on our external developer
platform today I'm going to walk you
through this fun or new language that
some of you may have heard about by now
called Kotlin and how it can help make
your life a little bit better and more
consistent throughout the entire
development stack I'll walk you through
a short overview the language and then
specific real-world examples primarily
focused on using it in the the build
tools but first remember to use the
conference app to rate and ask questions
before we begin with Kotlin why isn't
Java good enough for us
one of the major talking points lately
has been when Android will see true Java
eight support recently along with the in
release we did hear word of eight
support with the new compiler Jack
however we're kind of in a fragmented
world when it comes to the languages
that Android supports with Jack you get
the lambda support and you get the newer
API features for the brand-new release
but we all know how Android users are
slow to adopt new versions so Java 7 has
support for a larger set of devices I
believe from KitKat and up and below
that they're still stuck on Java 6
support
so with that fragmentation it's really
hard to focus on just using a newer
language
Java Android can both be quite
error-prone as well
capturing inter classes for example
leaves your apps prone to memory leaks
especially when passing those on to
asynchronous operations hopefully you
got to see the talk by py earlier he
drove a lot more into the leaks that can
be associated with that if you didn't
get a chance to see that today I'd
recommend watching that video there are
also several some tactical problems with
Java beside lambdas which is kind of the
most popular thing that people say they
want such as the collection streaming
and other systemic problems such as the
verbose Ness null ability and mutability
these syntactical problems can be
resolved with some great libraries that
help improve the app development
experience and safely backport some of
those features from Java 1/8 and 7 to
previous versions libraries like Jack
retro lambda and even rxjava but these
systemic problems caused a bit of an
issue though well Ruby is what's
primarily used in for building Gradle
and it's an expressive and useful
language however I think it also has a
few limitations then make it less than
ideal for a world where we wanted this
consistency across the first is that
it's a that the first is that it's a
dynamic language while Kotlin is
statically typed Gradle is going to
spend more time processing the language
because of the runtime checking that
needs to be done and it's been noted
that using Kotlin in your Gradle builds
will speed up the configuration step
because groovy is dynamic harder for the
IDE to be smart for you to parse to
autocomplete and therefore it's going to
be more prone to error you're going to
have to do the build before you can
often see that there's an issue and
that's going to slow down the feedback
cycle by using a statically typed
language you allow the IDE to be smarter
for you and help give you these issues
before you have to spend the time groovy
brings a number of performance and
memory concerns if it was going to be
specifically on Android as well
so that might limit this consistency
that we talked about for example the
standard runtime for groovy is quite
large the dynamic nature means that the
garbage collector and Android would be
running quite frequently which could
cause a poor user experience and cause
frames to drop wouldn't it be great to
have consistency between our build
scripts plugins and the deliverable code
well I think that we can get that by
using Collin with all type I'm sure you
a thing or two about it well if there's
been a few other talks already about
Kotlin here at the conference but for
those of you who haven't got a chance to
hear about it I'll walk through a few of
the advantages of it it's built by the
folks at jetbrains the people behind
IntelliJ in most of the Android studio
work and it's completely in it's built
completely in the open and it's designed
with mobile first in mind with Android
developers being a really large target
audience for them they reach through 100
milestone somewhat recently so we have a
stable AI and many of the top apps are
already starting to integrate or explore
integration since the first time I gave
this talk the Gradle team has also
announced official support for Kotlin
and build scripts as well while it's
still in its infancy the dedication from
the team and the official announcement
means that going forward we'll see it
treated as a first-class citizen because
it's designed to work with Android and
mobile first in mind the bytecode that's
generated by Collin is 100% compatible
with the JVM six so it covers that
fragmentation problem that I mentioned
earlier and you don't really need to
convert your entire project to Kotlin to
start using it you can use it right away
because Kotlin is fully interoperable
with Java you can intermix them in the
same project the language has its own
standard runtime and this library does
need to be bundled with your application
fortunately it's quite small coming in
at around 600 K last time I checked now
if you were to contrast this to the iOS
world which many of you may be familiar
with as well Swift has a very similar
set up you need a bundle swift with your
iOS application but it comes in at
around 10 Meg's for Android it's pretty
important especially if we're going to
consider targeting emerging markets that
we need to keep our app binaries small
and fortunately Kotlin allows us to do
that because Kotlin is statically typed
as I mentioned earlier and it keeps
memory allocation in mind we don't have
the same type of runtime overhead that
we would be that we would have by using
a dynamically typed language like Ruby
this could be a large constraint on
Android where the GC would be making
that more problematic
lastly Colin is a modern language with
many awesome features that make
development fun and you can use it on
all of your Android
vices today but more importantly Colin
helps us with many of the constraints
that Java introduced that Java and
Android both introduced by utilizing
Collins type system for null safety it
can help us reduce easy to avoid null
pointer error exceptions and make our
code much more maintainable Kotlin gives
us a great way to reduce the boilerplate
code that's so synonymous with Java and
it makes our code much more maintainable
and approachable for other developers
the Android API is rely primarily on an
architecture of inheritance and although
this works well for the teams at Google
it puts the large larger burden on the
app developer especially when many of us
seek an architecture of composition
there are also many api's that require
proper ceremony to complete you have to
call a number of methods in order just
think about the steps required for
toasting savings equal light
transactions or using the media recorder
often you have to initialize do your
work and then call a commit or save and
if you happen to miss one of those steps
you're only going to discover that at
runtime lastly while Java is too verbose
in my opinion to define a maintainable
build script I believe Kotlin is
expressive and concise enough to compete
with many aspects of groovy the
preferred build script language of of
Gradle while providing much-needed type
safety to reduce errors and expedite the
development of your tooling so we Colin
has it brings a lot of cool features to
the table we have higher-order functions
and properties and mix-ins and there's a
there's a lot of these and I'm only
supposed to be up here for about 45
minutes so I'm just going to go through
a few of these today that I think will
be really promising and help with your
tooling so one of the most common
exceptions in Java development is the
null pointer exception infamously known
as the billion dollar mistake
unfortunately Java doesn't have a
first-class representation of something
that may or may not be null and we've
seen many libraries and tooling try to
address this in the past with band-aids
on top of java by having runtime based
checks for null it makes the code much
more susceptible even when we're using
those null checks and having the
potential value of null requires
defensive programming
which leads to much less maintainable
code as well so here's our first example
to show Cotton's variable assignments
you'll notice that Kotlin uses a syntax
where it reverses the type and name
ordering for variable declaration in
this case we'll get a compile time
exception on that second line as we're
not allowed to assign null to VAR a
however in this next example you'll note
the question mark along with the
declaration this indicates to Kotlin
that the value may be null and will take
care of checking that once we try to
utilize the variable though we will see
a compilation error as we needed to
explicitly check for null before using
you may notice the two different ways of
declaring the variable here both var and
Val and to clarify Kotlin uses var to
indicate that it's immutable variable
while it uses Val to indicate indicate
that it's an immutable value in this
last example of null ability we can see
a few different formats to check for
null the first line of code you'll note
the question mark in use again well that
is declared any further method calls on
that object will return null if the
parent object is null and this removes
the need for us to do the nested if null
checks in Java in the second line of
code we follow a slightly different
format instead of utilizing null we
specify a default value using a single
expression if-else and in this last
example we take advantage of the Elvis
operator to simplify the syntax of the
previous examples let's move on to
another cool feature of collin class
properties in this example we'll define
a class called user and specify a member
variable for the name using the syntax
where we put the member in line with the
class name is one approach although we
could specify it below in the class as
well which may be more familiar some of
you although this looks like a standard
Java field this is a synthetic property
this means that the getters and setters
are automatically generated for us and
that's what's being used near the bottom
of the slide that definitely helps clean
up some of that boilerplate code we can
however override the default generated
getters and setters to specify
custom logic by declaring a get in a set
method below the property definition
you'll notice that we change the syntax
for the property declaration here as
well from the previous slide this is
just another way of handling that in
addition to using properties to clean up
boilerplate code Kotlin offers a concept
called the data class this is designed
to be a lightweight pojo and and do all
of those things then it's standard POJO
and java would normally need to take
care of by advicing by adding the data
keyword in the declaration we get this
behavior it'll automatically generate an
equals and hashcode method for us so we
no longer need to define that and it
will also create the to string method
with all of the constructor parameters
that we defined
lastly it'll generate the copy method
for us with default parameters so that
you don't have to implement builders to
copy and create immutable pojos
throughout your code base data classes
do have many limits as well for example
they cannot extend another class or be
abstract so I definitely recommend
looking up the restrictions of this in
the Kotlin documentation to decide if
it's right for you let's move on to
another example function literals or
lambdas are a great way to make code
more readable and have come to be
expected for modern languages today Java
6 doesn't have support for these but by
using a framework like retro lambda that
rewrites the bytecode from a lambda a
Java 7 or Java 8 lambda 2 a single
abstract method is a great way for us to
get that in android today lucky for us
we get it out of the box with Collin in
this example we see a few different
syntactical ways to write them they will
infer the type from the definition so we
can reference the variables directly in
the first example in a second with the O
with only a single parameter we can
refer to it as the standard it notation
similar to groovy or many other
languages and we can store the function
literal in variables such that we can
access it later when needed expanding on
the function literal concept Collin also
provides us with higher-order functions
or functions that take functions as
parameters or
to turn them this is a very powerful
technique to write clean readable code
we'll get to see some more powerful
examples of this in real-world use cases
for cleaning up Android and Gradle code
as soon as we understand the last
concept required and that last concept
that I want to talk about is extension
functions calling gives you the ability
to add methods to existing types and
this is very powerful and similar to
other languages like C sharp and it's a
great way to replace the utility hell
that Java has known to become where you
have a you told class representing
interactions with an object that's out
of your control
the syntax requires that you just define
interacts with that class as if it was
owned by that class please note that you
cannot override existing methods of a
class with a function with an extension
function another thing to note is that
Kotlin only gives you access to the
method that you defined in a class where
you've defined the function extension if
you wanted to use it in other classes
from the class where you had to find it
I mentioned earlier that function that
extension functions were a great way to
avoid that util hell in Java but I also
mentioned that Kotlin is completely
interoperable with Java so what is this
actually doing it's generating a class
with a static method that intercepts
calls to the object in Kotlin but in
Java you can that you can call that
generated static util directly Calton
will assign a default name to the file
based on the file name but you can
specify something custom by using the
annotation here file JVM name with the
string for the file if you wanted to
group multiple of these extension
functions into one util instead of
having one generated per you could use
this other annotation and declare the
name and use the JVM Multi file class
annotation to do that this can be really
powerful in Android here's the
traditional way of saving an object into
shared preferences in Java you can see
that it requires us to admit the
preference editor put the object into
the preference editor and then call
apply and this is prone for error as it
requires the ceremony to befall the
exact followed exactly and if we don't
then we don't save the value that we
expect
so how can we make this better here's
that same functionality but using the
last three concepts that we talked about
using in cotton extension functions
higher-order functions and function
literals we add a method edit to the
shared preference object that takes a
function literal that is defined as
another extension function of the editor
class and this can be confusing at first
but it's incredibly powerful and it
allows any function literal pass 10 to
behave as if it was a method on the
shared preference editor object this
allows us to use the code in a type safe
way knowing that the string is saved
without having to worry about
referencing the correct editor a caveat
to note though is that since Kotlin is
Java 6 compatible using higher-order
functions imposes certain runtime
penalties each function is an object and
it captures a closure these variables
that are accessed in the body of the
function so now we have memory
allocations both for the function
objects and for the classes and the
virtual calls the introduced runtime
overhead as well but by adding the
inline keyword in Kotlin to the function
declaration we are telling the Kotlin
compiler to compile the code inline as
if we had defined it the very first way
that I showed in Java which is while
prone to error from a maintainability
perspective much more performant for the
machine so now our bytecode between the
Kotlin version and the Java version is
identical remember when I said that
Kotlin doesn't add runtime overhead well
this is one of those features that
really allows for that these Kotlin
features give us a powerful ability to
start creating a DSL there's this cool
proof-of-concept library called Eng
co-written by the jetbrains team that
allows you to cleanly describe Android
layouts using purely Collins without
having to use eczema XML at all by
utilizing higher-order functions you can
write a clean Android layout DSL you may
also notice that the syntax is starting
to look quite similar to groovy so maybe
now I've told you on some of the
benefits of Kotlin as a language and you
can see how it could be useful for work
in your android app but introducing that
would add further fragmentation to this
to your codebase
you might have Kotlin in your app and a
mix of mix of groovy and Java and your
build tools so that's up to three
languages jvm languages just to be
thinking about and humans aren't really
that great at context switching no
matter really what you set what you
think about yourself
studies show that we're not great at it
so this overhead is going to reduce
developer productivity maybe we can use
Kotlin by bringing it to the next level
in Gradle we could use it in the build
tool as well and I'm going to walk
through some small examples of mini use
case of a use case many of us have had
how to load API key information so that
we can sign outgoing requests to a web
server and they've been a quite a few
talks and blog posts and sample projects
to teach us using Kotlin in in android
specifically so from now on I'll just be
focusing primarily on inside of Gradle
of course to use Kotlin we need to
install it it's quite simple to install
using Gradle we just add a build time
dependency and apply the plug-in and
then we include the standard library and
runtime we can intermix the Katie files
and the Java files and the groovy files
also to note be sure to install the
IntelliJ or Android studio Kotlin plugin
it'll make your life a little bit easier
can even help facilitate adding these
dependencies and it has provided Java to
Kotlin converter may not produce the
most idiomatic Colin but it's definitely
a great start this get Scotland in our
runtime code but let's take a moment to
make our build script even better using
Colin as well the Kotlin Gradle support
the Kotlin support in Gradle scripts
specifically it's still a work in
progress at the moment the Gradle team
first unveiled Kotlin support for build
scripts at Gradle some it a few months
ago with the benefits of Kotlin in the
IDE it'll now be much easier for us to
write and maintain these build scripts I
know I'm really excited for autocomplete
in Gradle at this point the integration
is somewhat limited though and it
requires some workarounds here's an
example that I created that's a subset
of the larger example in the Gradle repo
for Kotlin and I have that linked from
the slides when those get posted you'll
see that but if you look carefully at
that previous example you'll notice that
there are a couple things that were a
little bit off there's a few lines that
just
look quite right that's because to make
Kotlin work in an idiomatic way that
most of us are familiar with from groovy
and what most Android developers are
used to in general I had to add all of
these extension functions to get it to
work some things that I did here created
a block for the Android tag so that we
could use the Android DSL reference we
want to named access to the release
build since it statically typed in
groovy when you type your build type
release brackets that's actually
internally resolving that in doing a
lookup with the find by name and if we
want that static compilation we have to
use an extension function to explicitly
declare the build type it's not awesome
but that's one of the workarounds that
needed to be done
we also needed to access the default
product flavor object directly if we
were just to use the default config that
groovy provides us or that Gradle
provides us it returns the abstract
class so we would have to do an instance
of check and cast it to something
different which would be pretty gross so
this allows us to get around that a
little bit as well also in standard
groovy when using the Android build
tools you'll notice that you can set
them in SDK and the compile time SDK
just using an integer well under the
hood that's actually converting that
into an API level object so we also
created a couple extension functions to
facilitate being able to take an integer
and convert it into that so you can
definitely see that it's a proof of
concept however it goes to show the
entire Android stack can be used in
Kotlin and we can dig into some examples
now that we've moved past the script a
little bit and to where Kotlin shines
without having to have these type of
workarounds and that's in the plugins so
as your your build scale and you want to
share different logic between the
different apps that you have you start
building plugins this Kotlin in those
can be very productive
so here's a common scenario that a lot
of Android engineers would be familiar
with a developer would want to sign an
outgoing request with a consumer key and
secret for authentication on the backend
in this example we define the key in
secret and then we use them with a
generic SDK let's focus on that API key
part specifically what an obvious
improvement that we can do to
productionize the code here is to have
different
API keys for different build types or
flavors for example due to analytics you
may want a different consumer key and
secret used for the developer release
and the production release if this
wasn't an SDK but your own web service
you'd also want to define the staging
and production credentials this way
potentially as well more interestingly
what if you wanted to push this to an
open-source repo like github or allow
third-party developers or contractors to
work on your source code and you didn't
want to expose confidential information
ideally we'd have a proper separation of
concerns and we'd have these keys
provided to the application during the
build process from a secure location on
the CI machine this would meet the
previous concern and give us the
confidence that when the developer
pushed to an open source repo that they
didn't accidentally leak information
this is an example of where the Gradle
tooling can really shine what we have
here is the Android Gradle plug-in DSL
it allows us to add a constant to the
generated buildconfig class that's
accessible in the Android source code
we're able to define different keys and
secrets for various build types and
flavors both and this syntax is very
straightforward you just declare the
type followed by the name and the value
to be accessed so now we have the keys
provided to Gradle to the class that's
broadly accessible in our Android source
code although this allows us to provide
different keys for different build types
meeting one of our previous requirements
we still haven't been able to achieve
our other goal of separating the API
keys from the main repository so let's
take a look at some other techniques
that we can use with Gradle to help us
there Gradle provides a number of
mechanisms to provide our inject values
into the build process
there's the Gradle properties or
sometimes referred to as the project
properties or dash P this lives in
various locations starting in the local
project defined as the Gradle dot
properties file but also including the
user's home in the home slash dot Gradle
Gradle dot properties that lives outside
of your repo there's also the standards
standard system variables set for
running running on the terminal with
dash D lastly you can always load your
own custom property file and then use
those values in the rest of your build
lifecycle
in practice the choice varies from team
to team it's largely driven by your own
team's policies working process and
structure what CI system do you use
what's your onboarding process like for
new and new engineers and other minor
constraints once we have the property
accessible this skip prop function uses
both the Gradle properties and the
system variables and sets the order of
precedence and how they're resolved so
you can have your development key for
your dev build but when it comes to the
CI build you can have your system
variables set by a build engineer DevOps
to overwrite that to avoid accidental
check-ins and this could protect
confidential information for your
organization and here's how we could use
that get prop function in the build
Gradle whatever that has been set to
we'll inject that into the build config
class now we've met the capability to of
both of our requirements that we
mentioned earlier we have the separation
of concerns and we're being able to
inject that into the different build
types however if you have multiple keys
it can be tedious to keep track of all
the different environment variables
required to set up a new development
environment or spin up a new CI box so
you might want to create a custom
properties file and leave the Gradle dot
information like the artifact ID version
number other things like that and then
you may need a file another reason you
might want a properties file like this
is if you use third-party SDKs that rely
on these for pulling out client ID or
information like that or simply you just
want to onboard new engineers with your
own Gradle plug-in and simplify that
process as you scale out your team so if
you wanted to do that we'd add it to the
git ignore and then we'll go ahead and
we'll show some code for generating some
custom property files from that so let's
create a custom task that can be defined
in build.gradle we get all the values we
need and then we write them into the
file for the build if you're a Java
engineer that's not very familiar with
groovy with output stream will be of
interest to you here it's an extension
to the file class implemented by groovy
that just wraps opening a file and
reading the output stream conceptually
it's very similar to the Kotlin
extension functions function extension
groovy like Kotlin also does not have
checked exceptions so there's no need
for a try-catch here so now all you need
to do is run this task once for whenever
you have a new environment and a new
developer or additional keys if you add
a custom property to the get ignore file
you can then push this code to a public
repo as well without concern your team
probably has more than one app though
maybe for consistency you want to share
some of this code you can make sure
every app is set up in the same way even
better you want to reuse this process
for other external apps so let's make
this more consistent for all your apps
through building a Gradle plugin the
Gradle plug-in has three basic
ingredients that I'm going to be talking
about today and the first is the task
it's typically used to represent an
action triggered from the command line
or another task you can also extend the
project object for various things
some examples are providing values from
the build.gradle or a function to the
build.gradle this is the land object
that you normally see in your
build.gradle files
lastly the plug-in itself is used to
bind the previous components that we
just talked about into the Gradle
lifecycle and this is generally the
business logic of your plugin that we
need to talk about a very simple way to
create a custom task is by extending the
default task class functions annotated
with the at task action will be called
when the task is executed create file
function here contains the logic that we
wrote values into the custom property
file with some generalization to allow
for reusability this task requires key
and output file to be provided so that
the plug-in consumer supplies their own
lists of the keys and the path to the
file that they want to write because
this code will sit outside of the build
great l we could have written it in Java
let's do a simple example to demonstrate
why I think groovy or Kotlin would be
preferable to Java in this example this
is what it looks like in Java as you can
see it's a lot more ugly than the groovy
version that we just looked at it
includes additional try-catch null
checks and while Java developers
acclimate over time to seeing that and
kind of tuning it out and looking at the
logic it actively discourages many new
developers from approaching the codebase
especially when they're coming from
different languages how many of you have
opened up an objective-c file and had a
hard time looking past all the brackets
that's the exact same feeling that non
Java developers get when they look at
barrier for entry and I believe Kotlin
can help us out with that for dramatic
effect I'll show you what it looks like
if we just commented out all that
ceremonial code all that boilerplate and
this is about as concise as the grupe
version and as you can see it's much
easier to follow along what's going on
now that we've followed the small rabbit
hold down let's get back on track with
our plugin example to continue along
with the task another important part of
it is the defined inputs and outputs
input is the Gradle annotation that
marks a field is an input task to be
completed an output file is another
Gradle annotation that's declared in an
output of the task for this file they're
particularly important for incremental
building for the Gradle and for the
Gradle clean task to empower proper
caching and fast builds for the
consumers of this plugin to make it
easier for our plugin consumers to
configure the task we'll provide an
extension an extension is a simple class
that allows the plug-in consumer to
provide the certain data required to run
the plug-in for example it's the Gradle
so it sits primarily inside of the
Gradle plug-in DSL so this is what
you're used to and an example of this is
it's using a pogo or a groovy version of
a POJO and this gives us the
functionality to create that lambda now
these data members at compile time will
be provided with getters and setters
similar to the synthetic properties in
Colin to make it more idiomatic will
provide will also provide the key file
to shortcut assignment to file you can
add the get prop function here in the
extensions so the function can be
available to any project that applies
our plugin and lastly the plug-in itself
that will help us bind and integrate
these components into our build
lifecycle
first we want to add our extension into
the project object by using the
extensions properly property this allows
us to access the provided data by the
plug-in consumer and allows them to use
its syntax in their build the plug-in
class interacts a lot with the project
object and the Gradle provides a
configuration function in the project
object to allow for a more concise
syntax by inferring the project object
will be used in the following closure
you can see in the second line here
project extensions for more concise
example this can be inferred to sim can
be inferred to simply as extensions with
the configure closure which performs
exactly like the first example another
important part of the plugins is to make
the tasks available to the project the
after evaluate closure means that if you
want the block of code to be called once
all the initialization phase of Gradle
has been completed let's say that we
only want to add the tasks if the keys
have actually been assigned and that is
we do in the after evaluate closure to
allow the plug-in consumer setting it in
their build Gradle here we can see how
one would use that plug that plug-in in
your build.gradle script so there you
have it our Gradle plug-in in groovy
simplifying your use of the Web API keys
now let's see what it would look like if
we try to convert that into Kotlin
here's the syntax that you should
already be familiar with from the
earlier introduction that I gave to the
language we have two fields keys that
are a list and file that is nullable now
we don't need it to be Nalla Balu say
but for this demo I want to make it
novel to show you how to deal with the
interoperability of Java API s that are
by nature na level so Kotla needs to be
able to interact with that API and know
that that's not about coming in please
pay attention to the first line the open
here declares that this class is not
final by default all classes in Kotlin
are final and that'll be an issue when
it comes to building this in Gradle
because the task needs to explicitly be
extended from via Gradle and it provides
a proxy and we need to mark it as open
such the Gradle can inherit from it and
add its own logic
here's that version of create file
function when translated line by line
similar to groovy Kotlin does not have
checked exceptions so any uncaught
exception will just be elevated to the
collar here we have another version
that's a bit more idiomatic we've
replaced the for loop with a 4h and a
function literal but what's more
interesting here is this last line here
we're using the double bang operator
remember how key file was novel well
what we're saying here with the double
bang operator is that key if key file is
null
just throw the null pointer exception
and that's another way to deal with
nullable objects and ja in with nullable
objects coming from java here's our
version of the POJO as the Gradle
extension and this uses the data class
from Colin now we're looking at the
plug-in class similar to before we want
to add the extension to the project and
again we want to use the after evaluate
here to allow the extension to be set in
the build Gradle well this is cleaner
than the Java example that I showed
earlier at this stage it still looks
quite verbose and I'd love to further
improve on that some examples the fine
they get by name with the holder you're
looking that up that's just not going to
autocomplete so what can we do to
simplify this well by utilizing a couple
extension functions we can assign a
configure function to the project in the
first line extensions and extensions on
the second line one will be able to make
comfortable to those coming from groovy
so here's the example of how it looks
like before and after we use those
extension functions to clean it up you
can see in the second example how we
move towards a more declarative and
groovy like syntax so now we have the
final version of our plugin in Colin
just like with the groovy version we add
the extension the after evaluation is
done to create a task to create a file
based on the extension data that was
supplied it's declarative
nice and familiar - groovy developers
but it's consistent with the Kotlin that
is potentially already in your android
app if you use anko or similar patterns
in your android app all of your code can
start to look like this as well
I believe this reduces the context
switching the overhead and it allows for
a faster move between different layers
of the stack
I know I've run into a large case of
developers that have a little bit of
anxiety and hopping into their build
tooling coming from Android apps and I
hope that something like this can start
to make that a little more approachable
we've talked about a lot of info here
today there's some great resources on
the web to help you dig deeper into the
language first is the official Docs
they're a great learning resource with a
ton of info I'd recommend starting there
the Kotlin Cohens are a great way to
learn and play with Kotlin in your
browser it's an interactive IDE anko is
that cool plugin that I showed earlier
it's open source you can dig into that
layouts
I wouldn't necessarily using that in
production I know that some apps are but
it's kind of cool to see how that
evolves there's also the official Gradle
repo that has examples of using Kotlin
and build scripts now there was another
talk given by Jake Wharton actually last
year adore dev that dives a lot deeper
and using Kotlin in android development
I recommend watching that there's also
been a lot of other great Kotlin talks
coming out of the Android scene recently
if you wanted more information on using
that in android lastly this sample
Gradle plug-in is open source and this
one that we built today and it Scotland
version lives in this repo on github
these are all clickable links from the
slides will be shared the more people
use and contribute to Kotlin the faster
we can all have a modern language for
our day jobs since Google may take a
while to officially sanction Kotlin for
Android if they ever do it's up to us in
the community to drive the best
practices forward while Google owns
Android it's an open source ecosystem
and we are all responsible for making it
better can take some questions now
and if you don't want to say them out
loud then I'm happy to talk afterwards
as well they
for your time today thank you very much
hi
we got one question from the ABS that's
where the catalan has support for lint
in android studio right now
the linting tooling is a very tooling in
general is an awesome Jake today
introduced lint support in 104 it's
somewhat recent 103 so it's it's recent
but I don't think there's a lot of
out-of-the-box lint tooling for the
things in cotton that you might want to
be checking for so just be the Android
ones that you run I don't know
are there any questions from the
audience surprised no one's asking me
about the downsides of Collin yeah maybe
you could say something about that I
well I mean it's it's not the first
party tooling that's built by the
Android team so it's definitely running
a little slower bill times are slower
there's still Finnick enos in the IDE if
you're using an alternative build system
like buck you're going to have some
issues getting it running it's
definitely a fast moving environment so
the tooling will get there but it's
definitely a work in progress so is it
something that you would you would try -
oh absolutely absolutely guys over in
the corner no I mean for us we've had
multiple teams in uber that have been
been investigating it using it in
testing different things for a little
while I know there's been plenty of
other teams Pinterest has some of their
code written in it I know squares worked
in Kotlin a little bit on some of their
stuff it's definitely up and coming and
it's going to be a great way to put into
your apps but it's definitely since it's
still evolving is an ecosystem and the
two links coming up around it it's
something to be thoughtful about the
migration okay thank you tie and the
please give him a hand and remember to
rate the session