MVP (Model View Presenter) di Android

Basis kode yang bersih selalu menyenangkan untuk digunakan. Basis kode yang terorganisir dengan baik mudah dipelihara, kuat, berkinerja baik, dapat diuji, dan dapat didokumentasikan sendiri. Memilih arsitektur untuk Android bisa jadi rumit, namun dalam tutorial ini, Anda akan melihat satu cara untuk mencapai basis kode yang bersih menggunakan MVP , kependekan dari Model - View - Presenter . Anda juga akan mempelajari bagaimana pola ini cocok dengan ekosistem Android.

Dalam tutorial ini, Anda akan membuat aplikasi bernama Umbrella yang akan menampilkan ikon payung saat ramalan cuaca turun hujan, dan ikon matahari saat cuaca cerah dan cerah di luar. Yang penting di sini adalah, Anda akan memfaktorkan ulang versi awal aplikasi ini, sehingga memanfaatkan penggunaan pola model - view - presenter . Anda juga akan mempelajari bagaimana komponen aplikasi yang difaktorisasi dapat diuji.

MVC: Pendekatan Tradisional

Aplikasi Android yang ditulis secara tradisional terdiri dari tiga komponen utama.

• Model : Model berisi data yang ditampilkan. Biasanya, data ini diambil dari jaringan atau database lokal. Kemudian data tersebut dimasukkan ke dalam kelas-kelas kecil dan sederhana yang dapat digunakan oleh komponen lainnya.
• Tampilan : Tampilan adalah apa yang ditampilkan kepada pengguna. Mereka juga menangani setiap interaksi yang mungkin dimiliki pengguna dengan pendengar layar klik, misalnya. Tampilan seharusnya hanya bertanggung jawab untuk menampilkan sesuatu dan tidak boleh mengandung logika bisnis apa pun. Dengan demikian, tampilan cenderung menjadi komponen yang ringan dibandingkan dengan pengontrol dan biasanya tidak berisi banyak kode. Di Android, tanggung jawab tampilan sering kali jatuh pada aktivitas dan fragmen .
• Pengontrol : Pengontrol adalah cara untuk menghubungkan model dan tampilan bersama-sama. Pengontrol memperbarui model ketika sesuatu terjadi dalam tampilan. Pengontrol juga akan memperbarui tampilan saat model berubah. Terlalu sering, tanggung jawab pengontrol juga ditemukan dalam aktivitas dan fragmen.

Arsitektur ini paling dikenal sebagai MVC. Meskipun akronim ini cenderung identik dengan buruk, ini adalah arsitektur yang telah berfungsi dengan baik tanpa adanya arsitektur apa pun. Namun, itu memang memiliki kekurangan.

Apa Yang Salah Dengan Pendekatan Ini?

Ketika datang untuk mengimplementasikan MVC pada platform Android, banyak hal menjadi rumit. Untuk memulai, sebagian besar logika berakhir di pengontrol. Ini adalah masalah Android yang umum untuk memiliki aktivitas pengontrol yang berisi semua logika. Pengontrol kemudian memiliki semua tanggung jawab atas apa yang ditampilkan di layar. Untuk layar yang sederhana, ini dapat dikelola tetapi, seiring bertambahnya fitur, file ini akan terus berkembang.

Selain itu, aktivitas Android terkait erat dengan UI dan mekanisme akses data. Karenanya, mudah untuk terjebak dalam menempatkan controller dan logika tampilan dalam aktivitas atau fragmen. Ini, bagaimanapun, menciptakan komponen yang berpasangan erat yang membuatnya lebih sulit untuk refaktor dan perubahan.

Lapisan tampilan seharusnya hanya memusatkan perhatian pada tampilan. Seharusnya tidak perlu tahu tentang database atau panggilan jaringan. Selain itu, sulit untuk menguji komponen saat dirangkai dengan erat. Anda harus menguji kode yang ada di pengontrol. Sebagian besar kode yang diuji pada akhirnya harus menjalankan komponen Android SDK, seperti aktivasi, yang memerlukan perangkat atau emulator yang berjalan penuh. Pengujian unit dasar tidak akan membantu; Anda perlu menggunakan pengujian unit berinstrumen yang mahal untuk menguji bagian dasar aplikasi.

MVP: Pendekatan Alternatif

Salah satu alternatif untuk masalah yang disajikan oleh MVC adalah memisahkan beberapa bagian dari satu sama lain. MVP adalah pola arsitektur yang dapat Anda gunakan untuk mengatasi beberapa kekurangan MVC, dan merupakan arsitektur alternatif yang baik. Ini memberikan cara mudah untuk memikirkan tentang struktur aplikasi Anda. Ini memberikan modularitas , kemampuan untuk diuji dan, secara umum, basis kode yang lebih bersih dan dapat dipelihara .

Memilih akronim, MVP terdiri dari komponen-komponen berikut:

• Model : Model akan terus memuat data dalam kelas sederhana, jadi tidak ada yang benar-benar berubah di sini.
• Tampilan : Tampilan akan terus diimplementasikan menggunakan kelas Aktivitas atau Fragmen, tetapi kami akan mengubah cakupan dari kontrol tampilan.
• Presenter: Bagian terakhir adalah presenter, yang menangani pembaruan UI berdasarkan perubahan pada model data, dan juga memproses input pengguna. Presenter akan berisi banyak kode bisnis dan menggantikan pengontrol dari MVC.

Dalam MVP, alih-alih memiliki kelas Aktivitas pengontrol yang menangani perubahan pada model dan apa yang ditampilkan di layar, pengontrol dan bagian tampilan dipisahkan, dan penyaji dan tampilan menjadi lebih ringan.

Data ( model ) dan UI ( view ), hanya berkomunikasi satu sama lain melalui perantara ( penyaji ). The presenter berisi sebagian besar logika bisnis, sementara pandangan berfokus pada bagaimana menampilkan data. Tanggung jawab pengontrol sekarang dibagi antara tampilan dan penyaji. Seorang penyaji menangani aliran data, dan memisahkan logika bisnis dari pengontrol. Kode khusus Android tetap berada di lapisan tampilan, dan penyaji dapat diuji secara terpisah dari Android SDK.

Jadi bagaimana aliran data di antara komponen-komponen ini? Lihat diagram ini:

Di dalam kode, Anda akan melihat antarmuka yang menentukan penyaji dan tampilan. Antarmuka membantu memisahkan bagian-bagian arsitektur. Antarmuka membentuk kontrak antara penyaji dan tampilan. Mereka juga akan membantu Anda menentukan dan menulis kasus uji nanti.

Ketika ada perubahan pada data, penyaji diberi tahu bahwa data telah berubah. Tampilan kemudian akan menerima data itu melalui penyaji dan memperbarui dirinya sendiri menggunakan data dari penyaji. Anda juga bisa pergi ke arah yang berlawanan dengan acara dari tampilan. Saat pengguna berinteraksi dengan tampilan, metode pada penyaji dipanggil. Penyaji kemudian memanggil metode yang sesuai untuk tindakan itu untuk memperbarui model.