What is it like to develop Android projects with Kotlin?

Preface

From learning Kotlin, to writing some trial code, to doing some packaging work, to finally writing a project, I have to say that I encountered a lot of problems in the process. Although many of the pitfalls were caused by my own choices, such as using anko layout instead of xml, but overall, the surprises brought by this language are enough for me to ignore the bumps on the road.

This article is just to sort out some of my thoughts and surprises along the way. As I learn and use Kotlin, I will revise it over the long term.

text

1. With null safety, you no longer have to worry about the server returning null objects

A simple example is that String and String? are two different types. String is certain to be non-empty and must have a value; while String? is unknown and may have a value or may be empty. When using the properties and methods of an object, objects of type String can be used directly without any scruples, while objects of type String? require you to make a non-empty judgment first.

 fun demo() {
    val string1: String = "string1"  
    val string2: String? = null  
    val string3: String? = "string3"   
     
 println(string1.length)
 println(string2?.length)
 println(string3?.length)
 }

The output is:

 7
 null  
 7

Even though string2 is a null object, it does not report a null pointer just because I called its properties/methods. All you need to do is add a "?".

If this still doesn't reflect the benefits of null safety, then look at the following example:

 val a: A? = A()
 println(a?.b?.c)

Imagine that when each level of attributes may be empty, how do we handle it in JAVA?

2. Transformation and intelligent conversion saves effort and worry

I have written JAVA code like this

 if( view instanceof TextView) {
    TextView textView = (TextView) view ;
    textView.setText( "text" );
 }

The writing rules in Kotlin are different

 if( view   isTextView ) {
 TextView textView = view   as TextView
    textView.setText( "text" )
 }

The comparison is more obvious after reducing the code

 JAVA 
 
 if( view instanceof TextView) {
    ((TextView) view ).setText( "text" );
 } 
 
 Kotlin 
 
 if( view   isTextView ) {
 ( view   as TextView).setText( "text" )
 }

Compared to JAVA's way of writing (Class) before the object, Kotlin adds as Class after the object to achieve the conversion. At least for me personally, after getting used to the smooth writing of as Class, I can no longer tolerate the front-end writing in JAVA. Even with the cast shortcut key, it is still easy to interrupt my writing order and thinking.

In fact, Kotlin can be even simpler here:

 if( view   isTextView ) {
 view .setText( "text" )
 }

Because the current context has determined that view is TextView, view in the current code block is no longer a View class, but a TextView class. This is Kotlin's smart conversion.

Let's take the example of null safety above. Under normal thinking, since String and String? are different types, is it possible for me to write code like this?

 val a: A? = A()
 if (a != null ) {
 println(a?.b)
 }

If you write it this way, Kotlin will show you a highlighted warning saying that this is an unnecessary safe call. As for why, it is because you have already written a != null before, so a in this code block is no longer of type A?, but of type A.

 val a: A? = A()
 if (a != null ) {
 println(ab)
 }

Another common scenario for smart conversion is in switch case statements. In Kotlin, it is the when syntax.

 fun testWhen(obj: Any ) {
 when (obj) {
 is   Int -> {
            println( "obj is an int" )
 println(obj + 1)
 } 
 
 is String -> {
            println( "obj is a string" )
            println(obj.length)
 } 
 
 else -> {
            println( "obj is something i don't care" )
 }
 }
 } 
 
 fun main(args: Array<String>) {
 testWhen(98)
 testWhen( "98" )
 }

The output is as follows:

 obj is an int  
 99
 obj is a string
 2

It can be seen that under the condition that it has been determined to be a String, it was originally an obj object of the Any class, and I can directly use the .length attribute of the String class. In JAVA, we need to do this:

 System. out .println( "obj is a string" )
 String string = (String) obj;
 System. out .println(string.length)

or

 System. out .println( "obj is a string" )
 System. out .println(((String) obj).length)

The former interrupts the continuity of writing and reading, and the latter...

Kotlin is much smarter than that. Even now, when I am writing code, I occasionally get a highlighted warning. Only then do I realize that my writing is redundant and Kotlin has already taken care of it for me. I will not go into details here.

3. When is more powerful than switch

Through the above example of smart conversion, we have demonstrated some of the functions of when. But compared with JAVA's switch, Kotlin's when brings me much more surprises than this.

For example:

 fun testWhen( int : Int ) {
 when ( int ) {
 in 10 .. Int .MAX_VALUE -> println( "${int} is too big, I'm too lazy to calculate" )
 2, 3, 5, 7 -> println( "${int} is a prime number" )
 else -> println( "${int} is not a prime number" )
 }
 } 
 
 fun main(args: Array<String>) {
    (0..10).forEach { testWhen(it) }
 }

The output is as follows:

1. Not a prime number
2. Not a prime number
3. is a prime number
4. is a prime number
5. Not a prime number
6. is a prime number
7. Not a prime number
8. is a prime number
9. Not a prime number
10. Not a prime number
11. It's too big, I'm too lazy to calculate

Unlike the rigid switch-case statement in JAVA, in when, I can use parameters to match the range from 10 to Int.MAX_VALUE, or to match the set of values ​​2, 3, 5, 7. Of course, I haven't listed all the features here. The flexibility and simplicity of when makes me very happy when using it (compared with JAVA switch)

4. Container Operators

Since I fell in love with RxJava, it is really hard for me to go back to the past, because of the many convenient operators in RxJava. In Kotlin, the container itself has a series of operators, which can implement some logic very concisely.

For example:

 (0 until container.childCount)
        .map { container.getChildAt(it) }
        .filter { it.visibility == View .GONE }
        .forEach { it.visibility = View .VISIBLE }

The above code first creates a range from 0 to container.childCount - 1; then uses the map operator with the code to extract the child to convert this Int collection into a collection of childView; then uses the filter operator to filter the collection and selects all childViews with visibility set to GONE as a new collection; finally, forEach traverses and sets all childViews to VISIBLE.

Here is the JAVA code for comparison.

 for ( int i = 0; i < container.childCount - 1; i++) {
 View childView = container.getChildAt(i);
    if(childView.getVisibility() == View .GONE) {
        childView.setVisibility( View .VISIBLE);
 }
 }

I will not describe in detail the advantages of this chain writing method here.

5. Thread switching, so easy

Since RxJava is mentioned above, we have to think of another advantage of RxJava - thread scheduling. There is a library in Kotlin that is tailored for Android development, called anko, which contains a lot of code that can simplify development, including simplifying threads.

 async {
    val response = URL( "https://www.baidu.com" ).readText()
 uiThread {
        textView.text = response
 }
 }

The above code is very simple. The code is implemented in an asynchronous thread through the async method. After reading the response to the http request, the uiThread method is used to switch back to the ui thread to display the response on the textView.

Putting aside the internal implementation, you no longer need to write a lot of invalid code for a simple asynchronous task. According to convention, it seems that JAVA code should be posted here for comparison, but please forgive me for not wanting to refresh the screen (ah ha ha)

6. A keyword to implement a singleton

That’s right, a singleton can be implemented with just one keyword:

 object Log {
 fun i(string: String) {
 println(string)
 }
 } 
 
 fun main(args: Array<String>) {
 Log.i( "test" )
 }

Goodbye, singleton pattern

7. Automatic getter, setter and class concise declaration

There are the following classes in JAVA

 class Person {
 private String name ; 
 
 public Person(String name ) {
 this.name = name ;
 } 
 
 public void setName(String name ) {
 this.name = name ;
 } 
 
 public void getName() {
 return   name ;
 }
 } 
 
 Person person = new Person( "张三" );

Person person = new Person("张三");

It can be seen that under the standard writing method, one attribute corresponds to two methods, get and set, and the amount of code that needs to be written manually is quite large. Of course, there are shortcut keys to help us generate these codes, but considering various complex situations, it is not always perfect.

And this is what Kotlin does:

 class Person(var name : String)
 val person = Person( "张三" );

You can also add default values:

 class Person(var name : String = "张三" )
 val person = Person()

Here is a more complex data class in my project:

 data class Column (
 var subId: String?,
        var subTitle: String?,
 var subImg: String?,
        var subCreatetime: String?,
        var subUpdatetime: String?,
        var subFocusnum: Int ?,
 var lastId: String?,
 var lastMsg: String?,
        var lastType: String?,
        var lastMember: String?,
        var lastTIme: String?,
 var focus: String?,
 var subDesc: String?,
        var subLikenum: Int ?,
        var subContentnum: Int ?,
 var pushSet: String?
 )

At first glance, there is no redundant code. This is one of the reasons why I think Kotlin code is easier to write cleanly than JAVA code.

8. DSL-style programming

Speaking of DSL, the one that Android developers are most exposed to is probably Gradle.

For example:

 android {
 compileSdkVersion 23
    buildToolsVersion "23.0.2"   
 
 defaultConfig {
        applicationId "com.zll.demo"  
 minSdkVersion 15
 targetSdkVersion 23
 versionCode 1
 versionName "1.0"  
 }
 buildTypes {
 release {
            minifyEnabled false  
            proguardFiles getDefaultProguardFile( 'proguard-android.txt' ), 'proguard-rules.pro'  
 }
 }
 }

This is a Groovy DSL that declares compilation configuration.

So what does it feel like to use a DSL in your Android project code?

 override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState) 
 
    val homeFragment = HomeFragment()
    val columnFragment = ColumnFragment()
    val mineFragment = MineFragment() 
 
 setContentView(
 tabPages {
                backgroundColor = R.color.white
                dividerColor = R.color.colorPrimary
                behavior = ByeBurgerBottomBehavior(context, null ) 
 
 tabFragment {
                    icon = R.drawable.selector_tab_home
                    body = homeFragment
                    onSelect { toast( "home selected" ) }
 } 
 
 tabFragment {
                    icon = R.drawable.selector_tab_search
                    body = columnFragment
 } 
 
 tabImage {
                    imageResource = R.drawable.selector_tab_photo
                    onClick { showSheet() }
 } 
 
 tabFragment {
                    icon = R.drawable.selector_tab_mine
                    body = mineFragment
 }
 }
 )
 }

[[231055]]

That's right, the code above is used to build the viewPager + fragments + tabBar of this main interface. Start with tabPages, set the background color, dividing line and other properties; then use tabFrament to add fragment + tabButton, and the tabImage method only adds tabButton. The code you see is all for configuration, and the specific implementation is encapsulated.

The anko library mentioned earlier can actually be used to replace XML for layout:

 override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState) 
 
 verticalLayout {
 textView {
 text = "This is the title"  
 }.lparams {
            width = matchParent
 height = dip(44)
 } 
 
 textView {
 text = "This is the content"  
            gravity = Gravity.CENTER
 }.lparams {
            width = matchParent
            height = matchParent
 }
 }
 }

Compared to using JAVA code for layout, this DSL approach is also about configuration, encapsulating the layout implementation code behind, which is very similar to XML layout.

There will be a special article to introduce DSL and anko layout in the future, so I will stop here.

9. Delegation/Proxy, SharedPreference is no longer a hassle

Through the delegation function in Kotlin, we can easily write a SharedPreference proxy class

 class Preference<T>(val context: Context, val name : String?, val default : T) : ReadWriteProperty< Any ?, T> {
 val prefs by lazy {
        context.getSharedPreferences( "xxxx" , Context.MODE_PRIVATE)
 } 
 
    override fun getValue(thisRef: Any ?, property: KProperty<*>): T = with (prefs) {
        val res: Any = when ( default ) {
 is Long -> {
                getLong( name , 0)
 }
 is String -> {
                getString( name , default )
 }
 is   Float -> {
                getFloat( name , default )
 }
 is   Int -> {
                getInt( name , default )
 }
 is Boolean -> {
                getBoolean( name , default )
 }
 else -> {
                throw IllegalArgumentException( "This type can't be saved into Preferences" )
 }
 }
 res as T
 } 
 
    override fun setValue(thisRef: Any ?, property: KProperty<*>, value: T) = with (prefs.edit()) {
 when (value) {
 is Long -> putLong( name , value)
 is String -> putString( name , value)
 is   Float -> putFloat( name , value)
 is   Int -> putInt( name , value)
 is Boolean -> putBoolean( name , value)
 else -> {
                throw IllegalArgumentException( "This type can't be saved into Preferences" )
 }
 }.apply()
 }
 }

Let's skip the principle for now and see how to use it

 class EntranceActivity : BaseActivity() { 
     
    private var userId: String by Preference(this, "userId" , "" ) 
 
    override fun onCreate(savedInstanceState: Bundle?) {
 testUserId()
 } 
     
 fun testUserId() {
        if (userId.isEmpty()) {
            println( "userId is empty" )
            userId = "default userId"  
 } else {
            println( "userId is $userId" )
 }
 }
 }

Repeatedly launch the app output results:

 userId is empty
 userId is   default userId
 userId is   default userId
 ...

When the app is started for the first time, the userId retrieved from SharedPreference is empty, but it is not empty afterwards. Therefore, the code userId = "default userId" successfully modifies the value in SharedPreference.

That is to say, with the help of this Preference proxy, SharedPreference access operations become as simple as ordinary object calls and assignments.

10. Extensions, say goodbye to tools

A long time ago, someone told me that the tool class itself is something that violates the object-oriented concept. But at that time I thought, if you don't let me use the tool class, how can I write some code? It was not until I knew the concept of extension that I suddenly understood.

 fun ImageView.displayUrl(url: String?) {
    if (url == null || url.isEmpty() || url == "url" ) {
        imageResource = R.mipmap.ic_launcher
 } else {
 Glide. with (context)
                . load (ColumnServer.SERVER_URL + url)
 . into (this)
 }
 }
 ...
 val imageView = findViewById(R.id.avatarIv) as ImageView
 imageView.displayUrl(url)

The above code can be understood as:

1. I extended the ImageView class with a method called displayUrl, which receives a String object called url. If nothing goes wrong, the image at this url will be loaded through Glide and displayed on the current imageView;
2. I got an instance of the ImageView class through findViewById in another place, and then called the displayUrl method of this imageView to try to load the url I passed in.

Adding methods to ImageView through extension is less invasive than writing a CustomImageView by inheriting ImageView and then adding methods. There is no need to write CustomImageView in the code, nor to hard-code the package name in the XML layout, which will cause trouble in transplantation.

This can certainly be done with a tool class, such as ImageUtil.displayUrl(imageView, url), but the tool class does not read as naturally and smoothly as the extended method.

Extensions are a major advantage of Kotlin over JAVA