Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Android SDK
Code

Komponen Senibina Android: Lifecycle dan LiveModel

by
Difficulty:IntermediateLength:MediumLanguages:
This post is part of a series called Android Architecture Components.
Introduction to Android Architecture Components
Android Architecture Components: LiveData

Malay (Melayu) translation by Robi'ah Ar Ro'yi (you can also view the original English article)

Di bahagian terakhir siri ini, Pengenalan kepada Komponen Senibina Android kita bercakap mengenai Arkitektur Android yang baru dan mengapa ia telah dibangunkan. Pada asasnya, seni bina baru ini membincangkan beberapa isu Android yang diketahui dengan menawarkan banyak komponen yang dibuat khusus untuk sistem ini. Ia adalah blok bangunan seni bina. Kami telah melihat komponen ini, jadi sudah tiba masanya untuk memahami lebih mendalam.

Dalam tutorial ini, kami akan melihat dengan lebih dekat komponen Komponen Lifecycle dan LiveModel . Apabila kami meneroka ini, kami juga akan menyemak beberapa coretan kod dari aplikasi sampel kerana kami bercakap mengenai paradigma baru Android, rakaman itu dibuat dengan Kotlin yang hebat.

Jika anda tidak tahu Kotlin lagi, jangan takut untuk mengikutinya; Pelaksanaannya sangat dekat dengan Java, dan saya yakin anda boleh memahaminya. Sekiranya anda ingin mengetahui lebih lanjut tentang Kotlin, Jessica Thornsby menulis satu siri yang sangat baik di sini di Tuts + di Coding Aplikasi Android di Kotlin . Anda mesti melihatnya!

Projek Sampel

Kami menyediakan aplikasi kecil yang menunjukkan konsep yang kita sedang bercakap dalam tutorial ini. Nama aplikasi adalah MyWeatherApp , dan ia membolehkan pengguna mengetahui cuaca hari menggunakan nama bandar atau lokasi pengguna semasa. Logik aplikasi cukup mudah, tetapi anda boleh membetulkannya untuk membuat aplikasi anda sendiri.

Sample Application

Seperti yang anda lihat dalam rajah di bawah, seni bina adalah konsisten dengan yang dicadangkan oleh Android, dan kami menggunakan pakej Senibina Komponen yang baru sebanyak mungkin, menjaga perkara yang mudah untuk analisis asas. Sebagai bonus, kami menggunakan Dagger 2 sebagai perpustakaan Injection Depedency. Walau bagaimanapun, kami tidak akan menggali lebih terperinci mengenai pelaksanaannya, kerana ia akan terlepas dari skop tutorial.

The WeatherApplication

Bagaimana cara kerja App?

Permohonan dibuat semudah mungkin. Ia hanya mempunyai satu Aktiviti, di mana pengguna boleh mendapatkan cuaca dengan mencari nama bandar atau menggunakan lokasi semasa peranti. MainActivity memanggil MainModel untuk mendapatkan LiveData dilihat dan bertindak balas kepadanya. MainModel mengambil data cuaca dari MainRepository , dan menggabungkan semua data sebagai LiveData . MainRepository mendapat data dari pelbagai sumber.

Menjalankan Aplikasi Contoh

Muat turun atau klonkan repositori dari repo GitHubc kami dan bangun dengan Gradle atau buka dalam IDE anda. Anda juga harus membuat akaun OpenWeatherMap dan mendapatkan ID aplikasi baru. Tambah ID aplikasi ke sumber rentetan yang dipanggil openWeather .

2. Menyediakan Projek

Oleh kerana Komponen Senibina masih dalam alfa, anda mesti memasukkan repositori Google, yang mengandungi beberapa perpustakaan percubaan, dalam projek build.gradle .

Dalam mod build.gradle , tambahkan yang berikut kepada seksyen dependencies untuk menambah sokongan untuk Lifecycles , LiveData , dan ViewModel :

  • compile "android.arch.lifecycle:runtime:1.0.0-alpha5"
  • compile "android.arch.lifecycle:extensions:1.0.0-alpha5"
  • annotationProcessor "android.arch.lifecycle:compiler:1.0.0-alpha5"

Jika anda menggunakan Kotlin, anda juga harus menambah atau menggantikan annotationProcessor dengan Kapt , yang mengendalikan anotasi pada Kotlin.

Untuk mengaktifkan Kapt , tambahkan kod berikut dalam build.gradle root.

3. Komponen Lifecycle

Setiap pemaju Android sudah biasa dengan konsep kitaran hayat. Sistem ini menggalakkan kitaran hayat Apps, Aktiviti, Fragments, dan sebagainya tanpa kawalan pemaju. Konsep ini adalah salah satu paradigma Android dan, sehingga baru-baru ini, tidak mudah untuk bekerja dengannya, kerana tidak mungkin untuk memeriksa status kitar hayat komponen secara langsung. Apa yang boleh kita lakukan adalah bertindak balas terhadap kaedah tertentu, seperti onCreate dan onDestroy , yang dicetuskan oleh peristiwa kitaran hayat.

Activity Lifecyle

Ini semua telah berubah sejak pengumuman komponen Arkitek Pakej, yang memperkenalkan komponen yang disebut Lifecycle . Sekarang, sesetengah objek Android mempunyai Lifecycle melekat pada mereka, dan perubahan ini banyak untuk pemaju. Adalah mungkin untuk berunding dengan keadaan Lifecycle pada bila-bila masa, dan juga mungkin untuk bertindak balas kepada peristiwa Lifecycle menggunakan anotasi. Malah, tulang belakang komponen Arkitek Android yang baru adalah komponen Lifecycle .

Semua elemen pakej android.arch.lifecycle adalah penting untuk konsep Lifecycle , tetapi dua daripadanya sepatutnya lebih perhatian: LifecycleOwner dan LifecycleObserver . Mereka mewujudkan kemungkinan bekerja dengan Lifecycle , memerhatikan dan bertindak balas terhadap peristiwa yang berlaku dalam Aktiviti, Fragment, Perkhidmatan dan sebagainya.

LifecycleOwner

LifecycleOwner adalah kaedah antara muka tunggal untuk kelas yang mengandungi Lifecycle . Ia mengekstrak pemilikan Lifecycle , yang membolehkan anda menulis komponen yang boleh berfungsi dengannya. Dengan standard baru, Kegiatan dan Fragment adalah LifecycleOwner . Walau bagaimanapun, sehingga versi akhir Komponen Senibina dilancarkan, anda perlu menggunakan beberapa kelas khas: ActivityLifecycle , FragmentLifecycle , dan LifecycleService .

Tiada perubahan ketara dalam pelaksanaan kelas ini apabila dibandingkan dengan Standard Activity and Fragment. Sebaik sahaja kelas dipanjangkan, mereka akan mempunyai Lifecycle dilampirkan, yang boleh diambil pada bila-bila masa dengan kaedah getLifecycle () . Kemungkinan lain yang menarik ialah kita boleh menyemak keadaan asikan kitaran semasa dengan getCurrentState , yang mengembalikan Lifecycle.State .

Terdapat lima keadaan kehidupan Lifecycle berbeza:

  • Diinisialisasi : untuk objek yang dipanggil, tetapi itu tidak "aktif". Ini bersamaan dengan keadaan sebelum kaedah Activity.onCreate .
  • DIBUAT : untuk objek yang baru dibuat. Ini dipanggil selepas kaedah onCreate dan juga dipanggil sebelum kaedah onStop .
  • MEMULAI : dipanggil selepas onStart dan sebelum kaedah onPause .
  • Dilanjutkan : Keadaan aktif atau keadaan semula untuk LifecycleOwner . Dipanggil selepas kaedah onResume .
  • DIHANCURKAN : untuk objek LifecycleOwner dimusnahkan. Lifecycle ini tidak akan menghantar lebih banyak acara. peristiwa ini dicapai sebelum kaedah onDestroy .
LifecycleOwner Events

LifecycleObserver

Salah satu ciri yang paling menarik dalam Lifecycle ialah ia dapat dilihat dengan mudah. Kelas LifecycleObserver boleh melihat komponen LifecycleOwner , seperti Aktiviti dan Fragment. Ia menerima LifecycleOwner.EventS dan boleh bertindak balas kepada mereka menerusi  anotasi @OnLifeCycleEvent(Lifecycle.Event) .

Kaedah yang diterangkan dengan @OnLifecycleEvent tidak memerlukan hujah, tetapi jika digunakan, hujah pertama mesti LifecycleOwner . Apabila anotasi menggunakan Lifecycle.Event.ON_ANY , kaedah ini sepatutnya mengharapkan dua hujah: LifecycleOwner dan Lifecycle.Event .

Untuk membolehkan anotasi @OnLifecycleEvent , LifecycleObserver perlu memberi perhatian kepada Lifecycle , jika tidak, ia tidak akan menerima acara. Untuk membuatnya berfungsi, hubungi Lifecycle.addObserver(LifecycleOwner) dan LifecycleOwner kemudian akan dapat bertindak balas kepada Lifecycle.Event . Ia juga mungkin untuk memanggil Lifecycle.removeObsever(LifecycleObserver) untuk membuang pemerhati

Terdapat pelbagai kes penggunaan yang menarik untuk LifecycleObserver . Sebagai contoh, ia boleh digunakan untuk membuat lapisan Penyampai daripada corak arsitektur Lihat Presenter Model.   Juga boleh digunakan untuk membuat pendengar yang boleh berhenti mendengar apabila Lifecycle dimatikan

4. Komponen LiveModel

Direka untuk bekerja dengan lapisan UI, komponen ViewModelmenutup jurang sedia ada di Android dari awal: menyediakan cara yang elegan untuk mengurus dan menyimpan data objek yang berkaitan dengan paparan. Komponen ini mengekalkan integriti data antara perubahan konfigurasi, boleh dikongsi antara Aktiviti dan Fragment, dan merupakan alat yang sangat baik untuk mengelakkan kebocoran memori.

ViewModel sentiasa dicipta dalam hubungan rapat dengan skop tertentu, sama ada Kegiatan atau Fragment. Skop ini dikekalkan semasa Aktiviti atau Fragmen masih hidup. Secara praktikal, ViewModel menyambung semula dengan paparan selepas perubahan konfigurasi, mempertahankan dirinya sehingga pandangan utama dimusnahkan. Menurut dokumentasi rasmi:

Tujuan ViewModel adalah untuk memperoleh dan menyimpan maklumat yang diperlukan untuk Aktiviti atau Fragment.

Di atas semua, ViewModel memudahkan pemisahan kebimbangan dalam proses pembangunan Android. Dengan menggerakkan semua operasi yang berkaitan dengan data ke komponen ini dan dengan membiarkannya mengendalikan logik, penerapan testability dan maintainability sangat bertambah baik. Dengan ViewModel, mudah untuk mengamalkan Senibina Android yang dicadangkan di Google I/ O 2017. Anda juga boleh menggunakannya untuk menggunakan corak seni bina yang lebih canggih, seperti MVP atau MVVM.

Terapkan ViewModel

Terdapat dua cara untuk melaksanakan ViewModel . Lalai adalah memperluaskan kelas, memberikan pembina tanpa hujah. Ini adalah cara yang paling mudah, tetapi ia tidak berfungsi dengan baik dengan Suntikan Ketergantungan.

Untuk mendapatkan ViewModel dibina dengan teknik ini dari Aktiviti atau Fragment, sila hubungi ViewModelProviders.of(FragmentActivity).get(class<T>). Hujah terakhir harus mengandungi kelas ViewModel. Contoh ViewModel yangsama akan dimuatkan oleh paparan dan akan mengandungi semua data untuk pandangan itu.

Perhatikan bahawa, sejak ViewModel diambil dari kaedah ViewModelProviders.of , pembina tidak boleh menerima hujah. Sebagai penyelesaian, anda boleh memohon Lihat ViewModelProvider.Factory . Malah ini adalah teknik yang sama yang kita gunakan untuk menyertakan ViewModel .

Masukkan ViewModel

Apabila menggunakan DI, perkara menjadi lebih rumit. Anda mesti melaksanakan ViewModelProvider.Factory . Langkah-langkah berikut boleh digunakan untuk memasuki ViewModel dengan menggunakan Dagger. ViewModelFactory adalah kelas utiliti yang menyediakan ViewModel untuk skop

Bagger juga memerlukan @MapKey ditakrifkan untuk ViewModel dan pengikat bagi setiap model dan bagi kilang dalam modulnya

Selepas itu ikuti prosedur Dagger standard dan anda akan dapat membuat ViewModel yang dapat memasuki hujah pada pembangunnya. Untuk membuat contoh baru, dapatkan ViewModelFactory dan ambil ViewModel dikehendaki dari itu.

Dalam projek sampel kami, anda boleh melihat DI dengan menggunakan Dagger. Saya juga menyediakan contoh Folder dalam tutorial GitHub repo dengan coretan yang menunjukkan cara mengkonfigurasi ViewModels pada sistem Dagger menggunakan Kotlin.

Kesimpulannya

Setakat ini, perjalanan kami melalui Komponen Senibina Android yang baru sangat produktif. Bagaimanapun, kita masih banyak perkara untuk dibincangkan. Dalam tutorial seterusnya, kami akan membincangkan komponen LiveData , menyiasat ciri asas dan maju, dan menggunakan konsep ini untuk aplikasi sampel kami.

Lihat awak tidak lama lagi! Dan sementara itu, periksa beberapa jawatan lain kami mengenai perkembangan aplikasi Android!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.