Ini adalah seri artikel MAD Skills tentang Hilt! Dalam artikel ini, kita akan melihat mengapa injeksi dependensi (DI) sangatlah penting untuk aplikasi dan Hilt, yaitu solusi yang direkomendasikan Jetpack untuk DI di Android.
Jika Anda lebih menyukai konten ini dalam format video, lihat di sini:
Dengan mengikuti prinsip injeksi dependensi di aplikasi Android, Anda meletakkan dasar untuk arsitektur aplikasi yang baik. Hal ini membantu dalam penggunaan kembali kode, kemudahan pemfaktoran ulang, dan kemudahan pengujian! Pelajari lebih lanjut tentang manfaat DI di sini.
Saat membuat instance class dalam proyek, Anda bisa menggunakan grafik dependensi secara manual dengan memenuhi dependensi dan dependensi transitif yang dibutuhkan class.
Namun melakukannya secara manual setiap saat bisa menyebabkan kode boilerplate dan rawan error. Lihat contohnya, salah satu ViewModels yang kami miliki di iosched, aplikasi Google I/O open source. Dapatkah Anda membayangkan jumlah kode yang diperlukan untuk membuat FeedViewModel dengan dependensi dan dependensi transitifnya?
Ini bukanlah hal yang mudah, repetitif, dan kita bisa saja mendapatkan dependensi yang salah. Dengan menggunakan library injeksi dependensi, kita bisa mendapatkan manfaat DI tanpa harus menyediakan dependensi secara manual, karena library membuatkan semua kode yang diperlukan. Dan di sinilah Hilt berperan.
Hilt adalah library injeksi dependensi yang dikembangkan oleh Google untuk membantu Anda mendapatkan hasil maksimal dari praktik terbaik DI di aplikasi dengan melakukan semua kerja keras dan membuat semua boilerplate yang Anda perlukan.
Dengan menggunakan anotasi, Hilt membuatkan kode tersebut pada waktu kompilasi, sehingga membuatnya sangat cepat saat runtime. Hal ini dilakukan dengan menggunakan kekuatan Dagger, library DI JVM, dan Hilt dibangun di atasnya.
Hilt adalah solusi DI yang direkomendasikan Jetpack untuk aplikasi Android dan dilengkapi dengan fitur dan dukungan library Jetpack lainnya.
Semua aplikasi yang menggunakan Hilt harus berisi class Application yang dianotasikan dengan @HiltAndroidApp karena ini memicu pembuatan kode Hilt pada waktu kompilasi. Dan agar Hilt dapat memasukkan dependensi ke dalam aktivitas, aktivitas tersebut harus dianotasikan dengan @AndroidEntryPoint.
Untuk memasukkan dependensi, anotasikan variabel yang ingin dimasukkan dengan Hilt menggunakan @Inject. Semua variabel yang dimasukkan Hilt akan tersedia saat super.onCreate dipanggil.
Dalam contoh ini, kami memasukkan MusicPlayer ke dalam PlayActivity. Namun bagaimana Hilt tahu cara menyediakan instance tipe MusicPlayer? Yah, saat ini Hilt belum tahu caranya! Kita perlu memberi tahu Hilt cara melakukannya… dengan anotasi! tentu saja.
Menganotasikan konstruktor class dengan @Inject akan memberi tahu Hilt cara membuat instance class tersebut.
Hanya ini yang dibutuhkan untuk memasukkan dependensi ke dalam Activity! Cukup mudah! Kita mulai dengan contoh sederhana karena MusicPlayer tidak bergantung pada tipe lainnya. Namun jika kita memiliki dependensi lain yang diteruskan sebagai parameter, Hilt akan menanganinya dan memenuhi dependensi tersebut saat menyediakan instance MusicPlayer.
Ini sebenarnya, contoh yang sangat sederhana dan mudah. Namun jika Anda harus melakukan apa yang telah kami lakukan sejauh ini secara manual, bagaimana Anda akan melakukannya?
Saat melakukan DI secara manual, Anda bisa memiliki class container Dependensi yang bertanggung jawab untuk menyediakan tipe, dan mengelola siklus proses instance yang disediakannya. Kami menyederhanakannya sedikit di sini, itulah yang dilakukan Hilt di balik prosesnya!
Saat Anda memberikan anotasi pada Activity dengan @AndroidEntryPoint, container dependensi secara otomatis dibuat, dikelola, dan dikaitkan dengan PlayActivity. Mari kita panggil implementasi manualnya, PlayActivityContainer. Dengan menganotasikan MusicPlayer dengan @Inject, pada dasarnya kita memberi tahu container cara menyediakan instance tipe MusicPlayer.
Dan dalam Activity, kita perlu membuat instance container, dan mengisi dependensi aktivitas yang menggunakannya. Hal ini juga dilakukan oleh Hilt saat menganotasikan aktivitas dengan @AndroidEntryPoint.
Sejauh ini, kita melihat bahwa ketika @Inject digunakan untuk menganotasikan konstruktor class, ia memberi tahu Hilt cara menyediakan instance class tersebut. Dan saat menganotasikan variabel di class beranotasi @AndroidEntryPoint, Hilt memasukkan instance tipe tersebut ke dalam class.
@AndroidEntryPoint, yang bisa menganotasikan sebagian besar class framework Android, tidak hanya aktivitas, membuat instance container dependensi untuk class tersebut dan mengisi semua variabel beranotasi @Inject.
@HiltAndroidApp menganotasikan class Application, dan selain memicu pembuatan kode Hilt, juga membuat container dependensi yang terkait dengan class Application.
Setelah membahas dasar-dasar Hilt, mari kita perumit contohnya. Sekarang, MusicPlayer menggunakan dependensi dalam konstruktornya, MusicDatabase.
Oleh karena itu, kita harus memberi tahu Hilt cara menyediakan instance MusicDatabase. Jika tipenya adalah antarmuka atau Anda bukan pemilik class karena asalnya dari library, misalnya, Anda tidak bisa menganotasikan konstruktornya dengan @Inject!
Mari kita bayangkan menggunakan Room sebagai library persistensi di aplikasi. Kembali ke implementasi manual PlayActivityContainer, saat menyediakan MusicDatabase, dengan Room ini menjadi class abstrak, kita akan menjalankan beberapa kode saat menyediakan dependensi. Kemudian, saat menyediakan instance MusicPlayer, kita harus memanggil metode yang menyediakan atau memenuhi dependensi MusicDatabase.
Kita tidak perlu mengkhawatirkan dependensi transitif di Hilt, karena Hilt menghubungkan semua dependensi transitif secara otomatis. Namun, kita harus memberi tahu cara menyediakan instance tipe MusicDatabase. Untuk itu, kita menggunakan modul Hilt.
Modul Hilt adalah class yang dianotasikan dengan @Module. Dan di dalam class, kita bisa memiliki fungsi yang memberi tahu Hilt cara menyediakan instance tipe tertentu. Informasi ini juga dikenal oleh Hilt dengan sebutan binding dalam jargon Hilt.
Fungsi yang dianotasikan dengan @Provides memberi tahu Hilt cara menyediakan instance tipe MusicDatabase. Body berisi blok kode yang perlu dieksekusi Hilt, dan ini persis sama seperti yang dilakukan dalam implementasi manual kami.
Jenis nilai yang ditampilkan, MusicDatabase, menginformasikan Hilt tentang tipe yang disediakan fungsi ini. Dan parameter fungsi memberi tahu Hilt dependensi dari tipe yang sesuai, dalam hal ini, ApplicationContext yang sudah tersedia di Hilt. Kode tersebut memberi tahu Hilt cara menyediakan instance tipe MusicDatabase, atau dengan kata lain, kita memiliki binding untuk MusicDatabase.
Modul Hilt juga dianotasikan dengan anotasi @InstallIn yang menunjukkan container dependensi atau komponen letak informasi ini. Namun apa yang dimaksud dengan komponen? Mari kita bahas ini secara lebih detail.
Komponen adalah class yang dihasilkan Hilt yang bertanggung jawab untuk menyediakan instance tipe, seperti container yang telah kita program secara manual. Pada waktu kompilasi, Hilt melintasi grafik dependensi aplikasi Anda dan menghasilkan kode untuk menyediakan semua tipe dengan dependensi transitifnya.
Hilt menghasilkan Komponen, atau container dependensi, untuk sebagian besar class framework Android. Informasi, atau binding, dari setiap komponen disebarluaskan melalui hierarki komponen.
Jika binding MusicDatabase tersedia di SingletonComponent, yang sesuai dengan class Application, ia juga akan tersedia di komponen lainnya.
Komponen ini dihasilkan secara otomatis oleh Hilt pada waktu kompilasi, dan dibuat, dikelola, serta dihubungkan dengan class framework Android yang sesuai saat Anda menganotasikan class tersebut dengan @AndroidEntryPoint.
Anotasi @InstallIn untuk modul berguna mengontrol tempat menyediakan binding tersebut dan binding lain yang bisa mereka gunakan.
Kembali ke kode PlayActivityContainer yang kami buat secara manual, saya tidak yakin apakah Anda menyadarinya, tetapi setiap kali dependensi MusicDatabase dibutuhkan, kami membuat instance yang berbeda.
Ini tidak ideal karena kami mungkin ingin menggunakan kembali instance MusicDatabase yang sama di seluruh aplikasi. Sebagai ganti fungsi, kita bisa berbagi instance yang sama dengan menyimpannya semua dalam sebuah variabel.
Pada dasarnya, kami memasukkan tipe MusicDatabase ke container ini karena kami selalu menyediakan instance yang sama sebagai dependensi. Bagaimana cara melakukannya dengan Hilt? Yah, tidak ada kejutan di sini... Dengan anotasi yang lain!
Dengan anotasi @Singleton dalam metode @Provides, kita memberi tahu Hilt untuk selalu membagikan instance yang sama dari tipe ini dalam komponen tersebut.
@Singleton adalah anotasi cakupan. Dan setiap komponen Hilt memiliki anotasi cakupan yang terkait.
Jika Anda ingin cakupan tipe ke ActivityComponent, Anda harus menggunakan anotasi ActivityScoped. Anotasi ini bisa digunakan di Modul, tetapi juga dapat menganotasikan class yang konstruktornya dianotasikan dengan @Inject.
Ada dua tipe binding:
Hilt menawarkan integrasi dengan library Jetpack terpopuler: ViewModel, Navigation, Compose, dan WorkManager.
Selain ViewModel, setiap integrasi memerlukan library yang berbeda untuk ditambahkan ke proyek Anda. Lihat dokumentasi untuk informasi selengkapnya tentang hal ini. Apakah Anda ingat kode FeedViewModel dari iosched yang kita lihat di awal postingan blog ini? Ingin melihat tampilannya dengan dukungan Hilt?
Selain menganotasikan konstruktor dengan @Inject, untuk memberi tahu Hilt cara menyediakan instance ViewModel ini, kita perlu menganotasikan class dengan @HiltViewModel.
Itu saja! Anda tidak perlu secara manual membuat penyedia ViewModel untuk hal ini, Hilt akan menanganinya.
Hilt dibangun di atas library injeksi dependensi populer lainnya: Dagger! Dagger akan sering disebut dalam episode berikutnya! Jika Anda menggunakan Dagger, Dagger dan Hilt bisa bekerja sama. Baca selengkapnya tentang API migrasi di panduan.
Untuk informasi lebih lanjut tentang Hilt, kami memiliki tips praktis dengan anotasi terpopuler, apa yang dilakukannya, dan cara menggunakannya. Selain dokumen di Hilt, kami juga memiliki codelab untuk belajar praktik langsung.
Dan itu saja untuk episode ini! Namun ini tidak berakhir di sini! Kami punya lebih banyak episode MAD skills yang akan segera hadir, jadi silakan ikuti publikasi Android Developers Medium untuk melihat kapan mereka diposting.
Trackr adalah contoh aplikasi manajemen tugas. Meskipun sering kali digunakan untuk menjelajahi pola UI umum dari perspektif mendukung aksesibilitas, Trackr juga merupakan salah satu contoh kami dalam menunjukkan praktik terbaik pengembangan Android modern. Kami baru saja memaksimalkan aplikasi ini untuk perangkat berlayar besar, jadi mari kita lihat bagaimana penerapan Desain Material dan pola responsif menghasilkan pengalaman pengguna yang lebih mulus dan intuitif di perangkat berlayar besar.
Sebelum: Dari layar Tasks, Anda bisa mengakses Archive dan Settings dari menu di panel aplikasi bawah. Pada perangkat berlayar besar, kontrol menu berupa target sentuh kecil di tempat yang sulit diakses, dan panel aplikasi bawah terlalu melebar.
Setelah: Saat ukuran layar lebih lebar, kami menampilkan rel navigasi sebagai gantinya. Kami juga menempatkan tombol tindakan mengambang (FAB) (yang membuka layar New Task) di rel navigasi dan menghapus panel aplikasi bawah seluruhnya.
Meskipun perubahan ini dilakukan dengan mempertimbangkan perangkat yang lebih besar, perubahan ini juga berguna untuk ponsel dalam mode lanskap karena ada lebih banyak ruang vertikal untuk melihat daftar tugas.
Sebelum: Layar Tasks dan layar Archive memanfaatkan lebar tampilan penuh, dan mengetuk item akan menggantikan daftar dengan detail item itu. Pada perangkat berlayar besar, elemen UI dilebarkan atau dikelompokkan ke satu sisi, dan layarnya terasa tidak seimbang.
Setelah: Baik layar Tasks dan layar Archive menunjukkan daftar/detail UI menggunakan SlidingPaneLayout. Kami menulis caranya di artikel sebelumnya tentang perubahan yang kami buat untuk aplikasi Google I/O, jadi lihatlah artikel tersebut jika Anda tertarik dengan detail teknisnya.
Layar Task Detail juga memiliki tombol tindakan mengambang (yang membuka layar Edit Task), tetapi jika rel navigasi terlihat, ini akan menyebabkan dua tombol tindakan mengambang (FAB), yang tidak ideal. Sebagai gantinya, kami menyembunyikan tombol tindakan mengambang (FAB) kedua dan menambahkan tombol edit ke toolbar di kanan atas
Sebelum: Saat Anda mengedit tugas, UI Edit Task menggantikan Task Detail dan menempati seluruh layar. Seperti halnya Task Detail, layar ini terasa tidak seimbang. UI New Task juga memiliki masalah yang sama (bahkan, New Task dan Edit Task sebenarnya adalah destinasi yang sama di grafik navigasi kami).
Setelah: Di perangkat berlayar besar, kami menggunakan DialogFragment sehingga UI Edit Task mengambang di atas konten lainnya.
Awalnya kami mencoba menampilkan UI ini di panel detail dengan mengganti Task Detail. Meskipun mudah, kami segera merasa tidak puas dengan pendekatan tersebut karena beberapa alasan:
Hal menarik di sini adalah desain yang paling sederhana bisa memiliki celah fungsionalitas saat Anda mencobanya di perangkat. Bila itu terjadi, mundurlah selangkah untuk fokus pada pengalaman pengguna, dan cari pola desain untuk memfasilitasinya.
Dengan meningkatnya popularitas tablet dan perangkat foldable, sekarang membuat UI yang responsif semakin penting daripada sebelumnya. Kami menunjukkan bagaimana menambahkan rel navigasi dan menggunakan SlidingPaneLayout tidak hanya membuat aplikasi Trackr terlihat lebih baik, tetapi juga secara drastis meningkatkan kegunaan dan menciptakan pengalaman yang tidak bisa didapat di ponsel. Kami juga menunjukkan bagaimana terkadang Anda harus memikirkan kembali desain seputar kegunaan, bukan hanya ruang layar, untuk memenuhi kebutuhan pengguna.
Kami harap Anda menyukai Trackr baru yang disempurnakan! Lihat kodenya di github.com/android/trackr.
Diposting oleh Jacob Lehrbaum Director of Developer Relations, Android
Pengalaman aplikasi yang bagus cocok untuk bisnis. Faktanya, hampir tiga perempat pengguna aplikasi Android yang memberikan ulasan bintang 5 di Google Play menyebutkan kualitas pengalaman mereka dengan aplikasi tersebut.1; kecepatan, desain, dan kegunaannya. Di Google, kami ingin membantu semua developer mencapai keunggulan aplikasi, dan pada gilirannya membantu Anda mendorong akuisisi, retensi, dan monetisasi pengguna.
Jadi apa yang dimaksud dengan “keunggulan aplikasi”? Mungkin terdengar aspiratif, tetapi sebenarnya dapat diraih oleh banyak aplikasi. Semua dimulai dengan fokus penuh pada pengguna, dan lebih khusus lagi, pada pengalaman pengguna intuitif yang membawa mereka ke fungsionalitas utama aplikasi Anda secepat mungkin — tetapi ini baru permulaan. Aplikasi yang unggul selalu konsisten di semua layar dan pengalamannya. Berjalan dengan baik di perangkat apa pun yang digunakan. Keunggulan aplikasi dapat dicapai bila semua pihak berkepentingan yang memengaruhi aplikasi berinvestasi dalam pengalaman menggunakan aplikasi Anda.
Salah satu hambatan yang menghalangi keunggulan aplikasi adalah akuntabilitas yang terbagi atau tidak jelas. Beberapa ukuran utama kualitas aplikasi, seperti error dan waktu pemuatan, sering kali dianggap sebagai tanggung jawab satu grup di perusahaan, seperti tim teknis. Namun, ketika kami berbicara dengan organisasi terbaik2 tentang bagaimana mereka mencapai kualitas aplikasi, jelas bahwa mengambil pendekatan lintas fungsional adalah kuncinya, dengan tim teknis, desain, produk, dan bisnis bekerja sama menuju tujuan bersama.
Jadi apa saja praktik terbaik internal di balik keunggulan aplikasi?
Percakapan ini jauh lebih mudah bagi saya di tim bisnis karena saya bisa mengatakan “aplikasi kompetitor ini lebih cepat daripada aplikasi kita; kita perlu mengurangi waktu pemuatan dari 5 detik menjadi 4 detik”.
Software engineer, aplikasi x-platform
Keunggulan aplikasi membantu mendorong performa bisnis. Fitur baru memang bagus, tetapi jika memperlambat waktu startup aplikasi atau menghabiskan terlalu banyak ruang perangkat, pengguna pada akhirnya semakin jarang menggunakan aplikasi Anda atau bahkan menghapusnya. Engineer yang membangun fokus seluruh perusahaan pada kualitas sering melakukannya dengan mengukur dampak masalah kualitas pada performa bisnis, melalui:
Perusahaan yang mengatur tim untuk mengelola fitur — atau tahapan dalam perjalanan pengguna — cenderung memberikan pengalaman yang lebih konsisten di setiap sistem operasi yang mereka dukung, menghadirkan aplikasi atau fitur baru ke pasar dengan lebih cepat, dan memberikan pengalaman aplikasi yang lebih baik untuk semua pelanggan mereka. Tim ini sering kali merupakan grup lintas fungsional yang mencakup teknis, pemasaran, pengalaman pengguna, dan produk — serta bertanggung jawab atas keberhasilan suatu fitur atau tahap perjalanan pengguna3 di semua perangkat dan platform. Selain pengalaman yang lebih baik dan kesamaan fitur, struktur ini memungkinkan penyelarasan tujuan di seluruh area fungsional sekaligus mengurangi silo, juga membantu tim untuk berfokus sepenuhnya dalam mencapai tujuan tertentu.
Anggota tim berfokus pada tujuan bisnis untuk meningkatkan fokus pada pengguna.
Jika sebagian besar pengguna menggunakan jenis perangkat tertentu, Anda bisa membangun empati serta merasakan pengalaman mereka jika Anda menggunakan ponsel, tablet, atau smartwatch yang sama sebagai perangkat utama Anda. Hal ini sangat relevan untuk kepemimpinan senior di organisasi Anda yang membuat keputusan yang memengaruhi pengalaman jutaan pengguna sehari-hari. Sebagai contoh, Duolingo telah memasukkan hal ini ke dalam DNA perusahaan mereka. Setiap karyawan Duolingo — termasuk CEO mereka — menggunakan secara eksklusif atau memiliki akses ke perangkat Android berspesifikasi rendah untuk merefleksikan sebagian besar basis pengguna mereka.
Pendekatan yang berpusat pada pengguna terhadap kualitas dan keunggulan aplikasi sangatlah penting untuk pertumbuhan bisnis. Jika Anda tertarik untuk mempelajari cara mencapai keunggulan aplikasi, bacalah studi kasus kami dengan tips praktis, dan daftarkan diri untuk menghadiri App Excellence Summit dengan mengunjungi halaman web keunggulan aplikasi Android.
Dalam postingan blog berikutnya, kami akan menggali lebih dalam mengenai dua pendorong pengalaman aplikasi yang menakjubkan: performa aplikasi dan bagaimana hal itu terkait dengan perilaku pengguna, dan menciptakan pengalaman pengguna yang mulus di semua perangkat. Daftar newsletter developer Android di sini untuk mendapatkan pemberitahuan tentang kabar berikutnya, dan dapatkan berita serta wawasan dari tim Android.
Data internal Google Play, 2021. ↩
Riset Kualitas Aplikasi Google, 2021 ↩
Langkah-langkah yang diambil setiap pengguna saat mereka berinteraksi dengan aplikasi Anda disebut sebagai “perjalanan pengguna”. Contoh tahapan perjalanan pengguna meliputi penginstalan, pengenalan, interaksi, dan retensi ↩
