📝 Rilis terbaru WorkManager 2.5.0 membuat penggunaan semakin mudah dalam lingkungan multiproses dan memberikan beberapa peningkatan stabilitas.
Jadi jika Anda memiliki aplikasi yang mengelola banyak proses, dan Anda membutuhkan cara yang bisa diandalkan untuk mengelola pekerjaan latar belakang (tidak ada lagi error inisialisasi ️️⚠), maka rilis ini cocok untuk Anda.
Ada beberapa perubahan yang perlu dilakukan pada kode Anda, jadi baca terus untuk mengetahui lebih lanjut.
Di akhir artikel, saya juga akan mencantumkan beberapa perubahan perilaku dan tambahan terbaru dalam versi library WorkManager ini.
Artefak multiproses baru memperkenalkan peningkatan kinerja dengan menyatukan penjadwalan tugas ke satu proses. Untuk memulai, tambahkan ke aplikasi Anda.
Implementation "androidx.work:work-multiprocess:2.5.0"
Sekarang Anda bisa memilih proses yang ditunjuk yang digunakan WorkManager untuk mengantrekan WorkRequests, dan menjalankan penjadwal dalam-prosesnya.
Konfigurasi yang menggunakan Configuration.Provider bisa terlihat seperti ini.
class MyApplication() : Application(), Configuration.Provider { override fun getWorkManagerConfiguration() = Configuration.Builder() .setProcessName("com.example:remote") .build()}
Catatan: Parameter pada setProcessName mengharuskan Anda untuk memberikan nama proses yang memenuhi syarat, yang terdiri dari nama paket aplikasi, diikuti oleh titik dua, dan kemudian nama proses host, mis. com.example:remote.
Saat menggunakan pekerjaan-multiproses, Anda juga perlu menggunakan RemoteWorkManager sebagai ganti WorkManager untuk mengelola permintaan pekerjaan. RemoteWorkManager akan selalu menjangkau proses yang ditunjuk untuk mengantrekan pekerjaan Anda. Ini memastikan bahwa Anda tidak melakukan inisialisasi WorkManager baru secara tidak sengaja dalam proses pemanggil. Penjadwal dalam-proses juga berjalan dalam proses yang ditunjuk yang sama.
Dengan WorkManager yang dikonfigurasi seperti ini dan menggunakan RemoteWorkManager untuk menjadwalkan tugas, pekerjaan Anda bisa dikelola dengan lebih cepat dan andal di aplikasi multiproses. Ini karena konflik SQLite bisa sangat berkurang (karena kita tidak lagi mengandalkan kunci berbasis file) dan rekonsiliasi tugas di seluruh proses tidak akan diperlukan lagi karena aplikasi Anda hanya akan memiliki satu instance WorkManager yang berjalan dalam proses yang Anda tentukan.
Sebelumnya, ketika ActivityManager tidak dapat membuat instance JobService untuk memulai tugas, tugas itu akan dihentikan secara diam-diam karena bug mendasar di platform. WorkManager sekarang memastikan bahwa ada tugas penjadwal cadangan untuk setiap WorkRequest ketika sebuah instance Application dibuat dengan merekonsiliasi objek WorkRequest dengan tugas.
Kami melihat bahwa salah satu penyebab aplikasi tidak bekerja adalah karena perangkat kehabisan penyimpanan. Ini terjadi terutama pada perangkat yang memiliki sedikit ruang penyimpanan. Namun, ketika aplikasi menjadwalkan banyak pekerjaan, WorkManager bertanggung jawab sebagian atas perangkat yang kehabisan ruang penyimpanan.
Secara default, tugas yang diselesaikan dicatat dalam database WorkManager internal selama 7 hari. Waktu ini dikurangi menjadi 1 hari, yang secara dramatis mengurangi ukuran database.
Meskipun kami mempersingkat durasi buffering, Anda bisa mengontrol seberapa lama tugas diingat dengan menggunakan keepResultsForAtLeast() API.
Jika Anda menggunakan ListenableFuture dengan WorkManager, maka pengujian menjadi lebih mudah — ekstensi Kotlin TestListenableWorkerBuilder sekarang menerima kelas apa pun yang memperluas ListenableWorker, sehingga Anda bisa lebih fleksibel selama pengujian.
Selain fitur baru, rilis ini juga berisi beberapa perbaikan bug yang meningkatkan stabilitas, keandalan, dan kinerja WorkManager. Anda bisa membaca semua perubahan serta perbaikan bug di catatan rilis.
WorkManager, serta beberapa library Jetpack lainnya, bisa menerima kontribusi melalui GitHub.
Alan Viverette menulis postingan blog komprehensif tentang keseluruhan proses.
Sebagian besar bug yang telah diperbaiki dalam rilis 2.5.0 didapat melalui input dari issue tracker publik.
Cara terbaik untuk membuat masalah yang bisa kita perbaiki adalah dengan membuat masalah yang dapat kita reproduksi. Untuk membantu kami mereproduksi masalah, kami menyarankan Anda menggunakan contoh WorkManager atau memberikan kode contoh Anda sendiri dengan petunjuk dalam deskripsi masalah.
Sekarang adalah waktu yang tepat untuk mulai bekerja dan mengelola pembaruan versi library di aplikasi Anda.
No comments :
Post a Comment