Ce à quoi j'ai pensé lorsque j'ai commencé à migrer de Java vers Kotlin

Commencé à écrire Kotlin

J'ai jusqu'à présent écrit des applications Android développées par la société en Java, mais avec le support officiel de la version Android Studio 3.0 = Kotlin fin octobre, j'ai décidé d'utiliser Kotlin pour implémenter la nouvelle partie développement. De plus, la partie implémentation existante est réécrite petit à petit selon les besoins (également pour la pratique).

Donc, je ne l'ai pas encore utilisé depuis un mois, mais j'écrirai ce que j'ai ressenti en écrivant Kotlin.

• Au fait, en ce qui concerne la réécriture de la partie existante, la fonction de conversion automatique d'Android Studio (≒ IntelliJ) est très excellente. Il est facile de convertir le fichier entier, et je suis heureux que si vous copiez une partie du code Java et le collez dans le fichier .kt, il sera converti.
  

Merci pour l'existence de l'option

Il n'est pas nécessaire de l'écrire à nouveau, mais c'est ce que je vais mentionner.
Par rapport à Swift, qui est également utilisé lors de l'écriture d'applications natives, je craignais de devoir faire attention à l'apparition de gluants, mais cela a été résolu. Bien sûr, même en Java, vous pouvez l'éviter en cochant Null ou en utilisant ʻOptional.ofNullable`, mais c'était bien d'avoir un monde où Nullable et NotNull sont clairement séparés.

J'aime écrire la «garde» de Swift comme utiliser l'opérateur Elvis.

sample.kt

val str: String = optionalStr ?: return

Afin de ne pas effacer la bonté de l'option, il faut également faire attention du côté Java

Lorsqu'il s'agit d'un projet dans lequel Java et Kotlin sont mélangés, il y a bien sûr des cas où Kotlin appelle du code Java. Dans un tel cas, si vous ajoutez une annotation côté Java, les restrictions optionnelles de Kotlin entreront en vigueur.

Par exemple, supposons que vous ayez le code suivant du côté Java.

AppUtil.java

public class AppUtil {
    public static String getVersion() {
        return "1.0";
    }
}

Lorsqu'elle est appelée du côté Kotlin, la valeur de retour de ʻAppUtil.getVersion () sera String! , Et les deux String et String? Seront autorisés. Si vous entrez par inadvertance même s'il est nul, vous reviendrez à l'ère gluante. Cela perdra son caractère, alors ajoutez l'annotation @ NonNull ou @ Nullable` à la méthode côté Java. L'EDI va maintenant déduire que le type de retour est «String» ou «String?».

l'extension est pratique

Vous pouvez créer de nouvelles méthodes et propriétés dans des classes existantes. Quand j'écrivais en Java, ce n'était pas pratique de ne pas avoir cela par rapport à Swift. (Pour y parvenir, il y avait pas mal de méthodes statiques de classes comme HogeUtil)

Extension.kt

fun Button.disableTouch() {
    alpha = 0.5f
    isEnabled = false
}

Ce qui précède est un exemple d'ajout d'une méthode à ʻandroid.widget.Button`.

Méthodes statiques et variables statiques en Java, etc.

Les méthodes et propriétés statiques que j'utilise souvent n'existent pas dans Kotlin. Par exemple, comment exprimer une méthode de fabrique comme public static HogeFragment newInstance (...) {...} que j'écrivais habituellement dans le fichier fragment est d'utiliser l'objet compagnon comme l'une des solutions. Il y a une main.

HogeFragment.kt

class HogeFragment : Fragment() {
    companion object {
        fun newInstance(...): HogeFragment {
            ...
        }
    }
}

• Cependant, si cela reste tel quel, il devra s'appeler HogeFragment.Companion.newInstance (...) lors d'un appel depuis Java, ce qui est un peu maladroit. Si vous voulez appeler HogeFragment.newInstance (...) comme vous l'avez fait en Java, ajoutez l'annotation @ JvmStatic à la méthode.
  

HogeFragment.kt

companion object {
    @JvmStatic
    fun newInstance(...): HogeFragment {
        ...
    }
}

D'autre part, pour exprimer des méthodes statiques (choses médiocres), vous pouvez également utiliser les fonctions de niveau supérieur du fichier.

HogeFragment.kt

fun topLevelFun(...) {
    ...
}
 
class HogeFragment : Fragment() {
    ...
}

Je me demandais si la première méthode (celle qui utilise Companion Object) est fondamentalement bonne car elle peut être appelée de la même manière qu'en Java et il n'y a pas besoin de s'inquiéter des conflits de noms. Cependant, j'ai récemment lu les blogs suivants, etc., et j'ai appris d'une manière ou d'une autre avec une image de la façon de les utiliser correctement. companion object vs. top-level - hydrakecat’s blog

La même chose est vraie pour les variables statiques, l'une consiste à déclarer des propriétés dans l'objet compagnon et l'autre à les déclarer au niveau supérieur. (Pour le premier, si vous ajoutez @ JvmField, vous pouvez l'appeler de la même manière qu'en Java.)

fin

Donc, je n'ai pas encore commencé à l'utiliser, mais j'ai écrit un peu sur ce que j'ai ressenti quand j'ai écrit Kotlin.
En plus de ce que j'ai écrit ci-dessus, je suis également heureux qu'il ait une sensation d'écriture similaire à Swift et que la quantité de code soit réduite par rapport à Java. Je pense qu'il peut être utilisé côté serveur.

[PR] Recherche d'amis

Nous recherchons des amis pour écrire ensemble Kotlin, Swift, Rails et Python chez Atlae! https://www.green-japan.com/company/172