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 ↩
