Ekspektasi seputar pengembangan UI telah berkembang. Saat ini, kami tidak dapat membuat aplikasi dan memenuhi kebutuhan pengguna tanpa antarmuka pengguna yang disempurnakan termasuk animasi dan gerakan. Persyaratan ini adalah hal-hal yang tidak ada saat Toolkit UI saat ini dibuat. Untuk mengatasi tantangan teknis dalam membuat UI yang dipoles dengan cepat dan efisien, kami telah memperkenalkan Jetpack Compose, toolkit UI modern yang menyiapkan pengembang aplikasi untuk sukses di lanskap baru ini.

Lebih dari dua posting kami akan menjelaskan manfaat Compose dan melihat cara kerjanya di bawah tenda. Untuk memulai, dalam posting ini, saya membahas tantangan yang dihadapi Compose, alasan di balik beberapa keputusan desain kami, dan bagaimana hal itu membantu pengembang aplikasi. Juga, saya akan membahas model mental Compose, bagaimana Anda harus memikirkan kode yang Anda tulis di Compose, dan bagaimana Anda harus membentuk API Anda.

Tantangan apa yang ditangani Compose?

Pemisahan masalah adalah prinsip desain perangkat lunak yang terkenal. Ini adalah salah satu hal mendasar yang kami pelajari sebagai pengembang aplikasi. Meskipun terkenal, seringkali sulit untuk memahami apakah prinsip ini diikuti atau tidak dalam praktik. Akan sangat membantu untuk memikirkan prinsip ini dalam istilah "Coupling" dan "Cohesion".

Saat kita menulis kode, kita membuat modul yang terdiri dari beberapa unit. Kopel adalah ketergantungan antar unit dalam modul yang berbeda dan mencerminkan cara bagian dari satu modul mempengaruhi bagian dari modul lainnya. Kohesi sebagai gantinya adalah hubungan antara unit-unit dalam modul, dan menunjukkan seberapa baik pengelompokan unit-unit dalam modul tersebut.

Saat menulis perangkat lunak yang dapat dipelihara, tujuan kami adalah meminimalkan sambungan dan memaksimalkan kohesi .

Ketika kita memiliki modul yang sangat berpasangan, membuat perubahan pada kode di satu tempat berarti harus membuat banyak perubahan lain pada modul lain. Lebih buruk lagi, kopling sering kali dapat tersirat sehingga hal-hal yang tidak terduga rusak karena perubahan yang tampaknya sama sekali tidak terkait.

Pemisahan masalah adalah tentang mengelompokkan sebanyak mungkin kode terkait sehingga kode kita dapat dengan mudah dipelihara dan diskalakan seiring pertumbuhan aplikasi.

Mari kita lihat ini secara lebih praktis dalam konteks pengembangan Android hari ini dan ambil contoh model tampilan dan tata letak XML.

Model tampilan menyediakan data ke tata letak. Ternyata ada banyak dependensi yang tersembunyi di sini: banyak sambungan antara model tampilan dan tata letak. Salah satu cara yang lebih umum Anda dapat melihat manifes ini adalah melalui API yang memerlukan sejumlah pengetahuan tentang bentuk dan konten tata letak XML itu sendiri, seperti findViewByID.

Menggunakan API ini memerlukan pengetahuan tentang bagaimana tata letak XML didefinisikan dan membuat sambungan di antara keduanya. Seiring pertumbuhan aplikasi kami dari waktu ke waktu, kami harus memastikan bahwa tidak satu pun dari dependensi ini menjadi usang.

Sebagian besar aplikasi modern menampilkan UI secara dinamis dan berkembang selama eksekusinya. Akibatnya, seseorang tidak hanya perlu memverifikasi bahwa dependensi ini dipenuhi oleh layout XML secara statis, tetapi juga akan dipenuhi untuk masa pakai program. Jika sebuah elemen meninggalkan hierarki tampilan saat runtime, beberapa dependensi ini mungkin rusak dan dapat menyebabkan masalah seperti NulReferenceExceptions.

Biasanya model tampilan didefinisikan dalam bahasa pemrograman seperti Kotlin dan tata letak dalam XML. Karena perbedaan bahasa ini, ada garis pemisah yang dipaksakan, meskipun model tampilan dan XML tata letak terkadang dapat terkait erat. Dengan kata lain, mereka sangat erat digabungkan.

Ini menimbulkan pertanyaan: Bagaimana jika kita mulai mendefinisikan tata letak, struktur UI kita, dalam bahasa yang sama? Bagaimana jika kita memilih Kotlin?

Karena kita kemudian akan bekerja dalam bahasa yang sama, beberapa dependensi yang sebelumnya implisit mungkin mulai menjadi lebih eksplisit. Kami juga dapat memfaktorkan ulang kode dan memindahkan sesuatu ke tempat yang akan mengurangi kopling dan meningkatkan kohesi.

Sekarang, Anda mungkin berpikir bahwa ini menyarankan agar Anda mencampur logika dengan UI. Kenyataannya adalah Anda akan memiliki logika terkait UI dalam aplikasi Anda, tidak peduli bagaimana strukturnya. Kerangka itu sendiri tidak dapat mengubah ini.

Tetapi apa yang dapat dilakukan kerangka kerja adalah memberi Anda alat untuk membuat pemisahan lebih mudah: alat itu adalah fungsi yang Dapat Disusun. Fungsi adalah sesuatu yang mungkin sudah lama Anda gunakan untuk memisahkan masalah di tempat lain dalam kode Anda. Keterampilan yang Anda peroleh untuk melakukan jenis pemfaktoran ulang dan menulis kode yang andal, dapat dipelihara, dan bersih — keterampilan yang sama berlaku untuk fungsi yang Dapat Disusun.