Diposting oleh Peter Visontay, Software Engineer; Bessie Jiang, Software Engineer
Kontributor: Inara Ramji, Software Engineer; Rodrigo Farell, Interaction Designer; James Kelly, Product Manager; Henry Chin, Program Manager.
Banyak pengguna menghabiskan waktu di smartphone mereka. Baik untuk bekerja, bermain game, atau terhubung dengan teman, orang sering menggunakan aplikasi sebagai gateway utama kehidupan digitalnya. Agar berfungsi, aplikasi sering kali perlu meminta izin tertentu, tetapi dengan banyaknya aplikasi pada sebuah perangkat, tidaklah mudah selalu mengontrol izin yang telah Anda berikan sebelumnya – terutama jika Anda sudah lama tidak menggunakan aplikasi.
Di Android 11, kami memperkenalkan fitur reset otomatis izin. Fitur ini membantu melindungi privasi pengguna dengan mereset izin runtime aplikasi secara otomatis – yaitu izin yang menampilkan peringatan kepada pengguna saat diminta – jika aplikasi tidak digunakan selama beberapa bulan. Mulai Desember 2021, kami memperluasnya ke miliaran perangkat lainnya. Fitur ini akan diaktifkan secara otomatis di perangkat dengan layanan Google Play yang menjalankan Android 6.0 (API level 23) atau yang lebih tinggi.
Fitur ini akan diaktifkan secara default untuk aplikasi yang menargetkan Android 11 (API level 30) atau yang lebih tinggi. Namun, pengguna bisa mengaktifkan reset otomatis izin secara manual untuk aplikasi yang menargetkan API level 23 hingga 29.
Jadi apa artinya ini bagi developer?
Beberapa aplikasi dan izin secara otomatis dikecualikan dari pembatalan, seperti aplikasi Device Administrator aktif yang digunakan oleh perusahaan, dan izin yang ditetapkan oleh kebijakan perusahaan.
Jika diperlukan, developer bisa meminta pengguna untuk mencegah sistem mereset izin aplikasi mereka. Ini berguna dalam situasi ketika pengguna menginginkan aplikasi bekerja di latar belakang, tanpa berinteraksi dengannya. Kasus penggunaan utama tercantum di sini.
Jika aplikasi menargetkan setidaknya API 30, dan meminta pengguna untuk menonaktifkan reset otomatis izin, maka developer perlu melakukan beberapa perubahan kode sederhana. Jika aplikasi tidak menonaktifkan reset otomatis, maka tidak diperlukan perubahan kode.
Catatan: API ini hanya ditujukan untuk aplikasi yang targetSDK-nya adalah API 30 atau yang lebih tinggi, karena reset otomatis izin hanya berlaku untuk aplikasi ini secara default. Developer tidak perlu mengubah apa pun jika targetSDK aplikasi adalah API 29 atau lebih rendah.
Tabel di bawah ini merangkum API lintas platform baru (dibandingkan dengan API yang dipublikasikan di Android 11):
Build.VERSION.SDK_INT >= Build.VERSION_CODES.R
androidx.core.content.PackageManagerCompat.getUnusedAppRestrictionsStatus()
PackageManager.isAutoRevokeWhitelisted()
Intent.ACTION_AUTO_REVOKE_PERMISSIONS
androidx.core.content.IntentCompat.createManageUnusedAppRestrictionsIntent()
API lintas platform ini adalah bagian dari library Jetpack Core, dan akan tersedia di Jetpack Core v1.7.0. API ini sekarang tersedia dalam versi beta.
Contoh logika untuk aplikasi yang mengharuskan pengguna menonaktifkan reset otomatis:
val future: ListenableFuture<Int> = PackageManagerCompat.getUnusedAppRestrictionsStatus(context) future.addListener( { onResult(future.get()) }, ContextCompat.getMainExecutor(context) ) fun onResult(appRestrictionsStatus: Int) { when (appRestrictionsStatus) { // Status could not be fetched. Check logs for details. ERROR -> { } // Restrictions do not apply to your app on this device. FEATURE_NOT_AVAILABLE -> { } // Restrictions have been disabled by the user for your app. DISABLED -> { } // If the user doesn't start your app for months, its permissions // will be revoked and/or it will be hibernated. // See the API_* constants for details. API_30_BACKPORT, API_30, API_31 -> handleRestrictions(appRestrictionsStatus) } } fun handleRestrictions(appRestrictionsStatus: Int) { // If your app works primarily in the background, you can ask the user // to disable these restrictions. Check if you have already asked the // user to disable these restrictions. If not, you can show a message to // the user explaining why permission auto-reset and Hibernation should be // disabled. Tell them that they will now be redirected to a page where // they can disable these features. Intent intent = IntentCompat.createManageUnusedAppRestrictionsIntent (context, packageName) // Must use startActivityForResult(), not startActivity(), even if // you don't use the result code returned in onActivityResult(). startActivityForResult(intent, REQUEST_CODE) }
Logika di atas akan berfungsi di perangkat Android 6.0 – Android 10 dan juga Android 11+. Menggunakan API baru saja sudah cukup; Anda tidak perlu lagi memanggil API reset otomatis Android 11.
API baru ini juga kompatibel dengan hibernasi aplikasi yang diperkenalkan dalam Android 12 (API level 31). Hibernasi adalah batasan baru yang diterapkan pada aplikasi yang tidak digunakan. Fitur ini tidak tersedia pada versi OS sebelum Android 12.
API getUnusedAppRestrictionsStatus() akan menunjukkan API_31 apakah reset otomatis izin dan hibernasi aplikasi diterapkan pada aplikasi.
getUnusedAppRestrictionsStatus()
API_31
Diposting oleh Tom Grinsted, Scott Lin, dan Tat Yang Koh, Product Managers di Google Play
Rating dan ulasan adalah hal yang penting. Keduanya memberikan masukan kuantitatif dan kualitatif berharga mengenai pengalaman yang dilaporkan pengguna tentang aplikasi atau game Anda, dan layanan lebih luas yang Anda tawarkan. Karena itulah keduanya menjadi salah satu sinyal yang digunakan orang saat memutuskan apa yang akan didownload di Google Play.
Kami mendengar dari pengguna dan developer Play Store bahwa rating dan ulasan bisa lebih membantu. Ini memang benar ketika rating dari satu bidang berdampak pada bidang lain — seperti ketika bug yang hanya berdampak pada satu negara berdampak negatif pada rating aplikasi di semua negara; atau ketika peningkatan positif dalam pengalaman tablet tidak diperhatikan karena jumlah pengguna di ponsel. Jadi, kami memulai program peningkatan multikuartal untuk membuat rating lebih dipersonalisasi dan mengindikasikan pengalaman yang diharapkan oleh setiap pengguna, dan membuatnya lebih mudah dibuka dan digunakan developer:
Kami memahami bahwa banyak developer memantau dengan cermat rating yang dilihat calon pengguna mereka, jadi kami akan memastikan Anda mendapatkan banyak informasi tentang perubahan mendatang ini. Kami juga menyempurnakan Play Console untuk membantu Anda memahami rating dan ulasan - terutama di berbagai faktor bentuk.
Memperluas dukungan Anda untuk berbagai tipe perangkat adalah salah satu perubahan paling penting dan berdampak yang bisa Anda lakukan pada antarmuka pengguna. Menambahkan tata letak yang dioptimalkan untuk tablet atau dukungan mouse dan keyboard yang lebih baik untuk Chrome OS bisa mengakibatkan perubahan bertahap dalam kualitas pengalaman pengguna Anda, yang pada akhirnya akan memengaruhi rating dan ulasannya.
Gambaran rating Tipe perangkat baru tersedia di ringkasan rating dan halaman perincian Konsol Play
Untuk mempermudah menemukan peluang di berbagai tipe perangkat dan melacak dampak pengalaman yang disempurnakan, kami menambahkan dimensi Tipe Perangkat baru ke halaman rating. Kami juga menambahkan filter Tipe Perangkat ke ulasan sehingga Anda mudah melihat cara pengguna tablet memberikan rating kepada Anda, atau apa yang dikatakan pengguna di Chrome OS dalam ulasannya.
Banyak yang memberi tahu kami bahwa Anda ingin mengakses data secara lebih terperinci daripada yang diizinkan oleh pemilih kami. Jadi, kami memecah opsi segmentasi Anda dan membuatnya lebih mudah digunakan. Sekarang Anda bisa bebas memilih periode waktu yang ingin diplot (dari 28 hari terakhir hingga masa pakai total aplikasi Anda), dan bagaimana Anda menginginkan data rating disatukan (harian, mingguan, atau setiap 28 hari). Ini memungkinkan Anda mengakses data lebih terperinci dalam jangka waktu yang lebih lama.
Pilih rentang waktu dan periode agregasi secara bebas untuk menemukan data rating yang Anda inginkan
Kami juga mengaktifkan download CSV dari data rata-rata dan distribusi rating Anda. Dikombinasikan dengan opsi pemilihan data baru, Anda bisa dengan mudah melakukan kueri serta mendownload lebih banyak data dan melakukan analisis offline. Misalnya, Anda bisa mendownload seluruh histori distribusi rating harian dan menghubungkannya dalam spreadsheet dengan kontak layanan pelanggan.
Akses dan download semua data Anda termasuk perincian rating secara langsung dari halaman ringkasan
Semua perubahan ini sekarang tersedia di Play Console. Kunjungi Analisis Rating dan Ulasan untuk mencobanya.*
Rating membantu orang memutuskan aplikasi mana yang akan didownload dan dijadikan bahan pertimbangan untuk pengistimewaan dan penempatan di Play Store. Namun karena pengalaman aplikasi bisa berbeda-beda menurut wilayah dan tipe perangkat pengguna, rating total tidak selalu menunjukkan keadaan sebenarnya. Karena itulah, mulai November 2021, kami akan mengubah rating yang dilihat pengguna individu berdasarkan tempat mereka terdaftar, dan pada akhir tahun, perangkat yang mereka gunakan.
Mulai November, ini berarti pengguna ponsel akan melihat rating khusus untuk negara atau wilayah tempat mereka tinggal. Jadi pengguna di Jepang akan melihat rating aplikasi yang dikumpulkan dari rating yang dikirimkan oleh pengguna lainnya di Jepang.
Awal tahun depan kami akan meng-update rating untuk merefleksikan tipe perangkat yang digunakan pengguna untuk membuka Play, baik itu: tablet dan perangkat foldable, Chrome OS, Wear, atau Auto. Ini akan memberikan kesan yang lebih baik kepada pengguna tentang pengalaman yang mereka harapkan untuk perangkat yang digunakan. Kami sarankan Anda melihat rating faktor bentuk hari ini - terutama untuk tablet yang pertumbuhannya sangat kuat - untuk melihat apakah Anda harus berinvestasi dalam mengoptimalkan pengalaman pengguna.
Kami memahami bahwa sebagai developer, Anda ingin memastikan bahwa Anda memahami dan siap menghadapi perubahan besar dalam rating yang terlihat pengguna. Jadi setidaknya 10 minggu sebelum terjadi perubahan di Play Store, kami secara otomatis akan menganalisis perubahan yang dilihat oleh aplikasi Anda dan menjangkau semua developer yang melihat perubahan lebih dari 0,2 bintang pada tipe perangkat apa pun di salah satu pasar utama (dengan >5% pengunjung listingan Play Store Anda). Ini akan memberi Anda waktu untuk membuat perencanaan jika ingin membuat perubahan penting pada aplikasi.
Perubahan di Google Play ini akan meluncur mulai November dengan rating khusus untuk negara atau region. Nantikan pesan tentang rating di Inbox Konsol Play menjelang akhir tahun ini, dan jangan lupa bahwa Anda bisa mengeceknya lebih awal dengan memeriksa rating menurut negara dan tipe perangkat hari ini.
*Perhatikan, Anda memerlukan akun Konsol Play untuk mengakses link ini.
Menurut Anda, seberapa bermanfaatkah postingan blog ini?
★ ★ ★ ★ ★
Diposting oleh Ting-Yuan Huang, Software Engineer dan Jiaxiang Chen, Software Engineer
Kotlin Symbol Processing (KSP), alat baru kami untuk membangun plugin compiler ringan di Kotlin, sekarang dalam versi stabil! KSP menawarkan fungsionalitas yang mirip dengan Kotlin Annotation Processing Tool (KAPT), tetapi hingga 2x lebih cepat, menawarkan akses langsung ke konstruksi bahasa Kotlin, dan menawarkan dukungan untuk target multiplatform.
Selama beberapa bulan terakhir, KSP telah melalui 32 rilis dengan lebih dari 162 bug yang dilaporkan oleh komunitas dan diperbaiki oleh tim kami. Jika Anda berencana mengadopsinya, sekaranglah saatnya untuk mencoba.
Di tim Android, kami secara rutin bertanya kepada developer: apa frustrasi terbesar Anda saat menulis aplikasi saat ini? Salah satu masalah yang paling sering muncul adalah kecepatan build. Selama bertahun-tahun, kami terus melakukan peningkatan pada toolchain build Android, dan hari ini kami sangat gembira bisa menambahkan peningkatan tersebut dengan KSP. KSP adalah generasi berikutnya dari pemrosesan anotasi di Kotlin: KSP akan secara dramatis meningkatkan kecepatan build untuk developer Kotlin, dan tidak seperti KAPT, KSP menawarkan dukungan untuk Kotlin/Native dan Kotlin/JS.
"Menambahkan dukungan KSP ke Room meningkatkan kecepatan kompilasi dan memungkinkan Room untuk lebih memahami kode Kotlin, seperti nullability generik yang tidak mungkin dilakukan dengan KAPT. Ini juga membuka kemungkinan baru seperti pembuatan kode Kotlin, yang memungkinkan Room memiliki pengalaman pengguna Kotlin yang lebih baik di masa mendatang." - Yigit Boyar, Software Engineer, Android
Kotlin Annotation Processing Tool (KAPT) bekerja dengan infrastruktur pemrosesan anotasi Java untuk membuat sebagian besar pemroses anotasi bahasa Java langsung dapat digunakan di Kotlin. Untuk melakukannya, KAPT mengompilasi kode Kotlin ke dalam stub Java yang menyimpan informasi penting untuk pemroses anotasi Java. Membuat stub bukanlah hal mudah, ini berarti compiler harus me-resolve semua simbol dalam program Anda beberapa kali (sekali untuk menghasilkan stub, dan sekali lagi untuk melakukan kompilasi yang sesungguhnya).
KSP beralih dari model pembuatan stub dengan berfungsi sebagai plugin compiler Kotlin — ini memungkinkan pemroses anotasi membaca dan menganalisis program sumber dan sumber daya secara langsung di Kotlin, daripada mengharuskan Anda bergantung pada infrastruktur pemrosesan anotasi Java. Hal ini secara dramatis meningkatkan kecepatan build (hingga 2x lebih cepat untuk aplikasi pengujian Kotlin Room) dan berarti bahwa KSP bisa digunakan untuk lingkungan non-Android dan non-JVM seperti Kotlin/Native dan Kotlin/JS.
Untuk mulai menggunakan KSP, download project playground KSP dari GitHub, yang menunjukkan cara menggunakan KSP baik sebagai pemroses anotasi maupun sebagai aplikasi/library pengguna:
test-processor
workload
Jika Anda seorang developer aplikasi, lihat daftar library yang didukung dan panduan memulai untuk memindahkan modul dari KAPT ke KSP.
Jika Anda menggunakan Moshi atau Room dalam project, Anda sudah bisa mencoba KSP dengan melakukan perbaikan cepat pada file build modul. Sebagai contoh, untuk menggunakan Room versi KSP dalam modul Gradle, Anda cukup mengganti plugin KAPT dengan KSP dan menukar dependensi KSP:
apply plugin: 'com.google.devtools.ksp' dependencies { ... implementation "androidx.room:room-runtime:$room_version" kapt "androidx.room:room-compiler:$room_version" ksp "androidx.room:room-compiler:$room_version" }
Lihat catatan rilis Room untuk informasi selengkapnya.
Dengan rilis KSP 1.0, Anda akan mulai melihat peningkatan waktu build untuk project Kotlin saat Anda bermigrasi dari pemrosesan berbasis library di KAPT. Kami juga telah meng-update sejumlah library khusus Android yang bisa Anda coba hari ini dan menawarkan peningkatan performa yang signifikan.
Diposting oleh Dave Burke, VP of Engineering
Kita hanya beberapa pekan lagi dari rilis resmi Android 12! Sembari memberikan sentuhan akhir pada versi baru Android, hari ini kami menghadirkan update versi Beta final untuk membantu Anda dalam pengujian dan pengembangan. Untuk developer, sekarang adalah saatnya memastikan aplikasi Anda sudah siap!
Anda bisa mendapatkan Beta 5 hari ini di perangkat Pixel, termasuk di Pixel 5a dengan 5G, dengan mendaftar di sini untuk mendapatkan update over the air (OTA). Jika sudah terdaftar, Anda akan mendapatkan update secara otomatis. Anda juga bisa mencoba Android 12 Beta 5 di perangkat tertentu dari beberapa mitra kami seperti Sharp. Kunjungi situs developer Android 12 untuk detailnya.
Nantikan informasi selengkapnya tentang rilis resmi Android 12 yang segera hadir!
Update hari ini menyertakan build kandidat rilis Android 12 untuk Pixel dan perangkat lainnya serta Android Emulator. Kami mencapai Stabilitas Platform di Beta 4, jadi semua tampilan aplikasi sudah final, termasuk API SDK dan NDK, perilaku sistem yang berhubungan langsung dengan aplikasi, dan pembatasan pada antarmuka non-SDK. Dengan semua ini dan perbaikan serta optimalisasi terbaru, Beta 5 memberi Anda semua yang dibutuhkan untuk menyelesaikan pengujian.
Dengan rilis resmi Android 12 yang segera hadir, kami meminta semua developer aplikasi dan game untuk menyelesaikan pengujian kompatibilitas akhir dan memublikasikan update kompatibilitas Anda sebelum rilis final. Untuk developer SDK, library, fitur, dan game engine, perlu sekali merilis update yang kompatibel sesegera mungkin -- developer hilir aplikasi dan game Anda mungkin diblokir hingga mereka menerima update.
Untuk menguji kompatibilitas aplikasi Anda, cukup instal di perangkat yang menjalankan Android 12 Beta 5 dan kerjakan alur aplikasi untuk mencari masalah fungsional atau UI. Tinjau perubahan perilaku Android 12 untuk semua aplikasi dan fokuskan pada bagian aplikasi yang mungkin terpengaruh. Berikut adalah beberapa perubahan yang harus diuji:
Ingatlah menguji kompatibilitas library dan SDK di aplikasi Anda. Jika Anda menemukan masalah SDK, cobalah update ke versi SDK terbaru atau hubungi developer untuk mendapatkan bantuan.
Setelah Anda memublikasikan versi aplikasi yang kompatibel, Anda bisa memulai proses untuk meng-update targetSdkVersion aplikasi. Tinjau perubahan perilaku untuk aplikasi Android 12 dan gunakan framework kompatibilitas untuk membantu mendeteksi masalah dengan cepat.
Android 12 memiliki banyak fitur baru untuk membantu Anda membangun pengalaman yang menakjubkan bagi pengguna. Lihat postingan Android 12 Beta 2 kami untuk melihat rekap dan link pembicaraan Android 12 di Google I/O. Untuk detail selengkapnya tentang semua fitur dan API baru, kunjungi situs developer Android 12.
Pastikan juga mencoba Android Studio Arctic Fox dengan pengembangan dan pengujian Android 12 Anda. Kami telah menambahkan pemeriksaan lint untuk membantu Anda mengetahui bagian kode yang mungkin terpengaruh oleh perubahan Android 12, seperti deklarasi khusus layar pembuka, izin lokasi kasar untuk penggunaan lokasi yang baik, format media, dan izin frekuensi pengambilan sampel sensor tinggi. Anda bisa mencobanya dengan mendownload dan mengonfigurasi versi terbaru Android Studio.
Rilis Beta 5 kali ini memiliki semua yang Anda butuhkan untuk mencoba fitur Android 12, menguji aplikasi Anda, dan memberi kami masukan. Cukup daftarkan perangkat Pixel yang didukung untuk mendapatkan update over the air (OTA). Untuk mulai mengembangkan, siapkan Android 12 SDK.
Anda juga bisa mendapatkan Beta 5 di perangkat beberapa mitra kami seperti Sharp. Untuk pengujian yang lebih luas, Anda bisa mencoba Beta 5 pada image Android GSI, dan jika tidak memiliki perangkat, Anda dapat mengujinya di Android Emulator. Update ini juga tersedia untuk Android TV, sehingga Anda bisa melihat fitur TV terbaru dan menguji aplikasi di pengalaman Google TV yang sepenuhnya baru.
Nantikan peluncuran resmi Android 12 dalam beberapa pekan ke depan! Jangan ragu untuk terus menyampaikan masukan Anda melalui daftar hotlist kami untuk masalah platform, masalah kompatibilitas aplikasi, dan masalah SDK pihak ketiga.
Terima kasih yang sebesar-besarnya kepada komunitas developer yang telah membantu membentuk rilis Android 12! Anda telah mengirimkan ribuan laporan bug dan membagikan data yang telah membantu kami menyesuaikan API, meningkatkan fitur, memperbaiki bug krusial, dan secara umum menjadikan platform ini lebih baik bagi pengguna dan developer.
Kami tunggu kehadiran aplikasi Anda di Android 12!
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 ↩
