Easily move your tables between rooms

Implementing database migrations with Room just became easier, with the help of auto-migrations, introduced in version 2.4.0-alpha01. Until now, whenever your database schema changes you had to implement a Migration class and tell Room what exactly had changed. In most cases, this involved writing and executing complex SQL queries.

Now with the auto-migration feature, you indicate from which version to which version you want to migrate. Room can automatically generate migrations for simple cases like column addition, removal or new tables. For more ambiguous scenarios, Room will need some help. You’ll be able to provide concrete specifications — like a column or a table renamed or deleted — based on this, Room will generate and run the migration for you. Let’s check out some examples and see how this looks!

Putting the auto in auto-migrations

Let’s say that we’re adding a new column to a table, going from version 1 to version 2 of our database. We’ll have to update the @Database annotation by incrementing the version number and adding an auto-migration from version 1 to 2:

Whenever your database version changes again, just update the list of auto-migrations adding the new one:

For entities declared in @Database schema changes like adding a new column or table, updating the primary key, foreign key or indices or changing the default value of a column and more are automatically detected by Room and don’t require any other input.

⚠️Note: Under the hood, Room auto-migrations rely on the generated database schema, so make sure that the exportSchema option in @Database is true while using autoMigrations. Otherwise it leads to an error: Cannot create auto-migrations when export schema is OFF.

When auto-migrations need a little help

Room auto-migrations can’t detect all the possible changes performed on the database, so sometimes they need some help. A common example is that Room can’t detect whether a table or a column was renamed or deleted. When this happens, Room will throw a compile time error asking you to implement a AutoMigrationSpec. This class allows you to specify the type of change you made. Implement an AutoMigrationSpec and annotate it with one or more of:

• @DeleteTable(tableName)
• @RenameTable(fromTableName, toTableName)
• @DeleteColumn(tableName, columnName)
• @RenameColumn(tableName, fromColumnName, toColumnName)

For example, let’s say that we’re renaming the Doggos table to GoodDoggos. Room can’t detect whether this is a completely new table and we deleted the Doggos table, or the table was renamed and all of the values need to be kept.

Migrations vs Auto-migrations

When to use Migrations

To manually handle migrations, Room has offered the Migration class since version 1.0. Whenever you have complex database schema changes to make, you’ll have to use this class. For example, let’s say that we’ve decided to split a table into 2 different tables. Room can’t detect how this split has been performed, and can’t automatically detect which data to move. So this is when you’ll have to implement a Migration class and add it to the databaseBuilder() via addMigrations() method:

Combining migrations and auto-migrations

Room allows combining migrations with auto-migrations. For example, migrating from version 1 to version 2 may be done using Migration, version 2 to version 3 using auto-migration etc. If you define a Migration and an auto-migration for the same version, then the Migration will be run.

Under the hood an auto-migration constructs a Migration class, so the same migration logic described in detail here still applies. TL;DR: When the database is first accessed, Room checks whether the current database version is different from the one in @Database. If yes, Room looks for migration paths going from one to the other. Migrations are then run consecutively.

Testing auto-migrations

To test auto-migrations, you can use the MigrationTestHelper test rule and call helper.runMigrationsAndValidate(), in the same way as when using the Migration class. Read more about testing migrations in our documentation.

Conclusion

The auto-migration feature allows you to easily handle database schema changes by using the autoMigration parameter in @Database. While a lot of the basic cases can be handled by Room, for table / column delete or rename you’ll have to implement a AutoMigrationSpec. For all other cases, continue using Migrations.

This feature is currently in alpha. Help us make it better by providing feedback on our issue tracker.

Room auto-migrations was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

WorkManager — Kotlin APIs

WorkManager provides a set of APIs that makes it easy to schedule asynchronous tasks for immediate or deferred execution that are expected to run even if the app is closed or the device restarts. For Kotlin users, WorkManager provides first-class support for coroutines. In this post I’ll show you the basics of WorkManager with coroutines by building on the WorkManager codelab. So let’s get started!

The basics of WorkManager

The WorkManager library is the recommended choice for any task that should continue to run, even if the user navigates away from the particular screen, the user puts the application in background or the device restarts. Common tasks could be:

• Uploading logs or reporting data
• Applying filters to images and saving the image
• Periodically syncing local data with the network

If your immediate task can end when the user leaves a certain scope such as a screen, we recommend you use Kotlin Coroutines directly.

The WorkManager codelab blurs images and saves the result on disk. Let’s see what was needed to achieve this.

We added the work-runtime-ktx dependency.

implementation "androidx.work:work-runtime-ktx:$work_version"

We started by implementing our own Worker class. This is where we put the code for the actual work you want to perform in the background. You’ll extend the Worker class and override the doWork() method. As this is the most important class we’ll go over it in detail later. Here’s what the initial implementation looks like.

Then, we build our work request, in our case, we want to perform the work only once so we use a OneTimeWorkRequest.Builder. As input, we set the Uri of the image we want to blur.

Kotlin tip: to create the input data, we can use the workDataOf function that creates the data builder, puts the key-value pair and creates the data for us.

To schedule the work and make it run, we use the WorkManager class. We can provide tasks to be done and constraints to these tasks.

Make the Worker do the work

When you use a Worker, WorkManager automatically calls Worker.doWork() on a background thread. The Result returned from doWork() informs the WorkManager service whether the work succeeded and, in the case of failure, whether or not the work should be retried.

Worker.doWork() is a synchronous call — you are expected to do the entirety of your background work in a blocking fashion and finish it by the time the method exits. If you call an asynchronous API in doWork() and return a Result, your callback may not operate properly.

But what if we want to do asynchronous work?

Let’s complicate our example and say that we want to save the Uris of all the files that have been blurred in the database.

For this I created:

• A simple BlurredImage entity
• A dao class to insert and get images
• The database

Check out the implementation here.

If you have to do asynchronous work, like saving data in the database or doing network requests, in Kotlin, we recommend using a CoroutineWorker.

A CoroutineWorker allows us to do asynchronous work, using Kotlin coroutines.

The doWork() method is a suspend method. So this means that we can easily call our suspending dao here.

By default doWork() uses Dispatchers.Default. You can override this with the Dispatcher that you need. In our case, we don’t need to do this because Room already moves the insert work on a different Dispatcher. Check out the Room Kotlin APIs post for more details.

Start using CoroutineWorker to perform asynchronous work that needs to complete even if the user closes your app.

If you want to learn more about WorkManager, stay tuned for a future series dedicated to covering it in depth. Until then, check out our codelabs and documentation:

• WorkManager documentation
• Working with WorkManager codelab
• Advanced WorkManager codelab

WorkManager — Kotlin APIs was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Room is a wrapper over SQLite and it makes working with databases on Android so much easier and is by far my favorite Jetpack library. In this post I want to tell you how to use and test Room Kotlin APIs and while we do that, I’ll also share how things work under the hood.

We’re going to use the Room with a view codelab as a basis. Here we’re building a list of words that are saved in the database and displayed on the screen. The user can also add words to the list.

Define the database table

In our database we have only one table: the one containing words. The Word class represents an entry in the table and it needs to be annotated with @Entity. We use @PrimaryKey to define the primary key for the table. Based on this, Room will generate a SQLite table, with the same name as the class name. Each member of the class becomes a different column in the table. The column name and type is given by the name and type of each field. You can change it by using the @ColumnInfo annotation.

We recommend you always use the @ColumnInfo annotation as it gives you more flexibility to rename the members without having to change the database column names. Changing the column names leads to a change in the database schema and therefore you need to implement a migration.

Access the data in the table

To access the data in the table we create a data access object (DAO). This will be an interface called WordDao, annotated with @Dao. We want to insert, delete and get data from the table so these will be defined as abstract methods in the DAO. Working with the database is a time consuming I/O operation, so this needs to be done on the background thread. We’ll use Room integration with Kotlin coroutines and Flow to achieve this.

We’ve covered the basics of working with coroutines in this Kotlin vocabulary video. Check out this video for information about Flow.

Insert data

To insert data create an abstract suspend function that gets as parameter the Word to be inserted and annotate it with @Insert. Room will generate all the work that needs to be done to insert the data in the database and, because we made the function suspend, Room moves all the work to be done to a background thread. Thus, this suspend function is main-safe: safe to be called from the main thread.

@Insert
suspend fun insert(word: Word)

Under the hood Room generates the implementation of the Dao. Here’s how the implementation of our insert method looks like:

CoroutinesRoom.execute() function is called, with 3 parameters: the database, a flag to indicate whether we’re in a transaction and a Callable object. Callable.call() contains the code that handles the database insertion.

If we check the CoroutinesRoom.execute() implementation, we see that Room moves callable.call() to a different CoroutineContext. This is derived from the executors you provide when building your database or by default will use the Architecture Components IO Executor.

Query data

To query the table, we’ll create an abstract function and annotate it with @Query, passing in the SQL query needed to get the data we want: all words from the word table, ordered alphabetically.

We want to be notified whenever the data in the database changes, so we return a Flow<List<Word>>. Because of the return type, Room runs the query on the background thread.

@Query(“SELECT * FROM word_table ORDER BY word ASC”)
fun getAlphabetizedWords(): Flow<List<Word>>

Under the hood, Room generates the getAlphabetizedWords() for us:

We see a CoroutinesRoom.createFlow() call, with 4 parameters: the database, a flag indicating whether we’re in a transaction, the list of tables that should be observed for changes (in our case just word_table) and a Callback. Callback.call() contains the implementation of the query to be triggered.

If we check the CoroutinesRoom.createFlow() implementation, we see that here as well the query call is moved to a different CoroutineContext. Like with the insert call, this dispatcher is derived from the executors you provide when building your Database or by default will use the Architecture Components IO executor.

Create the database

We’ve defined the data to be stored in the database and how to access it, now it’s time to define the database itself. For this, we create an abstract class that extends RoomDatabase, annotate it with @Database, passing in Word as the entity to be stored, and 1 as database version.

We’ll define an abstract method that returns the WordDao. Everything is abstract because Room is the one that generates the implementation for us. Like this, there’s a lot of logic that we no longer need to implement.

The only step left is to build the database. We want to make sure we don’t have multiple database instances open at the same time, and we need the application context to initialise the database. So one way to handle this is to define a RoomDatabase instance in the companion object of our class, and a getDatabase function that builds the database. If we want Room queries to be executed on a different Executor than the IO Executor created by Room, we can pass it in the builder by calling setQueryExecutor().

Testing the Dao

To test the Dao we need to implement an AndroidJUnit test as Room creates an SQLite database on the device.

When implementing the Dao test, before each test is run, we create the database. After each test is run, we close the database. As we don’t need to save the data on the device, when creating the database, we can use an in-memory one. As this is a test, we can allow queries to be run on the main thread.

To test if a word is inserted successfully, we’ll create a word, insert it, get the first word from the list of alphabetised words and ensure it’s the same as the word we created. As we’re calling suspend functions, we’ll run the test in a runBlocking block. Since this is a test, we don’t mind if the test blocks the test thread.

Room offers a lot more functionality and flexibility than what we’ve covered — you can define how Room should handle database conflicts, you can store types that otherwise, natively with SQLite can’t be stored, like Date, by creating TypeConverters, you can implement complex queries, using JOIN and other SQL functionality, create database views, pre-populate your database or trigger certain database actions whenever the database is created or opened.

Check out our Room documentation for more information and the Room with a view codelab for hands-on learning.

Using and testing Room Kotlin APIs was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin is known for its conciseness and this, in practice, translates into higher productivity. Even more, 67% of professional Android developers who use Kotlin say it has increased their productivity. In this blog post, I’ll share a couple of ways Kotlin has increased the productivity of our partners’ engineers and look at the Kotlin features that help with this.

67% of professional Android developers surveyed who use Kotlin say it has increased their productivity

Conciseness, simplicity and productivity

Kotlin’s conciseness has effects on all stages of development:

• As an author it means that you can focus on the problem you need to solve, rather than on the syntax. Less code means less to test and less to debug and less chances of creating bugs.
• As a reviewer or maintainer it means that you have less code to read, making it easier to understand what the code does, and therefore easier to review or maintain.

One example of this comes from the team at Flipkart:

“During an internal survey, 50% of developers mentioned that they’d provide smaller estimates [to complete a feature] if the module was written in Kotlin.” (Flipkart)

Kotlin features and productivity

The majority of Kotlin features result in higher productivity, both due to conciseness and higher readability so let’s look at some of the most used ones.

Default arguments and builders

In the Java programming language, when some of the parameters of your constructor are optional, you usually take one of two roads:

• Add multiple constructors
• Apply the builder pattern

With Kotlin neither of these is necessary due to the use of default arguments. Default arguments allow you to implement function overloads without the extra boilerplate.

When the Cash App team started using Kotlin, they were able to eliminate many builders, and cut down on the amount of code they needed to write. In some cases, they saved 25% in code size.

For example, here’s how the implementation of a Task object, where the name of the task is the only mandatory parameter would look like when using a builder or when using default arguments:

Find out more about default arguments from our Kotlin Vocabulary blog post.

Objects and singletons

The singleton pattern is probably one of the most used patterns in software development — it helps you create a single instance of an object which can be accessed and shared by other objects.

To create a singleton you would need to control how the object is created, allowing only one instance of it and making sure that the code is thread safe. In Kotlin, you only need one keyword: object.

Operators, string templates and more

The conciseness and simplicity of the Kotlin language is shown in features like operator overloading, destructuring or string templates — the resulting code gets so easy to read.

For example, let’s say that we have a library with books. To remove a book from the library, and then work only with the title and print it, the code we write can look like this:

Here are the Kotlin features used:

• -= is implemented using operator overloading
• val (title, author) = book uses destructuring
• println(“Borrowed $title”) uses string templates

Conclusion

Kotlin makes it easy to read and write code. Patterns like singleton or delegation are part of the language, removing the need to write a lot of code that can lead to bugs being introduced and a higher maintenance burden. Features like string templates, lambda expressions, extension functions, operator overloading and more, make the code more concise and simple. Less code to write leads to less code to read, less code to maintain, fewer errors and higher productivity.

Read more about how you can Build Better Apps with Kotlin, and see how developers have benefited from Kotlin by reading our case studies. To make your first steps with Kotlin, one of the most loved languages in the world, check out our Getting started page.

More productivity with Kotlin was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

When using Android Java APIs in Kotlin, you quickly realise that you’re missing out on some of the Kotlin features that make coding so much easier and pleasant. Instead of writing your own wrappers and extension functions for these APIs, take a look at the Jetpack KTX libraries. Currently, more than 20 libraries have a KTX version, creating sweet idiomatic versions of Java APIs, ranging from Android platform APIs to ViewModels, SQLite and even Play Core. In this post we’ll look at some of the APIs available and peek under the hood to see how they were made.

If you prefer watching a video to reading a blog post check it out here:

Discoverability

As a best practice, to ease the discoverability of ktx functionality, always import the -ktx artifact when available. As the -ktx artifact depends transitively on the non-ktx version, you don’t need to include the other artifact. For example, for viewmodel you get 2 artifacts: viewmodel and viewmodel-ktx. The -ktx artifact will contain the Kotlin extensions:

// Java language implementation
implementation "androidx.lifecycle:lifecycle-viewmodel:$lifecycle_version"

// Kotlin implementation
implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version"

Always import the -ktx artifact

For extensions on the Android platform APIs, import the core-ktx artifact.

implementation "androidx.core:core-ktx:$corektx_version"

The majority of ktx functionality is implemented as extension functions so you’ll be able to easily find them by using auto-complete in Android Studio.

Other functionality, like the destructuring and operator overloading available on classes like Color can be discovered by checking out the list of KTX extensions.

Platform APIs — core-ktx

core-ktx provides idiomatic Kotlin functionality for APIs coming from the Android platform.

For example, if you’re working with SharedPreferences, when you want to update a value, instead of executing 3 different calls, you can just do one:

Under the hood, the ktx edit method calls the same functionality, providing a good commit default option: apply(). apply(), unlike commit(), commits the changes on disk asynchronously:

In core-ktx you’ll also find an easier way of handling frequently used platform listeners. For example, if you want to trigger an action when text was changed in an EditText, you’d have to implement all the methods of the TextWatcher, even if you’re only interested in onTextChanged(). core-ktx creates the corresponding TextWatcher methods: doOnTextChanged, doAfterTextChanged and doBeforeTextChanged, but in your Kotlin code, you just use the one you need:

This brings several benefits: your code becomes easier to read, as it’s more concise and you get better naming and nullability annotations.

You’ll find similar listener APIs for AnimatorListener and TransitionListener.

Under the hood, doOnTextChanged is implemented as an extension function on TextView — the class that also has the addTextChangedListener method. doOnTextChanged creates empty implementations for the other functions of the TextWatcher.

Jetpack APIs

The majority of extensions available are for Jetpack APIs. Here I’ll just go over some of the ones I found myself using most often.

LiveData

A lot of the LiveData functionality is implemented as extension functions as well: methods like map, switchMap or distinctUntilChanged (source).

For example, using map from livedata-ktx removes the need to call Transformations.map(livedata) { /* map function */ }, and allows us to call directly liveData.map in a more Kotlin idiomatic way.

When you observe a LiveData object, you’ll have to implement an Observer. But using the observe from lifecycle-ktx, the code becomes simpler. Make sure you call import androidx.lifecycle.observe if the method isn’t found.

LiveData is ideal for exposing data to be consumed by the UI so, to convert from Flow to LiveData and from LiveData to Flow, the lifecycle-livedata-ktx artifact provides two handy extension functions: Flow.asLiveData() and LiveData.asFlow().

Activity / Fragment and ViewModel

To construct a ViewModel, you would extend the ViewModel class and implement ViewModelProvider.Factory if your ViewModel has dependencies. To instantiate it, use the viewModels delegate (read more about delegates here): by viewModels(factory):

viewModels is available in the -ktx artifact of activity and fragment.

When working with coroutines, you’ll find yourself needing to launch a coroutine in the ViewModel. The work done by the coroutine should be cancelled when the ViewModel is destroyed. Instead of implementing your own CoroutineScope, use viewModelScope. The cancellation will be done automatically for you, in ViewModel.onCleared(). Find out the ins and outs of viewModelScope from this blog post.

Room and WorkManager

Both Room and WorkManager offer coroutines support via their -ktx artifacts. As we think it’s worth covering those more in depth, stay tuned for MAD Skills articles focused on those specific libraries!

Other KTX modules

AndroidX artifacts are not the only ones to provide KTX versions:

• Firebase has created common Kotlin extensions
• Google Maps offers Maps and Places ktx libraries
• Play Core has a core-ktx artifact, providing coroutines support for monitoring in-app updates

Concise, readable and Kotlin idiomatic — these are the features that will benefit your code, once you start using -ktx extensions. Stay tuned for more ways to take advantage of Kotlin and Jetpack in your app!

Using KTX libraries was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data classes — the classy way to hold data

Kotlin Vocabulary: data classes

A Puppy has a name, a breed and a whole lot of cuteness. To model a class that holds just data, you should use a data class. The compiler simplifies your work by auto generating toString(), equals() and hashCode() for you and providing destructuring and copy functionality out of the box letting you focus on the data you need to represent. Read on to learn more about other advantages of data classes, their restrictions and to take a look under the hood of how they’re implemented.

Usage overview

To declare a data class, use the data modifier and specify the properties of the class as val or var parameters in the constructor. As with any function or constructor, you can also provide default arguments, you can directly access and modify properties and define functions inside your class.

But, you get several advantages over regular classes:

• toString(), equals() and hashCode() are implemented for you, by the Kotlin compiler, avoiding a series of small human errors that can cause bugs: like forgetting to update them every time you add or update your properties, logic mistakes when implementing hashCode, forgetting to implement hashCode when you’re implementing equals and more.
• destructuring
• ease of copying by calling the copy() method:

Restrictions

Data classes come with a series of restrictions.

Constructor parameters

Data classes were created as a data holder. To enforce this role, you have to pass at least one parameter to the primary constructor and the parameters need to be val or var properties. Trying to add a parameter without val/var leads to a compile error.

As a best practice, consider using vals instead of vars, to promote immutability. Otherwise, subtle issues can appear for example when using data classes as keys for HashMap objects, as the container can get in an invalid state when the var value changes.

Similarly, trying to add a vararg parameter in the primary constructor leads to a compile error as well:

vararg is not allowed due to how equals() works on the JVM for arrays and collections. Andrey Breslav explains:

Collections are compared structurally, while arrays are not, equals() for them simply resorts to referential equality: this === other.

Inheritance

Data classes can inherit from interfaces, abstract classes and classes but cannot inherit from other data classes. Data classes also can’t be marked as open. For example, adding open will result in an error: Modifier ‘open’ is incompatible with ‘data’.

Under the hood

Let’s check what exactly does Kotlin generate to be able to understand how some of these features are possible. To do this, we’ll look at the Java decompiled code: Tools -> Kotlin -> Show Kotlin Bytecode then press the Decompile button.

Properties

Like with a regular class, Puppy is a public final class, containing the properties we defined and the getters and setters for them:

Constructor(s)

The constructor we defined is generated. Because we use a default argument in the constructor, then we get the 2nd synthetic constructor as well.

To find out more about default arguments and the generated code, check out this blog post.

toString(), hashCode(), equals()

Kotlin generates the toString(), hashCode() and equals() methods. When you modify the data class, updating properties, the right method implementations are generated for you, automatically. Like this, you know that hashCode() and equals() will never be out of sync. Here’s how they look for our Puppy class:

While toString and hashCode are quite straightforward an look similar to the way you’d implement it, equals uses Intrinsics.areEqual that performs a structural equality:

public static boolean areEqual(Object first, Object second) {
    return first == null ? second == null : first.equals(second);
}

By using a method call rather than the direct implementation, the Kotlin language developers get more flexibility, as they can change the implementation of areEqual in future language versions, if needed.

Components

To enable destructuring, data classes generate componentN() methods that just return a field. The component number follows the order of the constructor parameters:

Find out more about destructuring from our Kotlin Vocabulary post.

Copy

Data classes generate a copy() method that can be used to create a new instance of the object, keeping 0 or more of the original values. You can think of copy() as a method that gets all fields of the data class as parameters, with the values of the fields as default values. Knowing this, you won’t be surprised that Kotlin generates 2 copy() methods: copy and copy$default. The latter is a synthetic method that ensures that when a value isn’t passed in for a parameter, then the right value is used from the base class:

Conclusion

Data classes are one of the most used Kotlin features and for a good reason — they decrease the boilerplate code you need to write, enable features like destructuring and copying an object and let you focus on what matters: your app.

Data classes — the classy way to hold data was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever since we announced our Kotlin support in 2017 we’ve been getting a lot of questions about Kotlin on Android: you wanted to know whether it’s time to learn it, to introduce it to your app, what the best course or tutorial to learn Kotlin is, whether Google is using Kotlin internally and what our plans for the Java programming language are. In this post, I want to answer some of these questions.

Q: Should I learn Kotlin for Android?

The questions we get most often are on the same line:

• “What should I choose to learn between Kotlin and the Java programming language for a beginner?”
• ​”I’ve done the basics of the Java programming language, is it the right time for me to switch to Kotlin for Android development?”
• “For an old time Java developer wanting to learn Android development, do you recommend going straight to Kotlin or learning in Java?”

Short answer:

Yes! Start learning and using Kotlin!

Long answer:

Kotlin & Android

In 2017 we announced Kotlin support at Google I/O. That’s when we started making the first steps towards ensuring that our APIs, docs and samples are Kotlin friendly. In 2019 Android became Kotlin-first, so we started relying even more on Kotlin features. As an example, Coroutines became our recommended solution for running asynchronous work. Here’s what else we’ve done:

Kotlin-first libraries

We started by adding first class support for Kotlin Coroutines to several of our Android Jetpack APIs, like Room, LiveData, ViewModel and WorkManager, transforming the way we do async operations on Android. The Firebase Android SDK and many Jetpack libraries have Kotlin extension libraries (KTX) to make using them even more fluent with Kotlin.

Now, many of our libraries such as Paging 3.0 and DataStore are Kotlin-first. Jetpack Compose, our new, unbundled, declarative UI toolkit, is written from the ground up in Kotlin.

Tooling

Development productivity comes from great tooling. As such, we’ve been making many improvements for Kotlin to the compilation toolchain, including enhancements to the Kotlin JVM compiler, Kotlin-specific R8 optimizations, and even developing new tools like Kotlin Symbol Processing. We’ve added built-in Android Kotlin Live templates, which allow you to use shorthand to add common Android constructs to your Kotlin app. At the same time, new Kotlin-specific Lint checks help you make Kotlin code more language idiomatic. This is especially useful as you’re transitioning from the Java programming language to Kotlin.

Q: Is Google using Kotlin internally?

Within Google we’re also doubling down on Kotlin. Over 60 of our apps (like Google Home, Drive, Maps and others) have added Kotlin to their codebases. Our large internal codebase counts over two million lines of Kotlin code.

Q: Should I migrate my app to Kotlin?

We often get this question, but the answer here depends on you. If you’re happy with your current codebase and tech stack, are proficiently using your solution for managing async tasks, and have an efficient way to catch errors, migrating may not be the solution for you

If you like what you’ve seen with Kotlin from either trying it or learning the language through some of the courses mentioned below, and you also want to take advantage of the latest Jetpack APIs, then you should consider adding Kotlin to your app. One of the advantages of Kotlin is it’s great interop with the Java programming language. You can take small, incremental steps in adopting it — maybe first trying it out on tests, then on new features and then you can try converting some of the older code as you touch it.

To make your first steps towards migrating to idiomatic Kotlin check out our Converting to Kotlin codelab.

Q: What about the Java programming language in Android?

We added Kotlin support in addition to Java as they both compile to the same bytecode and can exist alongside each other. We love Kotlin for its expressive, safer way to write code. We continue to maintain and evolve our Java support as well. For example, in Android 11, we added support for a number of APIs from newer OpenJDK releases all the way up to version 13 and Android Studio even lets you use some of these APIs on all Android devices, regardless of their OS version. Read more about the support for newer language APIs here.

Q: What’s the best way to learn Kotlin?

Adopting a new language is not an easy task, but we’re trying to make it as easy as possible:

• Get started with the training courses — they address developers of all levels, from beginners to pros, that will help you advance your Kotlin on Android skills, from Android Basics in Kotlin, a new online course for people without programming experience, to advanced tutorials that teach you how to use Coroutines.
• All of our documentation pages contain Kotlin code snippets, so you can easily compare how our APIs work in both languages, and all of our samples have Kotlin versions.
• Check out our articles and videos that teach you a wide range of Kotlin topics.
• Read the guidance for developers and teams who want to switch to Kotlin on our developers.android.com/kotlin pages.

Since officially adding support for Kotlin 3 years ago, we’ve been stepping up to support this awesome language and ecosystem. Together with JetBrains, we’ve formed a foundation for Kotlin to ensure the language ages well, for example through a careful process for vetting breaking changes. Our contributions extend beyond that: Google has a team of engineers contributing to the Kotlin compiler as their full-time job, the Jetpack APIs we’re building are not only supporting Kotlin but they are Kotlin-first, and we’re committed to making Kotlin on Android a seamless experience.

Java is a registered trademark of Oracle and/or its affiliates.

Should I learn Kotlin for Android and other FAQs was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Users expect to have a seamless experience with your app. Crashes can lead to an increase in poor reviews, uninstalls and even damaging your brand perception. From talking to the community we know that one of the main reasons to adopt Kotlin is safer code. In this post I’ll share a couple of the ways Kotlin improved the stability of a few of our partners’ code but we’ll also look at the results of some Google Play store stats and see if there’s a correlation between using Kotlin and the number of crashes (spoilers: there is!).

App quality

The quality of your app doesn’t only have an impact on your user experience. There are several other elements that will be affected by a high number of crashes:

• App discoverability — Google Play store’s recommendations are composed of a mix of human curation and algorithmic calculations, of which quality is one of the largest considerations.
• Brand — Your product performance can impact your ratings and reviews, which can impact brand perception.
• Higher number of (engaged) users — Having improved organic traffic and brand perception can lead to better user acquisition and retention, which can also impact engagement and lower funnel metrics.

Apps built with Kotlin are 20% less likely to crash.

What role does Kotlin play in this? We looked at the top 1,000 apps on Google Play and we saw those that use Kotlin have 20% fewer crashes per user than those that don’t.

One example of this comes from the engineering team at Swiggy, where 74% of their code is in Kotlin — they saw a 50% reduction in crashes since moving new feature development to Kotlin.

Avoiding NullPointerExceptions

The #1 cause of crashes on Google Play are NullPointerExceptions. In 2018, the Google Home team started writing all new features in Kotlin and saw a 33% decrease in Null Pointer crashes over one year.

Google Home saw a 33% decrease in NullPointerExceptions

To avoid NullPointerExceptions, you need to make sure that the object references you’re working with are non-null before calling methods on them or trying to access their members. In Kotlin, nullability is part of the type system. For example, a variable needs to be declared from the beginning as nullable or non-nullable. By making nullability part of the type system you don’t have to rely on your memory and knowledge of the codebase, or on compile time warnings (if you annotate your fields / parameters with @Nullable) but rather nullability gets enforced, so you’ll get compile time errors, not just warnings. For ways to handle nullability check out this page.

Avoiding common issues

There are a lot of issues that we developers introduce without realising and a lot of them can be quite subtle and hard to investigate. Here are just a few of these issues that are avoided when using Kotlin.

hashCode() and equals()

If two objects are equal, then their hashcode should be the same — but yet, it’s common to forget to implement one of these methods or to update them when new properties are added to the class. When working with classes whose role is to just hold data, use Kotlin data classes. With data classes hashCode() and equals() is generated for you by the compiler and therefore automatically updated when you change the class’s properties.

Structural vs referential equality

Are two objects structurally equal (have equivalent content) or referentially equal (their pointers are the same)? In the Java programming language, for primitives you would always use ==, therefore, a common mistake is to call == (referential equality) for objects as well, when you actually want to check if they are structurally equal (checked by calling equals()). First, Kotlin doesn’t have primitive types, it uses classes like Int or String; so this means that you don’t need to make this differentiation between objects and primitive types anymore as everything is an object. Second, Kotlin defined == for structural equality and === for referential equality so you won’t be checking for referential equality when you shouldn’t.

When if else if else if else is not enough

When working with enums, you often need to ensure that you’re covering all the possible cases. This leads to using a switch or a chain of if elses. When you modify your enum to add a new value, you then have to manually check each code snippet where you’re using the enum and make sure you’re handling the new case. But this is error prone. In Kotlin, you can rely on the compiler for this, if you’re using when as an expression: you’ll get a compiler error if you’re not covering all possible branches.

Conclusion

The stability of your app is important for your users and your brand. Start using Kotlin to reduce crash rates, keep your users happy and stay on top of your retention and acquisition by keeping a high app rating.

Read more about how you can Build Better Apps with Kotlin, and see how developers have benefited from Kotlin by reading our case studies. To make your first steps with Kotlin, one of the most loved languages in the world, check out our Getting started page.

Fewer crashes and more stability with Kotlin was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin Vocabulary — destructuring

Sometimes you just want to break down one object that contains multiple fields to initialize several separate variables. To achieve this, you can use Kotlin’s destructuring declarations. Read on to find out how to use this feature, what Kotlin types offer it by default, how to implement it in your own classes or for classes that you don’t control but you think would benefit from destructuring and how everything works under the hood.

Usage

Destructuring declarations allows us to define local values/variables as such:

It’s a convenient way to work with data coming from functions or collections:

By default, all data classes support destructuring.

You can decide to only use a subset of variables from your class’s fields:

Destructuring doesn’t allow you to pick exactly which fields you want to use; it will always use the first x fields, where x is the number of variables you declare. The downside of this is that it’s easy to make mistakes. For example the following snippet might provide an unexpected result:

val (name, rating) = goodDoggo

The rating value will actually hold the value of goodDoggo.breed. You will get a warning saying: “Variable name ‘rating’ matches the name of a different component” and a suggestion to rename the rating to breed. As this is only in the IDE and not a compile warning it might be easy to miss.

Using a wrong destructuring variable declaration

If you only need a subset of non-consecutive fields, use _ for those you’re not interested in, Kotlin will just skip them. The example above becomes:

val (name, _, rating) = goodDoggo

Under the hood

Let’s take a look at a decompiled data class to see what’s going on. In this post we’ll only focus on the functions generated for destructuring. For more information on data classes in general, stay tuned for a future post.

To see the Java decompiled code, go to Tools -> Kotlin -> Show Kotlin Bytecode then press the Decompile button.

We see that functions called componentN are generated for every property declared in the primary constructor, where N is the index of the field in the primary constructor.

Implementing destructuring

As we’ve seen, destructuring relies on componentN functions. So if you want to add the destructuring functionality to a class that doesn’t support it, then just implement the corresponding componentN operator function. Make sure you prefix them with the operator keyword.

Implementing destructuring for classes you don’t own

Kotlin allows you to implement destructuring for classes you don’t own via extension functions. For example, Map.Entry is just an interface and by default it does not support destructuring. To overcome this, component1() and component2() functions were created, that return the key and value of Map.Entry.

Conclusion

Use destructuring whenever you need to unpack the fields of an object to values/variables. Under the hood destructuring is implemented by providing componentN operator functions, so you can provide those yourself for classes that you think benefit from this functionality.

Breaking down destructuring declarations was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin Vocabulary

Short and easy to use, default arguments allow you to implement function overloads without the boilerplate. Like many Kotlin features, this can feel like magic. Are you curious to learn its secrets? Read on to find out how default arguments work under the hood.

Basic usage

If you need to overload a function, instead of implementing the same function multiple times, you can use default arguments:

Default arguments can be applied to constructors as well:

Java interop

By default, Java doesn’t recognize the default value overload:

To instruct the compiler to generate the overload methods, use the @JvmOverloads annotation on your Kotlin function:

Under the hood

Let’s look at the Java decompiled code to see what the compiler generates for us: Tools -> Kotlin -> Show Kotlin Bytecode then press the Decompile button.

Functions

We see that the compiler generates 2 functions:

• play — that has 1 parameter: Toy and is called when default arguments are not used
• a synthetic method play$default — that has 3 parameters: Toy, an int and an Object; it’s called whenever the default arguments are used. The Object parameter is always null but the value of the int differs. Let’s see how!

The int parameter

The value of the int parameter of play$default is computed based on the number and the index of the arguments that have a default argument passed in. Based on the value of this parameter, the Kotlin compiler knows with which parameters to call the play function.

In our play() example call, the argument at index 0 is using the default argument. Therefore, play$default is called with int var1 = 2⁰:

play$default((Toy)null, 1, (Object)null);

The play$default implementation then knows that the value of var0 should be replaced with the default value.

Let’s take a more complex example to see how the int parameter behaves. Let’s expand our play function and, at the call site, use the default argument for doggo and toy:

Let’s see what happened in the decompiled code:

We see that now, our int parameter is 5. Here’s how this was computed: the parameters at positions 0 and 2 are using the default argument so var3 = 2⁰ + 2² = 5. In a bitwise & operation, the parameters get evaluated as such:

• var3 & 1 != 0 is true so var0 = goodDoggo
• var3 & 2 != 0 is false so var1 is not replaced
• var3 & 4 != 0 is true so var2 = SqueakyToy

Based on the bitmask applied to var3, the compiler can compute which parameters should be replaced with default values.

The Object parameter

In the examples above you might have noticed that the value of the Object parameter is always null and that it’s actually never used in the play$default function. This parameter is connected to supporting default values in overriding functions.

Default arguments and Inheritance

What happens when we want to override a function with default arguments?

Let’s change the example above and:

• Make play an open function of Doggo and Doggo an open class.
• Create a new PlayfulDoggo class, that extends Doggo and overrides play

When we want to set a default value in PlayfulDoggo.play we see that we are not allowed: An overriding function is not allowed to specify default values for its parameters

If we remove the override and we check the decompiled code, PlayfulDoggo.play() looks like this:

Does this mean that super calls with default arguments will be supported in the future? We’ll just have to wait and see.

Constructors

For constructors, the decompiled Java code has only one difference. Let’s take a look:

Constructors also create a synthetic method but, instead of the Object used in functions, constructors use a DefaultConstructorMarker which is called with null:

Secondary constructors with default arguments will also generate another synthetic method using a DefaultConstructorMarker, like primary constructors:

Conclusion

Simple and sweet, default arguments decrease the amount of boilerplate code we need to write when dealing with overloaded methods, allowing us to set default values for our parameters. As is the case for a lot of Kotlin keywords, when can understand their magic by peeking at the code it writes for us. Check out our other Kotlin Vocabulary posts for more.

Don’t argue with default arguments was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.