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

Pengantar Komponen Arsitektur Android

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Android Architecture Components.
Android Architecture Components: Lifecycle and LiveModel

Malay (Melayu) translation by Said bin Al Musayyib (you can also view the original English article)

Android diperkenalkan ke dunia pada tahun 2005, dan selama 12 tahun keberadaannya, platform itu telah mencapai kejayaan yang luar biasa, menjadi mobile OS paling banyak dipasang. Selama itu, 14 versi berbeda dari operasi sistem sudah ada diluncurkan, dengan Android selalu menjadi lebih matang. Namun, kawasan yang sangat penting dari platform terus dilepaskan: pola arsitektur standar, yang mampu menangani kekhasan platform dan cukup sederhana untuk dipahami dan diadopsi oleh pengembang menengah.

Nah, lebih baik terlambat daripada tidak pernah. Pada Google I / O terakhir, Android akhirnya memutuskan untuk mengatasi masalah ini dan menanggapi umpan balik dari pengembang di seluruh dunia, mengumumkan pengundian resmi untuk Aplikasi Android Arsitektur dan memberikan bangunan blok untuk menerapkannya: komponen Arsitektur baru Dan lebih baik lagi, mereka berhasil melakukannya tanpa mengorbankan keterbukaan sistem yang kita semua kenal dan cintai.

Architecture Components

Dalam tutorial ini, kami akan mengeksplorasi arsitektur standard yang diusulkan oleh Android team di Google I / O dan melihat elemen utama dari baru ViewModel Komponen: Lifecycle , ViewModel , LifeData , dan Room . Kami tidak akan terlalu memperhatikan kod itu, tetapi fokus pada konsep dan logika di balik tema itu. Kami juga akan melihat beberapa cuplikan sederhana, semuanya ditulis menggunakan Kotlin, bahasa yang menakjubkan yang sekarang didukung secara rasmi oleh Android.

1. Adakah Android hilang?

Jika anda baru saja memulakan perjalanan sebagai pengembang, mungkin anda tidak tahu apa yang sedang saya bicarakan. Bagaimanapun, aplikasi arsitektur boleh menjadi tema yang tidak jelas pada awalnya. Tapi percayalah, anda akan segera belajar kepentingannya! Selagi aplikasi tumbuh dan menjadi lebih kompleks, arsitekturnya akan semakin penting. Ini benar-benar boleh membuat karya anda menjadi kebahagiaan atau situasi yang sangat tidak menyenangkan

Aplikasi Arsitektur

Mengempatkannya secara kira-kira, aplikasi arsitektur adalah rencana yang konsisten yang perlu dibuat sebelum proses pembangunan dimulai. Rencana ini menyediakan peta bagaimana komponen aplikasi yang berbeza harus diatur dan diikat bersama. Ia menyajikan panduan yang harus diikuti selama proses pengembangan dan memaksa beberapa pengorbanan (biasanya berkaitan dengan kelas dan boilerplate) yang pada akhirnya akan membantu Anda membangun aplikasi yang ditulis dengan baik yang lebih dapat diuji, dapat diperluas, dan dapat dipertahankan.

Perisian aplikasi architecture adalah proses untuk menentukan struktur penyelesaian yang memenuhi semua keperluan teknikal dan pengendalian, apabila mengoptimalkan sifat umum atribut seperti kinerja, keamanan, dan manajemen. Ia melibatkan serangkaian keputusan berdasarkan berbagai faktor, dan masing-masing keputusan ini dapat memberikan dampak yang besar terhadap kualitas, kinerja, kemampuan pemeliharaan, dan keberhasilan aplikasi secara keseluruhan.
- Panduan Perisian dan Arsitektur Microsoft Software

Arsitektur yang baik memerlukan banyak faktor untuk dipertimbangkan, terutamanya sistem ciri dan batasan. Terdapat banyak arsitektur penyelesaian yang berbeza di luar sana, semuanya dengan pro dan kontra. Namun, beberapa konsep kunci bersifat umum di antara semua penglihatan.

Kesalahan lama

Sampai Google I / O terakhir, sistem Android tidak mengesyorkan khusus Arsitektur untuk aplikasi pembangunan. Itu bermakna anda benar-benar bebas untuk mengadopsi model apa pun di luar sana: MVP, MVC, MVPP, atau tidak ada pola sama sekali. Di samping itu, kerangka kerja Android bahkan tidak memberikan asal penyelesaian untuk masalah yang dibuat oleh sistem sendiri, khususnya komponen hidup komponen.

Great news at the Google IO 2017

Oleh itu, jika anda ingin menerapkan pola Model View Presenter pada aplikasi anda, anda harus menemukan solusi sendiri dari null, menulis banyak boilerplate kode, atau mengadopsi perpustakaan tanpa dukungan resmi. Dan bahawa tidak ada standar yang diciptakan banyak aplikasi yang ditulis dengan buruk, dengan codebases yang sulit untuk mempertahankan dan uji.

Seperti yang saya katakan, keadaan ini telah dikritik selama bertahun-tahun. Sebenarnya, saya baru saja menulis mengenai masalah ini dan bagaimana mengatasinya di blog saya seri Cara Mengadopsi View View Model pada Android . Tetapi yang penting adalah setelah 12 tahun yang panjang, Android akhirnya memutuskan untuk mendengarkan keluhan kami dan membantu kami mengatasi masalah ini.

2. Arsitektur Android

Panduan Arsitektur Android baru mendefinisikan beberapa prinsip kunci bahwa aplikasi android yang baik harus sesuai dan juga mengusulkan jalan yang aman bagi pengembang untuk membuat aplikasi yang bagus. Namun, panduan tersebut secara eksplisit menyatakan bahwa rute yang diajukan tidak wajib, dan akhirnya keputusannya bersifat pribadi; pengembang yang harus memutuskan mana jenis arsitektur yang harus diadopsi.

Menurut panduan, aplikasi Android yang bagus harus memberikan pemisahan keprihatinan pepejal dan UI pemacu dari model. Setiap kod yang tidak menangani UI atau operasi sistem interaksi seharusnya tidak berada dalam Aktiviti atau Fragmen, karena menjaga mereka agar tetap bersih akan memungkinkan Anda mengelakkan banyak masalah yang berkaitan dengan kehidupan siklus. Lagipula, sistem dapat menghancurkan Aktivitas atau Fragmen kapan saja. Di samping itu, data harus ditangani oleh model yang diisolasi dari UI, dan akibat dari kitar hayat masalah.

Arsitektur Baru yang Disarankan

Arsitektur yang direkomendasikan Android tidak boleh dengan mudah dicap di antara standard yang kita kenal. Ini kelihatan seperti Model View Controller, tetapi sangat dikaitkan dengan sistem arsitektur sehingga sulit memberi label pada setiap elemen menggunakan konvensi yang diketahui. Ini tidak relevan, kerana yang terpenting adalah bergantung pada komponen baru untuk menciptakan perpisahan perhatian, dengan kemampuan testability dan maintainability yang bagus. Dan lebih baik lagi, mudah untuk diimplementasikan.

Untuk memahami apa yang tim Android usulkan, kita harus mengetahui semua unsur-unsur Arsitektur Komponen, kerana mereka yang akan melakukan pengangkatan berat untuk kita. Terdapat empat komponen, masing-masing dengan ruang spesifik, Room , ViewModel , LiveData , dan Lifecycle . Semua bahagian itu ada tanggung jawab sendiri, dan mereka bekerja sama untuk menciptakan yang kuat. Mari kita lihat diagram yang disederhanakan dari arsitektur yang diusulkan untuk lebih memahaminya.

Android Architecture

Seperti yang boleh anda lihat, kami mempunyai tiga elemen utama, masing-masing mempunyai tanggung jawab.

  1. Activity dan Fragment mewakili View lapisan, yang tidak berkaitan dengan logika perniagaan dan operasi yang kompleks. Ia hanya mengonfigurasi tampilan, mengurus pengguna interaksi, dan yang terpenting, pengamatan dan menunjukkan elemen LiveData yang diambil dari ViewModel
  2. ViewModel mengamati Lifecycle paparan keadaan, menjaga konsistensi sepanjang perubahan konfigurasi dan acara hayat peranti Android lainnya. Hal ini juga dituntut oleh tampilan untuk mengambil data dari Repository , yang disediakan sebagai LiveData yang dapat diamati. Penting untuk difahami bahawa ViewModel tidak pernah  View langsung dan mengemas kini data yang selalu dilakukan oleh LiveData kesatuan.
  3. Repository bukan komponen Android khusus. Ia adalah kelas sederhana, tanpa pelaksanaan tertentu, yang bertanggung jawab untuk mengambil data dari semua sumber yang tersedia, dari database ke web layanan. Ia menangani semua data ini, secara umum mengubahnya menjadi LiveData yang terlihat dan membuat mereka tersedia untuk ViewModel .
  4. Room Pangkalan Data adalah perpustakaan pemetaan SQLite yang memfasilitasi proses berurusan dengan pangkalan data. Secara automatik ia menulis satu ton boilerplate, memeriksa kesalahan pada masa kompilasi, dan yang terbaik, ia dapat langsung mengembalikan query dengan LiveData yang terlihat.

Saya yakin anda telah memperhatikan bahawa kami telah banyak membicarakan perkara yang dapat diperhatikan. Pola Pengamat adalah salah satu dasar dari elemen LiveData dan komponen Lifecycle sedar. Pola ini membolehkan suatu objek untuk memberitahu pengamat senarai mengenai perubahan status atau data. Jadi ketika sebuah Kegiatan mengamati entitas LiveData , ia akan menerima pembaruan ketika data tersebut mengalami modifikasi.

Lain-lain Android Rekomendasi adalah mengkonsolidasikan arsitekturnya dengan menggunakan Sistem Ketergantungan Suntikan , seperti Google Dagger 2 atau menggunakan  Service Locator (yang jauh lebih sederhana dari DI, tetapi tanpa banyak keuntungan). Kami tidak akan membahas DI atau Perkhidmatan Locator dalam tutorial ini, tetapi Envato Tuts + mempunyai beberapa tutorial bagus tentang tema itu. Namun, maklum ada beberapa kekhilafan yang bekerja dengan Dagger 2 dan Android Components yang akan dijelaskan di bagian kedua dari seri ini.

3. Komponen arsitektur

Kita harus terjun jauh ke dalam aspek komponen baru agar dapat benar-benar mengerti dan mengadopsi model arsitektur ini. Namun, kami tidak akan membahas semua detail dalam tutorial ini. Kerana kompleksitas masing-masing elemen, dalam tutorial ini, kita akan membicarakan gagasan umum di belakang masing-masing komponen dan melihat beberapa kode cuplikan yang disederhanakan. Kami akan cuba untuk mempersembahkan komponen dan membuat anda mulakan. Tapi jangan takut, karena artikel kedepannya di seri ini akan menggali lebih jauh dan mencakup semua kekhasan Arsitektur Komponen.

Siklus Hidup Komponen-Sedar

Sebagian besar komponen aplikasi Android membuat siklus hidup melekat padanya, yang dikelola secara langsung oleh sistem sendiri. Sampai saat ini, semuanya menyerah pada pengembang untuk memantau komponen keadaan dan bertindak sesuai dengannya, menginisialisasi dan mengakhiri tugas tepat waktu. Namun, sangat mudah untuk menjadi bingung dan membuat kesalahan terkait dengan jenis operasi ini. Tetapi paket android.arch.lifecycle mengubah semua itu.

Sekarang, Kegiatan dan Fragmen membuat objek Lifecycle hidupan pada mereka yang dapat dilihat oleh LifecycleObserver kelas, seperti ViewModel atau objek yang mengimplementasikan antara muka ini. Itu bermakna pengamat akan menerima pembaruan mengenai perubahan keadaan objek yang dilihatnya, seperti saat Aktivitas dihentikan sementara atau saat dimulai. Ia juga dapat memeriksa keadaan objek yang diamati saat ini. Jadi sekarang lebih mudah menangani operasi yang harus mempertimbangkan kerangka kerja kerangka kerja.

LifecycleObserver reacts to LifecycleEvents

Untuk saat ini, membuat Activity atau Fragment sesuai dengan standard baru ini, anda harus memperluas LifecycleActivity atau LifecycleFragment . Namun, mungkin saja hal ini tidak akan selalu diperlukan, karena tim Android bertujuan mengintegrasikan sepenuhnya alat baru ini dengan kerangka kerjanya ..

 LifecycleObserver menerima Lifecycle acara dan boleh bereaksi melalui anotasi. Tiada kaedah penggantian yang diperlukan.

Komponen LiveData

Komponen LiveData adalah data pendudukan yang mengandungi nilai yang terlihat. Mengingat bahawa pengamat telah menyediakan Lifecycle selama Instansiasi LiveData , LiveData akan melakukan behavior menurut Lifecycle status. Sekiranya Lifecycle status DIMULAI atau DILANJUTKAN , pengamat menjadi aktif ; Jika tidak, tidak akan aktif .

LiveData mengetahui kapan data berubah dan juga jika pengamatnya aktif dan harus menerima pembaruan. Karakteristik lain yang menarik dari LiveData adalah bahawa ia mampu menghapus pengamat jika ia berada di Lifecycle.State.DESTROYED keadaan, hindari memori leak saat diamati oleh Kegiatan dan Fragment.

LiveData value updating process

LiveData harus menerapkan kaedah onActive dan onInactive .

Untuk mengamati komponen LiveData , anda harus memanggil observer(LifecycleOwner, Observe<T>)

Komponen ViewModel

Salah satu kelas terpenting dari baru Arsitektur Komponen adalah ViewModel , yang ViewModel untuk menyimpan data yang berhubungan dengan UI, menjaga integritas selama perubahan konfigurasi seperti layar rotasi. ViewModel mampu ViewModel dengan Repository , mendapatkan LiveData darinya dan menjadikannya tersedia pada gilirannya untuk dilihat oleh View. ViewModel juga tidak perlu melakukan panggilan baru ke Repositori perubahan konfigurasi, yang mengoptimalkan banyak kod

ViewModel is tight to UI Lifecycle

Untuk membuat paparan model, rentangkan kelas ViewModel .

Untuk mengakses dari satu paparan, Anda boleh memanggil ViewProviders.of(Activity|Fragment).get(ViewModel::class.Metode pabrik ini akan mengembalikan contoh baru ViewModel atau dapatkan yang ada, jika sesuai.

Room Komponen

Android menyokong SQLite sejak awal; Namun, untuk membuatnya bekerja, selalu perlu menulis banyak boilerplate. Juga, SQLite tidak menyimpan POJO (objek Java biasa-biasa saja), dan tidak memeriksa kueri pada saat kompilasi. Seiring datang Room untuk membongkar masalah ini! Ini adalah perpustakaan pemetaan SQLite, yang mampu menahan POJO Jawa, langsung mengubah kueri ke objek, memeriksa kesalahan pada kompilasi waktu, dan menghasilkan pengamatan LiveData dari hasil pencarian. Room adalah perpustakaan Pemetaan Objek  dengan beberapa tambahan Android yang keren.

Sampai sekarang, anda bisa melakukan sebagian besar dari kemapuam Room dalam menggunakan perpustakaan ORM Android lainnya. Namun, tidak satu pun dari mereka secara resmi didukung dan yang paling penting, mereka tidak dapat memproduksi hasil LifeData . Pustaka Room sebagai lapisan gigih pada Android Architecture yang dicadangkan.

Untuk membuat Room Pangkalan data, anda memerlukan @Entity untuk bertahan, yang boleh dijadikan POJO Java, interface @Dao untuk membuat input dan output query dan output, dan kelas abstrak @Database yang harus diperluas RoomDatabase .

Menambah Arsitektur Komponen ke Proyek Anda

Untuk saat ini, untuk menggunakan komponen baru, anda harus terlebih dahulu menambahkan repositori Google ke file build.gradle blog. anda. Untuk lebih jelasnya, lihat panduan resmi .

Kesimpulan

Seperti yang dapat anda lihat, arsitektur standar yang diusulkan oleh Android melibatkan banyak konsep. Jangan berharap untuk mempunyai pemahaman yang lengkap mengenai topik ini. Bagaimanapun, kami hanya mengenali temanya. Tetapi sekarang anda sudah memiliki cukup pengetahuan untuk memahami logika di belakang arsitektur dan peran yang berbeda dari Arsitektur.

Kami membicarakan sebahagian besar topik yang berkaitan dengan arsitektur Android yang diajukan dan komponennya; Namun, rincian tentang penerapan Komponen dan beberapa tambahan, seperti kelas Repository dan sistem Dagger 2 tidak dapat ditangani oleh bagian pertama ini. Kami akan mengeksplorasi tema itu di posting seterusnya.

Sampai jumpa lagi!

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.