Kotlin – Android kūrimas

Kodėl Kotlin tapo Android kūrimo standartu

Jei prieš kelerius metus kas nors būtų pasakęs, kad Java Android kūrime bus nustumta į antrą planą, turbūt nedaugelis tuo būtų patikėję. Java dešimtmečius buvo neatsiejama Android ekosistemos dalis – ji buvo visur, nuo paprasčiausių „Hello World” programėlių iki sudėtingų korporacinių sprendimų. Tačiau 2017 metais Google oficialiai paskelbė Kotlin pirmos klasės kalba Android platformai, ir nuo to momento viskas pradėjo keistis gana sparčiai.

Kotlin – tai statiškai tipizuota programavimo kalba, kurią sukūrė JetBrains komanda. Ji veikia ant JVM (Java Virtual Machine), kas reiškia, kad ji puikiai suderama su egzistuojančiu Java kodu – galima turėti projektą, kuriame šios dvi kalbos ramiai sugyvena viename faile. Tai buvo vienas iš pagrindinių veiksnių, kodėl migracija iš Java į Kotlin nebuvo skausminga proceso prasme.

Šiandien Google statistika rodo, kad didžioji dalis naujų Android programėlių rašoma būtent Kotlin kalba. Jei žiūrėtume į Play Store top 1000 programėlių, absoliuti dauguma jų jau turi reikšmingą Kotlin kodo dalį. Tai nėra atsitiktinumas – Kotlin siūlo tai, ko Java tiesiog nesugebėjo pasiūlyti be daugybės boilerplate kodo ir nepatogumų.

Kotlin sintaksė – kuo ji skiriasi nuo to, prie ko esame pripratę

Vienas pirmų dalykų, kurį pastebi pereinantys iš Java, yra tai, kiek mažiau kodo reikia parašyti tam pačiam rezultatui pasiekti. Tai nėra tik estetinis privalumas – mažiau kodo reiškia mažiau galimų klaidų, lengvesnį palaikymą ir greitesnį skaitymą.

Paimkime paprastą pavyzdį. Java duomenų klasė su keliais laukais, getter’iais, setter’iais, equals(), hashCode() ir toString() metodais gali užimti 50-60 eilučių. Kotlin tą patį padaro viena eilute:

data class Vartotojas(val vardas: String, val amžius: Int, val el_paštas: String)

Tai yra data class – vienas iš Kotlin konceptų, kuris iš karto parodo kalbos filosofiją. Kompiliatorius automatiškai sugeneruoja visus reikalingus metodus. Nereikia galvoti, ar nepamirštai perrašyti equals(), kai pridedi naują lauką.

Kitas svarbus aspektas – null safety. Java programuotojai gerai pažįsta NullPointerException – tai buvo viena dažniausių klaidų Android programėlėse. Kotlin šią problemą sprendžia kalbos lygmeniu. Kintamieji pagal nutylėjimą negali būti null:

var vardas: String = "Jonas"  // negali būti null
var pavardė: String? = null   // gali būti null, bet privalai tai eksplicitiškai nurodyti

Kompiliatorius tiesiog neleis kompiliuoti kodo, jei bandysi naudoti potencialiai null reikšmę be atitinkamo patikrinimo. Tai skamba kaip smulkmena, bet praktikoje tai eliminuoja ištisą klaidų kategoriją dar prieš paleidžiant programą.

Extension functions – dar vienas Kotlin bruožas, kurį pamylite greitai. Galima pridėti naujus metodus prie egzistuojančių klasių, net jei neturite prieigos prie jų kodo:

fun String.yraElPaštas(): Boolean {
    return this.contains("@") && this.contains(".")
}

// Naudojimas:
val elPaštas = "[email protected]"
if (elPaštas.yraElPaštas()) { ... }

Android SDK klasės staiga tampa daug patogesnės naudoti, kai galite jas pratęsti pagal savo poreikius.

Coroutines – asinchroninis programavimas be galvos skausmo

Jei yra vienas dalykas, dėl kurio Kotlin Android kūrime tikrai verta rinktis, tai yra coroutines. Asinchroninis programavimas – tai vienas iš tų dalykų, kuris teoriškai skamba paprastai, bet praktikoje gali tapti tikru košmaru.

Android programėlėse nuolat reikia atlikti operacijas fone – krautis duomenis iš serverio, rašyti į duomenų bazę, apdoroti paveikslėlius. Jei visa tai darytum pagrindiniame gijoje (main thread), programėlė tiesiog užšaltų. Java pasaulyje tai sprendė su AsyncTask, Thread, Handler – ir visi šie sprendimai turėjo savo problemų: sudėtingas kodo valdymas, memory leaks, sunkiai sekamas vykdymo srautas.

Coroutines leidžia rašyti asinchroninį kodą taip, lyg jis būtų sinchroninis:

viewModelScope.launch {
    val vartotojai = withContext(Dispatchers.IO) {
        api.gauti Vartotojus()  // šis kvietimas vyksta fono gijoje
    }
    // čia grįžtame į pagrindinę giją
    vartotojuSąrašas.value = vartotojai
}

Kodas atrodo tiesiškai ir lengvai skaitomas, bet po gaubtu viskas vyksta asinchroniškai. withContext(Dispatchers.IO) nurodo, kad ta kodo dalis turi vykti IO gijoje – tinklo ar duomenų bazės operacijoms. Kai ji baigiasi, automatiškai grįžtama į pagrindinę giją UI atnaujinimui.

Svarbu suprasti scope konceptą. viewModelScope – tai coroutine scope, susietas su ViewModel gyvavimo ciklu. Kai ViewModel sunaikinamas (pvz., vartotojas išeina iš ekrano), visos su juo susijusios coroutines automatiškai atšaukiamos. Tai elegantiškai sprendžia memory leak problemą, kuri buvo tokia dažna su senesniais sprendimais.

Praktinis patarimas: pradedant naudoti coroutines, pirmiausia išmok suspend funkcijų konceptą. Suspend funkcija gali „sustabdyti” savo vykdymą nelaukdama ir neblokuodama gijos – tai yra visa coroutines magijos esmė. Bet ji gali būti kviečiama tik iš kitos suspend funkcijos arba coroutine bloko.

Jetpack Compose – UI kūrimas Kotlin stiliumi

Tradicinis Android UI kūrimas su XML layoutais buvo… funkcionalesnis nei gražus. Turėjai XML failą su UI aprašymu, tada Java/Kotlin failą su logika, ir nuolat šokinėjai tarp jų. findViewById() kvietimai, View Binding, Data Binding – kiekvienas sprendimas bandė išspręsti tą pačią problemą: kaip sujungti UI ir logiką kuo skausmingiau.

Jetpack Compose – tai Google atsakas, ir jis yra visiškai Kotlin-first. UI aprašomas Kotlin kodu naudojant composable funkcijas:

@Composable
fun SveikinimoPranešimas(vardas: String) {
    Column(
        modifier = Modifier.padding(16.dp)
    ) {
        Text(
            text = "Sveiki, $vardas!",
            style = MaterialTheme.typography.headlineMedium
        )
        Spacer(modifier = Modifier.height(8.dp))
        Button(onClick = { /* veiksmas */ }) {
            Text("Spausk mane")
        }
    }
}

Composable funkcijos yra deklaratyvios – aprašai, kaip UI turi atrodyti tam tikroje būsenoje, o Compose pasirūpina, kad ekranas atitiktų tą aprašymą. Kai būsena keičiasi, Compose automatiškai perkuria tik tuos UI elementus, kuriems tai turi įtakos.

Tai yra fundamentalus mąstymo pokytis. Vietoj to, kad rankiniu būdu atnaujintum UI elementus („surask šį TextView ir pakeisk jo tekstą”), aprašai UI kaip būsenos funkciją. Jei būsena pasikeitė – UI automatiškai atsinaujins.

Compose ir Kotlin derinys yra ypač galingas dėl to, kad gali naudoti visas Kotlin galimybes tiesiai UI kode – lambda funkcijas, extension functions, coroutines. Nereikia mokytis atskiros XML sintaksės ar specialių data binding išraiškų.

Praktinė rekomendacija: jei pradedate naują projektą šiandien, tikrai verta rinktis Compose. Jei turite esamą projektą su XML layoutais – migracija gali būti laipsniška, nes Compose ir tradicinis View sistema gali egzistuoti viename projekte.

Android Architecture Components ir Kotlin

Geras Android programėlės architektūros pasirinkimas yra toks dalykas, kuris pradžioje gali atrodyti perteklinis, bet po kelių mėnesių palaikymo suprantate, kodėl tai buvo svarbu. Google rekomenduoja MVVM (Model-View-ViewModel) architektūrą, ir Kotlin su Jetpack komponentais ją padaro gana natūralią.

ViewModel – tai komponentas, kuris išgyvena konfigūracijos pakeitimus (pvz., ekrano pasukimą). Tai buvo klasikinė Android problema: pasuki telefoną, Activity perkuriama, ir visi tavo duomenys dingsta. ViewModel sprendžia tai:

class VartotojuViewModel(private val saugykla: VartotojuSaugykla) : ViewModel() {
    
    private val _vartotojai = MutableStateFlow>(emptyList())
    val vartotojai: StateFlow> = _vartotojai.asStateFlow()
    
    fun įkeltiVartotojus() {
        viewModelScope.launch {
            _vartotojai.value = saugykla.gauti Vartotojus()
        }
    }
}

Čia matome StateFlow – tai Kotlin Flow bibliotekos dalis, kuri leidžia reaktyviai stebėti duomenų pokyčius. UI gali „prenumeruoti” šį srautą ir automatiškai atsinaujinti, kai duomenys keičiasi.

Room – tai SQLite abstrakcija, kuri su Kotlin tampa ypač patogi. Duomenų bazės operacijos gali būti suspend funkcijos, kas leidžia jas lengvai naudoti su coroutines:

@Dao
interface VartotojuDao {
    @Query("SELECT * FROM vartotojai")
    suspend fun gauti Visus(): List
    
    @Insert
    suspend fun įterpti(vartotojas: Vartotojas)
    
    @Query("SELECT * FROM vartotojai")
    fun stebėtiVisus(): Flow>
}

stebėtiVisus() grąžina Flow – tai reiškia, kad kiekvieną kartą, kai duomenų bazėje pasikeičia vartotojų sąrašas, UI automatiškai gaus atnaujintus duomenis. Tai yra reaktyvus programavimas, ir su Kotlin jis atrodo natūraliai.

Dependency Injection su Hilt (kuris yra pastatytas ant Dagger) taip pat puikiai integruojasi su Kotlin. Anotacijos kaip @HiltViewModel, @Inject, @Module leidžia aprašyti priklausomybes deklaratyviai, o Hilt pasirūpina jų sukūrimu ir gyvavimo ciklo valdymu.

Testavimas Kotlin aplinkoje

Testavimas yra ta tema, apie kurią visi žino, kad svarbu, bet ne visi tai daro sistemingai. Kotlin čia taip pat turi ką pasiūlyti, ir tai nėra tik sintaksinis cukrus.

Unit testai su JUnit ir Mockk (Kotlin-first mocking biblioteka) atrodo gana skaitomi:

@Test
fun `kai vartotojas nerastas, grąžinamas null`() = runTest {
    // Arrange
    val saugykla = mockk()
    coEvery { saugykla.rasti(any()) } returns null
    val viewModel = VartotojuViewModel(saugykla)
    
    // Act
    viewModel.ieškotiVartotojo("[email protected]")
    
    // Assert
    assertNull(viewModel.rastas Vartotojas.value)
}

Atkreipkite dėmesį į backtick sintaksę testo pavadinimui – tai Kotlin leidžia naudoti bet kokį tekstą kaip funkcijos pavadinimą, kas testams yra labai patogu. Testo pavadinimas gali būti pilnas sakinys, aprašantis, ką testas tikrina.

runTest – tai coroutines testavimo bibliotekos funkcija, kuri leidžia testuoti suspend funkcijas sinchroniškai. coEvery – tai Mockk sintaksė suspend funkcijų mockavimui.

UI testams su Compose yra Compose Testing biblioteka, kuri leidžia testuoti composable funkcijas izoliuotai:

@Test
fun sveikinamasPranešimasRodoVardą() {
    composeTestRule.setContent {
        SveikinimoPranešimas(vardas = "Jonas")
    }
    
    composeTestRule
        .onNodeWithText("Sveiki, Jonas!")
        .assertIsDisplayed()
}

Praktinis patarimas dėl testavimo strategijos: pradėkite nuo ViewModel testavimo. Tai yra geriausias investicijų ir naudos santykis – ViewModel turi logiką, bet nereikia Android aplinkos (galima testuoti su paprastu JUnit). UI testai yra lėtesni ir trapesni, todėl jų turėkite mažiau, bet jie turėtų tikrinti kritinius vartotojo kelius.

Dažniausios klaidos ir kaip jų išvengti

Pereinant prie Kotlin, ypač iš Java, yra keletas klaidų, kurias daro beveik visi. Geriau apie jas žinoti iš anksto.

Piktnaudžiavimas !! operatoriumi. Tai yra „not-null assertion” – tu sakei kompiliatoriui „pasitikėk manimi, čia tikrai nėra null”. Jei klysti – gauni NullPointerException. Tai yra Kotlin null safety apėjimas, ir tai dažnai reiškia, kad kažkas negerai su kodo dizainu. Vietoj to naudok ?. (safe call), ?: (Elvis operatorius) arba let bloką:

// Blogai:
val ilgis = tekstas!!.length

// Geriau:
val ilgis = tekstas?.length ?: 0

// Arba:
tekstas?.let { 
    // čia tekstas tikrai nėra null
    println(it.length) 
}

Coroutines paleidimas iš netinkamos vietos. Dažna klaida – paleisti coroutine iš Activity ar Fragment tiesiogiai, nenaudojant lifecycle-aware scope. Tai gali sukelti memory leaks. Naudok viewModelScope ViewModel viduje arba lifecycleScope Activity/Fragment viduje.

Neefektyvus Compose rekomposicijų valdymas. Compose yra protingas, bet ne visagalis. Jei perduodi lambda funkciją kaip parametrą composable funkcijai, kiekvieną kartą bus sukuriamas naujas objektas, kas gali sukelti nereikalingas rekomposicijas. Naudok remember ir rememberUpdatedState ten, kur reikia:

@Composable
fun ManoKomponentas(onSpustelėjimas: () -> Unit) {
    val atmintas Veiksmas = rememberUpdatedState(onSpustelėjimas)
    Button(onClick = { atmintas Veiksmas.value() }) {
        Text("Spausk")
    }
}

Ignoruojami sealed class galimybės. Kotlin sealed class yra puikus būdas modeliuoti baigtinę būsenų aibę. UI būsenos modeliavimui tai yra labai tinkama:

sealed class UiBūsena {
    object Kraunama : UiBūsena()
    data class Sėkmė(val duomenys: List) : UiBūsena()
    data class Klaida(val pranešimas: String) : UiBūsena()
}

Tada when išraiška su sealed class yra išsami – kompiliatorius žino visas galimas reikšmes ir perspės, jei kurią nors praleisi.

Kotlin Android kūrime – kur viskas juda

Kotlin ekosistema nestovi vietoje. Kiekvienais metais atsiranda naujų galimybių, ir verta žinoti, kur viskas juda, kad galėtum priimti geresnius sprendimus šiandien.

Kotlin Multiplatform (KMP) – tai galbūt didžiausia tendencija artimiausiais metais. KMP leidžia dalintis Kotlin kodu tarp Android, iOS, web ir desktop platformų. Tai nėra tas pats, kas React Native ar Flutter – čia nekuriamas bendras UI, o dalijamasi verslo logika, tinklo sluoksniu, duomenų bazės operacijomis. UI kiekvienoje platformoje rašomas natyviai. Tai reiškia, kad galima turėti vieną VartotojuSaugykla klasę, kuri veikia tiek Android, tiek iOS.

Google ir JetBrains investicijos į KMP auga, ir jau dabar nemažai kompanijų tai naudoja produkcijoje. Jei kuriate produktą kelioms platformoms, verta rimtai apsvarstyti šią galimybę.

Kotlin Symbol Processing (KSP) keičia seną KAPT (Kotlin Annotation Processing Tool). KSP yra greitesnis, geriau supranta Kotlin tipus ir tampa standartu naujoms bibliotekoms. Room, Hilt ir kitos pagrindinės bibliotekos jau palaiko KSP. Jei dar naudoji KAPT – verta migruoti, kompiliavimo laikas gerokai sumažėja.

Compose toliau evoliucionuoja – atsiranda Compose Multiplatform, kuris leidžia naudoti tą patį Compose UI kodą keliose platformose. Tai dar eksperimentinė sritis, bet kryptis aiški.

Galiausiai – Kotlin kalbos raida. K2 kompiliatorius, kuris tapo stabilus su Kotlin 2.0, žymiai pagerina kompiliavimo greitį ir suteikia geresnę IDE palaikymą. Tai ne tik techninis patobulinimas – greitesnis kompiliavimas reiškia greitesnį development ciklą, kas kasdieniniame darbe yra labai juntama.

Jei šiandien pradedate mokytis Android kūrimo – Kotlin yra vienintelis logiškas pasirinkimas. Jei turite esamą Java projektą – migracija gali būti laipsniška, ir net dalinė migracija atneša naudos. Kotlin nėra tik „nauja Java” – tai kalbos, kuri buvo suprojektuota mokantis iš Java klaidų, ir tai jaučiasi kiekvieną dieną dirbant su ja. Ekosistema yra brandi, bendruomenė aktyvi, o Google investicijos rodo, kad tai nėra trumpalaikė mada – tai Android kūrimo ateitis.