Ditulis oleh: Purnima Kochikar, VP of Partnerships, Google Play
Minggu ini kami merayakan sepuluh tahun usia Google Play. Selama dekade yang lalu, kreativitas Anda dikombinasikan dengan investasi kami dalam sebuah platform global telah menciptakan ekosistem aplikasi yang berkembang pesat. 2,5 miliar orang di lebih dari 190 negara mengunjungi Play setiap bulan untuk terhubung dengan aplikasi dan game Anda, dan Play telah menghasilkan lebih dari $120 miliar penghasilan bagi developer hingga saat ini. Kami sangat bangga dengan pencapaian luar biasa ini, dan berterima kasih atas kemitraan Anda.
Melihat ke belakang
Saya bergabung dengan tim ini pada tahun 2012, hanya beberapa bulan setelah Google Play diluncurkan. Saat itu, pengguna aktif di Android baru saja tumbuh dari 100 juta menjadi 400 juta. Android adalah pendatang baru, dengan tujuan yang berani yaitu membuat komputasi seluler dapat diakses oleh siapa pun, di mana pun. Anda mungkin meragukan peluang kami untuk sukses - kami sangat jauh di belakang platform kompetitor dalam banyak aspek, mulai dari fitur dan alat platform hingga panduan desain dan kemampuan komersial. Keyakinan kami terhadap potensi besar dari sebuah ekosistem yang adil dan terbuka - serta, yang lebih penting, keyakinan kami pada potensi Anda yang tak terbatas - membuat kami terus maju. Kami melangkah dan terus didorong oleh komitmen kami untuk kesuksesan Anda.
Saat itu, tim kemitraan kami yang hanya terdiri dari enam orang sedang mencari cara terbaik untuk mendukung Anda dalam membuka peluang dan tantangan ekonomi seluler. Ada begitu banyak ketidakpastian: apakah kami dapat menghadirkan aplikasi yang Anda impikan kepada audience global pada perangkat yang terjangkau oleh mereka? Apakah orang akan menonton video di layar smartphone yang kecil, mengingat tingginya biaya data seluler dan kemampuan perangkat yang rendah? Apakah mereka mau membayar game seluler, dan merasa aman saat melakukannya? Apakah orang akan berlangganan konten dalam aplikasi secara sama dengan yang biasa mereka lakukan pada item fisik seperti majalah dan surat kabar?
Kami selalu bersama Anda dalam setiap proses ini, meluangkan waktu untuk memahami kebutuhan Anda, dan menemukan cara untuk membantu Anda membangun aplikasi dan game yang indah. Kami juga mengundang komunitas pengguna global untuk membantu kami mengembangkan aplikasi dan game Anda bersama-sama, didukung oleh fitur seperti pengujian beta dan peluncuran bertahap, serta kemampuan untuk membalas ulasan pengguna.
Kenangan terindah saya dari masa-masa awal itu adalah bekerja dengan perusahaan yang menginspirasi kami dengan memimpikan cara-cara baru untuk memanfaatkan keajaiban perangkat seluler. Mereka memperluas perspektif kami tentang hal-hal yang bisa dilakukan. Smule adalah salah satu kisah sukses dari hari-hari awal Play. Sungguh luar biasa melihat mereka tumbuh dan berkembang selama dekade terakhir.
Saat aplikasi mendapatkan traksi dan Anda ingin mengubahnya menjadi bisnis global berkelanjutan, kami memperkuat investasi platform niaga kami untuk membantu Anda mengembangkan dan mengelola bisnis Anda. Kami menambahkan metode pembayaran paling populer dan efektif dari seluruh dunia untuk memastikan orang-orang bisa membayar aplikasi dan game Anda dengan mudah. Kami menghapus kompleksitas yang terkait dengan pencarian dan pengintegrasian pembayaran lokal, termasuk akses ke lebih dari 300 metode pembayaran lokal yang didukung di 70 negara. Kami juga mengembangkan platform kami untuk mengantisipasi dan mendukung kebutuhan bisnis Anda - beralih dari model bisnis premium ke free-to-play dan langganan - dan sekarang Google Play membantu konsumen bertransaksi dengan aman dan lancar di lebih dari 170 pasar.
Kami memberikan insight terdepan dalam industri melalui Konsol Play pada siklus proses aplikasi Anda, mulai dari penginstalan hingga Vitals dan lainnya, untuk membantu Anda mengelola bisnis secara efektif. Saya ingat seluruh tim saya menangis ketika Vincenzo Colucci, pendiri Smart Launcher, menjelaskan bagaimana Play memungkinkannya tinggal di tempat yang ia impikan - di Manfredonia, Italia Selatan, dengan orang yang dicintainya - dan melakukan hal yang ia sukai - membuat aplikasi yang berdampak terhadap banyak orang di seluruh dunia. Perusahaannya juga berusia 10 tahun beberapa hari yang lalu.
Dalam setiap langkah, Anda menuntut sesuatu yang lebih dari kami dan menginspirasi kami untuk berpikir lebih luas. Sebagai respons, tim produk dan engineering kami membuat alat dan kemampuan yang bisa mendukung semua hal menakjubkan yang Anda lakukan. Masukan Anda telah membantu membentuk peluncuran fitur, sumber daya, dan program baru untuk mendukung kesuksesan Anda dalam platform ini. Dengan bantuan Anda, kami telah berevolusi:
Kami juga bekerja sama dengan Anda untuk membuat fitur baru yang akan berguna bagi seluruh ekosistem. Misalnya, pada tahun 2015, kami bekerja dengan Supercell untuk membantu mencegah penipuan, yang mengarah pada peluncuran Voided Purchases API, yang mendorong peningkatan di seluruh industri terhadap penipuan dan penyalahgunaan pengembalian dana. Demikian pula, mitra Jepang dan Korea kami seperti GungHo Online Entertainment dan NCSOFT membantu kami berkembang dari platform yang mendukung game bayar-dan-download, seperti Angry Birds awal dari Rovio, menjadi platform LiveOps yang mendukung game sebagai layanan langsung. Mitra media membantu kami mengembangkan platform langganan untuk menyertakan fitur seperti Penangguhan Akun dan Masa Tenggang. Yang menarik, kami menggunakan fitur ini untuk membantu mitra aplikasi olahraga mempertahankan pelanggannya saat dunia sedang lockdown.
Meskipun ada banyak contoh lainnya dalam kemitraan kami selama satu dekade, berikut adalah 10 peluncuran kami yang paling berkesan dalam 10 tahun terakhir:
Seiring berkembangnya bisnis Anda, kami berinvestasi dalam kemampuan produk seperti Play Points untuk membantu Anda mempertahankan dan menarik kembali pengguna yang paling loyal. Kami sangat bangga program ini memiliki lebih dari 100 juta pelanggan di 28 negara, dengan ekspansi selanjutnya dijadwalkan akhir tahun ini. Kami juga membuat layanan konsultasi untuk memberikan insight bisnis dan teknis guna membantu Anda membuat keputusan berdasarkan data tentang roadmap produk dan rencana ekspansi global Anda. Anda memberi tahu kami bahwa insight ini telah membantu mendorong jutaan peningkatan pendapatan untuk Anda, dan tidak hanya menginformasikan arah produk, tetapi juga strategi M&A Anda.
Yang terpenting, kemitraan kami telah menghadirkan aplikasi dan game yang berdampak bagi audience global, dan membangun bisnis sukses yang telah menciptakan lapangan kerja baru dan membantu ekonomi lokal. Di AS saja, Play dan Android telah membantu menciptakan lebih dari 2 juta pekerjaan. Kami benar-benar bangga dengan dampak ekonomi yang kami rasakan bersama komunitas lokal dan bisnis kecil di seluruh dunia.
Melihat ke depan
Sembari kita menantikan dekade berikutnya, mari kita berhenti sejenak dan merenungkan dua tahun terakhir yang menakjubkan yang telah kita lewati bersama, dan dampak positif yang luar biasa dari kemitraan kita terhadap kehidupan banyak orang. Android dan Play - didukung oleh bisnis Anda - telah menghubungkan banyak keluarga dan orang-orang terkasih, membantu orang tetap aman dengan mendukung kebutuhan sehari-hari, mempercepat akses pengobatan jarak jauh, menciptakan lapangan kerja, dan memungkinkan anak-anak untuk belajar dan tumbuh. Mari luangkan waktu sejenak agar semuanya meresap.
Tahun-tahun ini telah mengajari kami pelajaran penting tentang tanggung jawab bersama untuk mendorong ekosistem yang aman dan tepercaya, dan hal lain yang harus dilakukan agar perangkat seluler dapat diakses oleh semua orang. Saat kami berpikir tentang masa depan, ada tiga area yang menjadi perhatian utama kami:
Membantu siapa pun, di mana pun merasakan nilai yang diberikan aplikasi Anda, dengan membantu Anda menghadirkan aplikasi dan game yang lebih baik di semua perangkat dan layar. Kami memperluas jangkauan game kami ke PC melalui Layanan Game Play, yang menampilkan aplikasi paling relevan bagi pengguna melalui langganan aplikasi pilihan seperti Play Pass, dan membantu orang-orang menemukan aspek paling menarik dari aplikasi Anda melalui Penawaran Play dan LiveOps.
Terus mengembangkan alat kami untuk mendukung pengambilan keputusan bisnis Anda, mengembangkan model bisnis kami, dan untuk membantu Anda mengembangkan bisnis dengan aman dan menghadirkan pengalaman terbaik bagi pengguna dalam lanskap privasi dan keamanan yang terus berkembang.
Membangun ekosistem untuk semua orang dengan berinvestasi dalam inisiatif yang meningkatkan representasi pada industri aplikasi dan game, dan dengan mendukung lebih banyak pendiri yang kurang terwakili untuk membangun bisnis yang sukses. Tahun lalu kami bergerak dari model biaya layanan “satu ukuran untuk semua” guna memastikan semua jenis bisnis dapat berhasil, dan kami akan terus menghadirkan beberapa program yang dirancang untuk mendukung ekosistem aplikasi kami yang beragam.
Investasi berpengalaman, pendiri yang sukses telah muncul di developer generasi berikutnya melalui program Indie Game Festival dan Accelerator kami, dan dampak yang signifikan dari inisiatif Change the Game dan upaya aksesibilitas membuat kami optimis tentang ekosistem ini. Pada dekade mendatang, kami menantikan lebih banyak pendiri seperti Alyssa yang berusia sembilan tahun dan ibunya yang menciptakan Frobelles, permainan berdandan yang merepresentasikan gaya rambut Afrika dan Karibia, ke keluarga #WeArePlay kami.
Terima kasih telah menjadi bagian integral dari tujuan kami untuk membuat perangkat seluler dapat diakses oleh siapa pun, di mana pun. Kami telah melangkah jauh dan perjalanan kami masih panjang. Kami terinspirasi dan berterima kasih kepada Anda semua, dan akan selalu berkomitmen untuk kesuksesan Anda. Kami sangat menantikan karya berikutnya yang akan Anda buat, dan cakrawala baru yang Anda buka untuk kami jelajahi dan aktifkan.
Dengan penuh rasa terima kasih,
Purnima Kochikar
Diposting oleh Tim Android
Sebagai salah satu platform media sosial yang paling banyak digunakan, Twitter selalu mencari cara untuk menghubungkan penggunanya dengan lebih baik. Secara bersamaan, untuk membangun fitur baru secara efisien sambil mempertahankan fitur yang sudah ada, developer memerlukan infrastruktur yang mendukung. Tim engineer Twitter beralih ke Jetpack Compose untuk memulai perombakan yang sangat dibutuhkan fondasi UI aplikasi. Dengan Compose, developer bisa dengan mudah menemukan dan menggunakan API yang tepat, dengan cepat mengubah gaya dan memodulasi komponen, serta membangun lebih banyak dengan lebih sedikit kode.
Beberapa tim, seperti tim Android Client UI, Customer Acquisition, Twitter Blue, dan tim Komunitas, mengubah proses pengembangan mereka, yang menginspirasi kegembiraan di antara para engineer Twitter. “Beberapa tim di Twitter telah mengadopsi Compose dalam alur kerja harian mereka,” kata Sneha Patil, senior software engineer dan kepala teknis di tim Komunitas bagi Twitter untuk Android. Dengan menghapus pekerjaan membuat dan menyiapkan tema dan atribut khusus, Compose membuat fungsi penulisan dan penerapan persyaratan desain jauh lebih cepat dan lebih mudah daripada pengalaman mereka selama menggunakan Views. Jetpack Compose memungkinkan tim bekerja lebih cepat dan efektif, memastikan penggunaan kembali dalam kode mereka, dan dengan mudah mengajak engineer baru bergabung.
Membuat konten dinamis sangatlah mudah dengan Compose. Tim Twitter menggunakan composable LazyColumn untuk membangun UI tanpa memerlukan Adaptor atau ViewHolder, menyederhanakan proses penulisan kode yang secara mulus menghidupkan tata letak, tema, dan gaya. Dengan lebih sedikit baris yang ditulis, tim pengembangan di Twitter mengurangi boilerplate mereka, menemukan lebih sedikit bug selama pengembangan dan rilis, mengaktifkan eksperimen UI, dan mempercepat proses pengujian. Penyempurnaan ini meningkatkan produktivitas sehingga developer bisa menghabiskan lebih banyak waktu untuk membangun hal-hal yang membuat Twitter unik.
Mereka juga menggunakan Compose untuk membuat komponen stateless yang dapat digunakan kembali di seluruh aplikasi. Fleksibilitas Compose membuatnya lebih mudah dan cepat untuk memenuhi persyaratan desain, menjadikan pekerjaan pengaturan tema dan gaya lebih mudah bagi engineer baru dan berpengalaman.
Melihat peningkatan yang dialami, mereka memutuskan untuk membangun seluruh fitur baru menggunakan Compose. Mereka membangun fitur Komunitas, sebuah ruang khusus Twitter di mana pengguna bisa berinteraksi dalam diskusi yang mereka minati, dari awal menggunakan Compose. Berdasarkan pengalaman tim sebelumnya yang menggunakan Views untuk fitur lain, membangun dengan Compose jauh lebih cepat dengan bug lebih sedikit. “Ini seperti sulap,” kata Sneha, “Ini adalah pengubah permainan tentang bagaimana kami bisa mengembangkan di Android dengan Compose.”
Compose meningkatkan kecepatan dan efisiensi pengembangan UI engineer Twitter. Developer dengan mudah menggabungkan dan membangun menggunakan Compose, yang memudahkan mereka untuk memodulasi kode, menggunakan kembali komponen, dan memecah dependensi. Tim secara rutin menggunakan eksperimen UI, dan Compose membantu meningkatkan kepercayaan diri mereka dengan mengetahui komponen yang bereaksi terhadap interaksi pengguna, update data, dan berbagai ukuran layar yang akan terlihat dalam produksi.
Keberhasilan awal tim ini dengan Compose menginspirasi tim pengembangan lain di Twitter untuk mengikutinya. Bahkan sekarang, engineer yang mengerjakan komponen lama yang kompleks sedang mempertimbangkan untuk mengadopsinya.
Secara umum, Compose tidak hanya menghilangkan banyak kendala yang dialami tim dalam Views — ia juga menambahkan kenikmatan ke dalam alur kerja, dengan beberapa developer siap untuk meninggalkan metode lama. “Saya senang sekali bisa menulis lebih banyak Compose dan tidak akan pernah menyentuh tata letak XML lagi,” kata Yoali Sotomayor Baqueiro, software engineer untuk Android Client UI di Twitter. “Ini membuat pengembangan UI tidak hanya lebih mudah tetapi juga jauh lebih menyenangkan dan intuitif.”
Optimalkan pengembangan UI Anda dengan Compose.
Hari ini kami merilis Android 13 Beta ketiga, membawa kami ke fase siklus terakhir di mana kami berfokus pada penyempurnaan dan performa. Dengan Android 13, kami membangun tema inti tentang privasi dan keamanan, produktivitas developer, serta dukungan tablet dan layar besar.
Banyak hal yang bisa dipelajari di Android 13, mulai dari fitur privasi seperti izin notifikasi baru dan pemilih foto, hingga fitur produktivitas seperti ikon aplikasi bertema dan dukungan bahasa per aplikasi, serta fitur standar modern seperti video HDR, Bluetooth LE Audio, dan MIDI 2.0 melalui USB. Kami juga memperluas update terbaru yang kami buat di 12L, sehingga memberi Anda alat yang lebih baik untuk memaksimalkan potensi lebih dari 270 juta tablet dan perangkat layar besar yang digunakan secara aktif.
Versi Beta 3 membawa Android 13 ke Stabilitas Platform, artinya sekarang API developer dan semua perilaku aplikasi sudah final. Kami berterima kasih atas semua masukan yang Anda berikan sehingga kami bisa mencapai titik ini! Untuk developer, fokusnya sekarang adalah menguji kompatibilitas dan kualitas saat Anda menyiapkan aplikasi untuk rilis resmi di akhir tahun!
Anda bisa mendapatkan versi Beta 3 di perangkat Pixel dengan mendaftar di sini untuk mendapatkan update over the air (OTA). Jika sebelumnya sudah mendaftar, Anda akan mendapatkan update hari ini secara otomatis. Anda juga bisa mencoba Android 13 Beta di perangkat tertentu dari beberapa mitra kami - pelajari lebih lanjut di android.com/beta. Baca terus untuk melihat sekilas tentang cara menyiapkan aplikasi Anda, dan kunjungi situs developer Android 13 untuk detailnya.
Dengan versi Beta 3, Android 13 mencapai Stabilitas Platform, sebuah tahap pencapaian yang berarti semua perilaku aplikasi dan API, termasuk API NDK dan API Level 33 SDK resmi, kini sudah final. Jadi dari versi Beta 3, Anda bisa percaya diri mengembangkan dan merilis update kompatibilitas karena tahu bahwa platform ini tidak akan berubah.
Kami meminta semua developer aplikasi dan game untuk memulai pengujian kompatibilitas akhir sekarang dan bersiap memublikasikan update kompatibilitas Anda sesegera mungkin sebelum rilis final.
Untuk semua developer SDK, library, fitur, dan game engine, perlu sekali memulai pengujian sekarang dan merilis update yang kompatibel sesegera mungkin -- developer hilir aplikasi dan game Anda mungkin diblokir hingga mereka menerima update. Jadi ketika Anda sudah merilis update yang kompatibel, umumkan dan beri tahu developer!
Kompatibilitas aplikasi berarti aplikasi Anda berjalan sesuai harapan pada platform versi baru. Dengan setiap rilis, kami membuat perubahan integral pada platform untuk meningkatkan privasi dan keamanan serta pengalaman pengguna secara seluruh di OS. Ini bisa memengaruhi aplikasi Anda, jadi sangatlah penting untuk menguji aplikasi Anda sekarang, membuat update yang diperlukan, dan memublikasikan update yang kompatibel kepada pengguna sebelum rilis final. Ini adalah dasar tetapi merupakan faktor kualitas penting yang akan disukai oleh pengguna Anda saat mereka mempelajari hal hal baru di Android 13.
Untuk menguji kompatibilitas aplikasi Anda, cukup instal aplikasi produksi dari Google Play atau sumber lain ke perangkat yang menjalankan Android 13 Beta 3. Ikuti semua alur aplikasi dan perhatikan masalah fungsionalitas atau UI. Tinjau perubahan perilaku untuk memfokuskan pengujian Anda. Berikut ini beberapa perubahan yang harus diperhatikan:
Ingatlah juga untuk menguji kompatibilitas library dan SDK di aplikasi Anda. Jika Anda menemukan masalah, cobalah update ke versi library atau SDK terbaru atau hubungi developer untuk mendapatkan bantuan.
Setelah memublikasikan versi aplikasi yang kompatibel, Anda bisa memulai proses untuk meng-update targetSdkVersion aplikasi. Tinjau perubahan perilaku untuk aplikasi yang menargetkan Android 13 dan gunakan framework kompatibilitas untuk membantu Anda mendeteksi masalah dengan cepat. Berikut ini beberapa perubahan yang perlu diuji (ini hanya berlaku untuk aplikasi dengan targetSdkVersion disetel ke API 33 atau yang lebih tinggi):
NEARBY_WIFI_DEVICES
READ_EXTERNAL_STORAGE
BODY_SENSORS_BACKGROUND
Android 13 dibangun di atas pengoptimalan tablet yang diperkenalkan di 12L, jadi sebagai bagian dari pengujian, pastikan aplikasi Anda tampil optimal di tablet dan perangkat layar besar lainnya. Anda bisa mengujinya menggunakan fitur layar besar dengan menyiapkan emulator Android di Android Studio, atau Anda dapat menggunakan perangkat layar besar dari mitra Android 13 Beta kami. Berikut ini beberapa area yang harus diperhatikan:
Anda bisa membaca selengkapnya tentang fitur tablet di Android 13 dan hal-hal yang harus diuji di sini.
Rilis Beta hari ini memiliki semua yang Anda butuhkan untuk menguji aplikasi dan mencoba fitur Android 13. Cukup daftarkan perangkat Pixel Anda untuk mendapatkan update over the air (OTA). Untuk memulai, siapkan Android 13 SDK.
Anda juga bisa menguji aplikasi dengan Android 13 Beta di perangkat dari beberapa mitra kami. Kunjungi android.com/beta untuk melihat daftar mitra selengkapnya, dengan link ke situs mereka untuk mendapatkan detail tentang perangkat yang didukung dan versi Beta, dimulai dengan versi Beta 1. Setiap mitra akan menangani pendaftaran dan dukungan mereka sendiri, serta memberikan update versi Beta kepada Anda secara langsung. Untuk pengujian yang lebih luas, Anda bisa mencoba Android 13 Beta 3 pada image GSI Android, dan jika tidak memiliki perangkat, Anda dapat mengujinya di Android Emulator.
Untuk detail selengkapnya tentang Android 13, kunjungi situs developer Android 13.
Diposting oleh Dave Burke, VP of Engineering
Sebagai bagian dari upaya kami memodernisasi panduan arsitektur aplikasi, kami ingin bereksperimen dengan pola UI berbeda untuk mengetahui pola terbaik, menemukan persamaan dan perbedaan di antara beberapa alternatifnya, dan pada akhirnya menggabungkan pembelajaran tersebut sebagai praktik terbaik.
Agar temuan kami mudah diikuti, kami membutuhkan sampel yang memiliki kasus bisnis yang familier dan tidak terlalu rumit. Dan… siapa yang tidak tahu dengan aplikasi TODO ? Kami memilih Architecture Blueprints! Secara historis, Blueprints berfungsi sebagai taman bermain eksperimental untuk pilihan arsitektur. Sangat cocok untuk ini!
Pola yang ingin kami uji jelas dipengaruhi oleh berbagai API yang tersedia saat ini. API terbaru saat ini adalah Jetpack Compose State API! Karena Compose bekerja secara mulus dengan setiap pola Aliran Data Searah , kami akan menggunakan Compose untuk merender UI guna membuat perbandingan yang adil.
Postingan blog ini menceritakan cara tim memigrasikan Architecture Blueprints ke Jetpack Compose. Karena LiveData juga dianggap sebagai alternatif dalam eksperimen, kami membiarkan sampel seperti pada saat migrasi. Dalam pemfaktoran ulang ini, class ViewModel dan layer data tidak disentuh.
⚠️ Arsitektur yang digunakan dalam codebase berbasis LiveData ini tidak sepenuhnya mengikuti praktik terbaik arsitektur terbaru. Secara khusus, LiveData tidak boleh digunakan dalam layer data atau domain — Flows dan coroutine bisa digunakan sebagai gantinya.
Sekarang setelah konteksnya jelas, mari kita dalami cara melakukan pendekatan pemfaktoran ulang Blueprints ke Jetpack Compose. Anda bisa melihat kode lengkapnya di cabang dev-compose.
Sebelum benar-benar mengerjakan coding, tim membuat rencana migrasi untuk memastikan semua orang setuju dengan perubahan yang diusulkan. Tujuan utamanya adalah menjadikan Blueprints sebagai aplikasi aktivitas tunggal dengan layar sebagai fungsi yang dapat dikomposisi, dan menggunakan library Compose Navigation yang direkomendasikan untuk berpindah antar layar.
Untungnya, Blueprints sudah menjadi aplikasi aktivitas tunggal yang menggunakan Jetpack Navigation untuk berpindah antar layar yang diimplementasikan dengan Fragment. Untuk bermigrasi ke Compose, kami mengikuti panduan interoperabilitas Navigation yang merekomendasikan aplikasi hibrid untuk menggunakan komponen Navigation berbasis fragmen dan menggunakan fragmen untuk menahan layar berbasis tampilan, layar Compose, serta layar yang menggunakan tampilan dan Compose. Sayangnya, tidak mungkin menggabungkan tujuan Fragment dan Compose dalam grafik Navigation yang sama.
Tujuan dari migrasi bertahap ini adalah untuk memudahkan peninjauan kode dan menjaga produk yang dapat dikirim selama migrasi. Rencana migrasi melibatkan tiga langkah:
Dan itulah yang kami lakukan! 🧑💻 Maju cepat ⏩ dua minggu, kami melakukan migrasi layar Layar Statistik (PR), layar Tambah/Edit tugas (PR), layar Detail tugas (PR), dan layar Tugas (PR); dan kami menggabungkan PR final yang memigrasikan logika Navigation dan Activity ke Compose, termasuk menghapus dependensi sistem Tampilan yang tidak digunakan.
Selama migrasi, kami menemukan beberapa ciri khusus Compose yang perlu disoroti:
Setelah Anda mulai menambahkan Compose ke aplikasi, pengujian yang menyatakan UI Compose harus menggunakan API pengujian Compose.
Untuk pengujian UI tingkat layar, sebagai ganti menggunakan API launchFragmentInContainer<FragmentType>, kami menggunakan API createAndroidComposeRule<ComponentActivity> yang memungkinkan kami mengambil resource string dalam pengujian. Pengujian ini berjalan dalam Espresso dan Robolectric. Karena Compose sudah mendukung ini semua, maka tidak diperlukan perubahan tambahan. Sebagai contoh, Anda bisa membandingkan kode dalam AddEditTaskFragmentTest yang dimigrasikan ke AddEditTaskScreenTest. Perhatikan, jika menggunakan ComponentActivity, Anda harus bergantung pada artefak androidx.compose.ui:ui-test-manifest.
Untuk pengujian integrasi atau end-to-end, kami juga tidak menemukan masalah! Berkat interoperabilitas Espresso dan Compose, kami menggunakan pernyataan Espresso untuk memeriksa Tampilan, dan API Compose untuk memeriksa UI Compose. Inilah sekilas tampilan AppNavigationTest selama migrasi ke Compose.
Kami memang memiliki masalah dengan cara menangani event ViewModel di Blueprints. Blueprints menerapkan solusi Event wrapper untuk mengirim perintah dari ViewModel ke UI. Namun, itu bukan sesuatu yang bisa berfungsi di Compose. Panduan terbaru kami merekomendasikan pemodelan “event” tersebut sebagai status, dan itulah yang kami lakukan selama migrasi.
Dengan melihat kasus penggunaan event menampilkan pesan di layar , kami mengganti tipe Event<Int> dari LiveData menjadi Int? Ini juga memodelkan skenario ketika tidak ada pesan untuk ditampilkan kepada pengguna. Dalam kasus penggunaan khusus ini, ViewModel juga memerlukan konfirmasi dari UI setiap kali pesan ditampilkan. Lihat perbedaan antara kedua implementasinya dalam kode berikut:
Meskipun sekilas mungkin terlihat lebih merepotkan, ini menjamin setiap pesan ditampilkan di layar!
Dalam kode UI, cara untuk memastikan event hanya ditangani sekali adalah dengan memanggil event.getContentIfNotHandled(). Pendekatan ini bekerja dengan baik di Fragmen tetapi gagal di Compose! Karena rekomposisi dapat terjadi sewaktu-waktu di Compose, event wrapper bukanlah solusi yang cocok. Jika event diproses dan fungsinya dikomposisi ulang (sesuatu yang sering terjadi saat menguji pendekatan ini), maka snackbar akan dibatalkan, dan pengguna mungkin melewatkan pesannya. Ini adalah masalah UX yang tidak dapat diterima! Solusi event wrapper tidak boleh digunakan di aplikasi Compose.
Lihat cuplikan kode berikut dengan kode sebelum (event wrapper) dan setelah (event as state). Karena menampilkan pesan di layar adalah logika UI dan composable layar semakin kompleks, kami menggunakan class holder status biasa untuk mengelola kompleksitas itu (mis. lihat AddEditTaskState).
Saat pemfaktoran ulang, Anda mungkin tergoda untuk memigrasikan semua yang ada ke Compose. Meskipun bukan masalah, Anda tidak boleh mengorbankan Pengalaman Pengguna atau kebenaran aplikasi Anda. Inti dari memigrasikan bertahap adalah aplikasi selalu dalam status dapat dikirim.
Ini terjadi pada kami saat memigrasikan beberapa layar ke Compose. Kami tidak ingin melakukan terlalu banyak migrasi secara bersamaan, dan memigrasikan beberapa layar ke Compose sebelum memigrasikan dari Event wrapper. Sebagai ganti menangani Event wrapper di Compose dan memberikan pengalaman yang kurang optimal, kami terus menangani pesan-pesan tersebut di Fragmen sedangkan kode lainnya untuk layar di Compose. Sebagai contoh, lihat status TasksFragment selama migrasi.
Tidak semuanya berjalan semulus kelihatannya. 🫤 Meskipun mengonversi isi Fragmen ke Compose sangatlah mudah, melakukan migrasi dari Navigation Fragment ke Navigation Compose membutuhkan banyak waktu dan pertimbangan.
Ada kebutuhan untuk memperluas dan menyempurnakan panduan mengenai berbagai aspek yang akan mempermudah migrasi ke Compose di masa mendatang. Pekerjaan ini memicu percakapan dan kami berharap bisa segera mendapatkan panduan baru tentang hal ini! 🎊
Sebagai pemula Navigation ✋ dan orang yang menangani migrasi ke Navigation Compose, saya menghadapi tantangan berikut:
Secara keseluruhan, melakukan migrasi dari Navigation Fragment ke Navigation Compose adalah tugas yang menyenangkan untuk dilakukan! Lucunya, kami menghabiskan banyak waktu menunggu tinjauan pembanding daripada memigrasikan proyek itu sendiri! Membuat rencana migrasi dan mengarahkan semua orang ke area yang sama pasti membantu menetapkan ekspektasi lebih awal dan memperingatkan rekan-rekan tentang ulasan yang masuk.
Kami harap Anda senang membaca pendekatan kami tentang migrasi ke Compose, dan kami berharap bisa berbagi lebih banyak hal tentang eksperimen dan peningkatan yang akan kami kerjakan dalam Architecture Blueprints.
Jika Anda tertarik melihat Blueprints dengan kode Compose, lihat cabang dev-compose. Dan jika Anda ingin melihat PR dari migrasi bertahap, berikut daftarnya:
Diposting oleh Marwa Mabrouk, Android Camera Platform Product Manager
Kamera Android adalah bidang yang menarik. Kamera merupakan salah satu alasan utama konsumen membeli ponsel. Kamera Android sekarang mendukung developer melalui berbagai alat. Camera 2 adalah API framework yang disertakan dalam Android sejak Android 5.0 Lollipop, dan CameraX adalah library dukungan Jetpack yang berjalan di atas Camera 2, dan tersedia untuk semua developer Android. Solusi ini dimaksudkan untuk saling melengkapi dalam memenuhi kebutuhan ekosistem Kamera Android.
Untuk developer yang mulai dengan Kamera Android, memperbarui aplikasi mereka ke versi terbaru, atau memigrasikan aplikasi mereka dari Camera 1, CameraX adalah alat terbaik untuk memulai! CameraX menawarkan manfaat penting untuk mendukung developer, dan mengatasi kompleksitas ekosistem.
Bagi developer yang membangun fungsionalitas sangat khusus dengan Kamera untuk kontrol tingkat rendah dari alur pengambilan gambar, dengan mempertimbangkan variasi perangkat, seharusnya menggunakan Camera 2.
Camera 2 adalah API umum yang memungkinkan hardware kamera di setiap perangkat Android dan digunakan di miliaran perangkat Android di seluruh dunia yang ada di pasaran saat ini. Sebagai API framework, Camera 2 memungkinkan developer memanfaatkan pengetahuan mendalam mereka tentang fotografi dan implementasi perangkat. Untuk memastikan kualitas Camera 2, produsen perangkat menunjukkan kepatuhan dengan menguji perangkat mereka. Variasi perangkat muncul di API berdasarkan pilihan produsen perangkat, sehingga fitur khusus bisa memanfaatkan variasi tersebut pada perangkat tertentu sesuai keinginan mereka.
Untuk lebih memahaminya, mari kita gunakan sebuah contoh. Kami akan membandingkan kemampuan pengambilan kamera. Camera 2 menawarkan kontrol khusus dari pipeline pengambilan gambar individual untuk masing-masing kamera di ponsel pada saat yang sama, selain setelan manual yang sangat mendetail. CameraX memungkinkan pengambilan gambar resolusi tinggi dan berkualitas tinggi, serta menyediakan fungsionalitas keseimbangan putih otomatis, eksposur otomatis, dan fokus otomatis, selain kontrol kamera manual yang mudah.
Pertimbangan contoh aplikasi: Samsung menggunakan Camera Framework API untuk membantu sistem kamera kelas profesional yang canggih untuk mengambil foto berkualitas studio dalam berbagai pencahayaan dan setelan pada perangkat Samsung Galaxy. Meskipun API ini bersifat umum, Samsung telah mengaktifkan variasi yang unik untuk setiap kemampuan perangkat, dan memanfaatkannya di aplikasi kamera pada setiap perangkat. Camera Framework API memungkinkan Samsung menjangkau kemampuan kamera tingkat rendah, dan menyesuaikan aplikasi native untuk perangkat
Contoh lain, Microsoft memutuskan untuk mengintegrasikan CameraX pada semua aplikasi produktivitas yang menggunakan Microsoft Lens (yaitu Office, Outlook, OneDrive), untuk memastikan penggunaan gambar berkualitas tinggi di semua aplikasi ini. Dengan beralih ke CameraX, tim Microsoft Lens tidak hanya dapat meningkatkan pengalaman developernya dengan melihat API yang lebih sederhana, tetapi juga meningkatkan performa, meningkatkan produktivitas developer, dan mempercepat waktu untuk memasuki pasar. Anda bisa mempelajarinya lebih lanjut di sini.
Ini adalah waktu yang sangat menarik untuk Kamera Android, dengan banyak fitur baru di kedua API:
Seiring pengembangan, kami berencana membagikan lebih banyak detail kepada Anda tentang fitur menarik yang telah kami rencanakan untuk Kamera Android. Kami nantikan partisipasi dan masukan Anda, melalui milis CameraX: camerax-developers@android.com dan issue tracker AOSP.
Terima kasih atas minat Anda pada Kamera Android, dan kami berharap dapat membangun pengalaman kamera luar biasa bagi pengguna yang berkolaborasi dengan Anda!
Diposting oleh Max Bires, Software Engineer
Pengesahan sebagai fitur telah dimandatkan sejak Android 8.0. Seiring rilis yang datang dan pergi, kepercayaan menjadi semakin penting untuk berbagai fitur dan layanan seperti SafetyNet, Kredensial Identitas, Kunci Mobil Digital, dan berbagai library pihak ketiga. Mengingat hal tersebut, inilah saatnya kami meninjau kembali infrastruktur pengesahan untuk memperketat keamanan rantai kepercayaan kami dan meningkatkan kepercayaan pemulihan perangkat jika ada kerentanan yang telah diketahui.
Mulai Android 12.0, kami akan menyediakan opsi untuk mengganti penyediaan kunci pribadi dalam pabrik dengan kombinasi ekstraksi kunci publik dalam pabrik dan penyediaan sertifikat over the air (OTA) dengan sertifikat jangka pendek. Skema ini akan dimandatkan dalam Android 13.0. Kami menyebut skema baru ini Remote Key Provisioning.
Produsen perangkat tidak akan lagi menyediakan kunci pribadi pengesahan secara langsung ke perangkat di pabrik, bebannya lebih ringan karena tidak perlu mengelola rahasia pengesahan di pabrik.
Dijelaskan lebih lanjut di bawah ini, format, algoritme, dan panjang rantai sertifikat dalam pengesahan akan berubah. Jika pihak yang mengandalkannya telah menyiapkan kode validasi sertifikat agar sesuai dengan struktur rantai sertifikat lama, maka kode ini harus diupdate.
Dua faktor motivasi utama yang mengubah cara kami menyediakan sertifikat pengesahan ke perangkat adalah agar perangkat bisa dipulihkan setelah dirusak dan memperketat supply chain pengesahan. Dalam skema pengesahan saat ini, jika sebuah model perangkat ternyata dirusak dengan cara yang memengaruhi sinyal kepercayaan pengesahan, atau jika kunci bocor melalui suatu mekanisme, maka kunci tersebut harus dicabut. Karena semakin banyak layanan yang mengandalkan sinyal kunci pengesahan, hal ini bisa berdampak besar pada konsumen yang perangkatnya terpengaruh.
Perubahan ini memungkinkan kami menghentikan penyediaan ke perangkat yang menggunakan software yang diketahui telah dirusak, dan menghapus potensi kebocoran kunci yang tidak disengaja. Hal ini akan sangat membantu mengurangi potensi gangguan layanan untuk pengguna.
Pasangan kunci statis unik dihasilkan oleh setiap perangkat, dan bagian publik dari pasangan kunci ini diekstraks oleh OEM di pabriknya. Kunci publik ini kemudian diupload ke server Google, di sana mereka berfungsi sebagai dasar kepercayaan untuk penyediaan nantinya. Kunci pribadi tidak pernah meninggalkan lingkungan aman yang menghasilkannya.
Bila telah dibuka dari kemasannya dan terhubung ke internet, perangkat akan menghasilkan permintaan penandatanganan sertifikat untuk kunci yang telah dihasilkannya, yang menandatanganinya dengan kunci pribadi sesuai dengan kunci publik yang dikumpulkan di pabrik. Server backend akan memverifikasi keaslian permintaan dan kemudian menandatangani kunci publik, dengan mengembalikan rantai sertifikat. Keystore akan menyimpan rantai sertifikat ini, menetapkannya ke aplikasi setiap kali pengesahan diminta.
Aliran ini akan terjadi secara teratur setelah berakhirnya sertifikat atau habisnya pasokan kunci saat ini. Skema ini menjaga privasi karena setiap aplikasi menerima kunci pengesahan yang berbeda, dan kunci diedarkan secara teratur. Selain itu, server backend Google tersegmentasi sedemikian rupa sehingga server yang memverifikasi kunci publik perangkat tidak akan melihat kunci pengesahan yang dilampirkan. Ini berarti Google tidak mungkin menghubungkan kembali kunci pengesahan ke perangkat tertentu yang memintanya.
Pengguna akhir tidak akan melihat perubahan apa pun. Developer yang memanfaatkan pengesahan perlu memperhatikan perubahan berikut:
