Massive View Controller - IOS - Solusi


16

Saya yakin setiap pengembang iOS baru memiliki masalah berikut: View Controllers menjadi sangat cepat penuh dengan kode untuk berbagai keperluan, dengan mudah mencapai 500 + baris kode.

Begini tampilannya untuk dua layar dasar dan umum:

1) Layar Formulir: masukkan deskripsi gambar di sini

2) Layar Pengontrol Tampilan Tabel masukkan deskripsi gambar di sini

Sejauh ini saya telah membaca tentang dua solusi berbeda:

  1. Solusi Pertama: https://bendyworks.com/single-responsibility-principle-ios/ . Ini didasarkan pada Pemberitahuan, itu sepenuhnya memisahkan View Controller dari Model View (Intentions) dan dengan demikian mengurangi kode di View Controller. Saya pikir itu memiliki kelemahan dari pemecahan kode, mirip dengan struktur Go-To. Ini terlihat seperti ini: masukkan deskripsi gambar di sini

  2. Solusi kedua menjaga View Controllers yang penuh sesak (aksi tombol dijalankan di dalam VC dan sebagainya). tetapi menggunakan perpustakaan seperti TPKeyboardAvoiding , BlocksKit atau solusi lain yang kebanyakan berdasarkan kategori. Dengan solusi kedua ini, kode berkurang secara drastis tetapi pengontrol tampilan masih memiliki banyak tanggung jawab.

Apa pendapat Anda tentang solusi ini? Mana yang lebih baik? Apakah ada yang lebih baik?


5
Saya tidak bisa memberikan jawaban yang baik karena waktu, tetapi ini harus mengarahkan Anda ke arah yang benar.
Mike D

Tujuan saya adalah mengumpulkan sebanyak mungkin jawaban yang baik untuk akhirnya mengatasi masalah ini yang dimiliki oleh banyak pengembang baru. Terima kasih untuk tautannya, jika saya menemukan sesuatu yang baru, saya pasti akan mempostingnya di sini.
Ravul

Inilah ceramah hebat tentang berkelahi dengan pengontrol tampilan gemuk oleh Andy Matuschak https://realm.io/news/andy-matuschak-refactor-mega-controller/
Tomasz Bąk

Jawaban:


6

Kami dapat menggunakan MVVM untuk menyelesaikan masalah ini.

Model-View-ViewModel, atau pola MVVM seperti yang umum dikenal, adalah pola desain UI. VM mengambil semua logika tentang mempersiapkan data model untuk UI dari VC.

Contoh:
Anda punya objek model dengan beberapa bidang, Anda ingin memformat beberapa di antaranya, membuat perhitungan dan menggabungkannya.

Dalam kasus MVC semua logika itu terletak di ViewController.
Di MVVM Anda memindahkan semuanya dari VC ke VM.

VM akan menyiapkan semua data untuk UI dan VC hanya mengaturnya seperti ini.

(di kelas VC)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Tutorial dan topik:


3
Sementara ini secara teoritis dapat menjawab pertanyaan, akan lebih baik untuk memasukkan bagian-bagian penting dari jawaban di sini, dan menyediakan tautan untuk referensi.
Bart van Ingen Schenau

Saya setuju dengan Bart. Jika tidak ada orang lain yang memposting ringkasan dari semua metode ini, saya akan membuatnya segera setelah saya mengerti dan menguji semuanya.
Ravul

2
@Ravul memperbarui jawaban
kaspartus

Saya telah memilih kembali jawaban Anda dan terima kasih atas gagasan ini. Saya hanya membaca tentang Pemrograman Reaktif Fungsional dan sepertinya ide yang bagus. Saya pikir jawaban untuk pertanyaan ini adalah enumerasi, dengan beberapa kelebihan, kekurangan dan setidaknya satu diagram konseptual untuk 4 cara berikut untuk mendekati masalah: 1) Kakao Reaktif 2) KVO 3) Metode pendelegasian dan 4) Cara klasik menulis View Controller. Saya akan menulisnya segera setelah saya menguji semua metode ini jika tidak ada orang lain yang melakukannya sebelum saya. Jika saat ini saya menemukan cara baru, itu lebih baik.
Ravul

3

Saya harus mengurai kode dalam View Controllers berukuran besar sebelumnya dan itu benar-benar menghambat kemampuan saya untuk menavigasi konten pada awalnya. Satu hal penting yang saya sadari adalah bahwa ukuran saja dari View Controller tidak cukup alasan untuk memecah hal-hal. Ada kerumitan dalam memiliki 1 file besar dan juga kompleksitas dalam memiliki banyak file kecil. Berikut adalah beberapa alasan yang sah untuk refactor untuk memecah View Controller menjadi bagian-bagian yang lebih kecil:

MVC

View Controller seharusnya tidak melakukan lebih dari menjadi perekat penghubung antara View dan Model. Jika Anda memiliki banyak kode koneksi jaringan, kode manipulasi gambar, dll, maka pertimbangkan untuk memecahnya menjadi kelas pembantu.

Kontrol Berganda dengan View Controller sebagai sumber data

Jika Anda memiliki banyak kontrol di layar yang memiliki View Controller Anda sebagai sumber data, pertimbangkan memecahnya menjadi objek sumber data yang terpisah dan menjadikannya sebagai sumber data. Atau Anda juga dapat memecahnya menjadi View Controllers yang terpisah (seperti jika Anda View Controller memiliki tampilan tabel selain controller lainnya, Anda dapat memecahnya ke dalam kelas Table View Controller sendiri).

Kode Gandakan

Jika Anda memiliki kode yang sama persis di berbagai Pengontrol Tampilan, masukkan di 1 lokasi bersama. Itu akan membuat kode Anda dapat digunakan kembali dan membantu mengelola kompleksitas.

Berikut adalah beberapa saran tambahan untuk meminimalkan kompleksitas View Controller:

Storyboard bukan Programmatic

Menciptakan elemen Tampilan adalah banyak kode dan bingkai kode geometri banyak pekerjaan juga. Jika belum mempertimbangkan menggunakan batasan tata letak otomatis dan menempatkan sebanyak mungkin elemen Tampilan di storyboard.

Kode / komentar yang tidak perlu

Pastikan juga untuk menghapus kode / komentar yang tidak perlu. Banyak kali file View Controller baru akan datang dengan metode yang tidak Anda gunakan. Jika Anda tidak menggunakan metode sepertididReceiveMemoryWarning itu maka aman untuk mengeluarkannya. Juga, karena file View Controller sangat besar kadang-kadang menakutkan untuk menghapus kode atau komentar lama. Jangan menunda itu! Itu hanya menambah kompleksitas.

Notifikasi

Untuk menjawab pertanyaan Anda tentang notifikasi: Notifikasi bukan Golden Hammer untuk digunakan dengan segalanya. Saya menemukan notifikasi berguna ketika beberapa Pengontrol Tampilan perlu memperbarui pada saat yang sama karena 1 tindakan tertentu. Berhati-hatilah dengan notifikasi, menggunakannya secara berlebihan dapat menyebabkan Anda merasa sangat sakit saat mencoba melacaknya.


2

Ada satu arsitektur khusus yang mereka sebut VIPER (View, Interactor, Presenter, Entity, dan Routing). Saya akan mencoba melanjutkan di sini apa yang perlu Anda ketahui:

Melihat

  • mereka adalah pandangan bodoh;
  • berisi objek seperti UIView, UIViewController, UILabel, dll;
  • menunggu konten dari Presenter ;
  • menangani interaksi pengguna dan meneruskannya ke lapisan Presenter .

Pembawa acara

  • tidak tahu objek UI;
  • dapatkan input dari Lihat lapisan;
  • menangani view logic (metode add akan menampilkan layar lain);

Rute

  • menangani logika navigasi dan animasi transisi;
  • tahu objek seperti UINavigationController, UIWindow, dll;

Jadi, apa yang saya pikir Anda akan bersihkan dalam kode Anda:

  • validasi data akan pindah ke lapisan Presenter ;

  • navigasi akan pindah ke objek Wireframe ( Routing layer);

  • pisahkan pengontrol tampilan Anda dengan memperhatikan prinsip KERING ;

  • Layar yang kompleks akan memiliki dua Tampilan dan Penyaji.

Anda harus melihat tautan ikuti tentang arsitektur VIPER http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

Semoga beruntung!


1
Apakah arsitektur ini berfungsi untuk aplikasi kecil? Sepertinya Anda harus membuat banyak objek untuk memperkenalkannya ke proyek.
Tomasz Bąk

ya, saya setuju bahwa itu lebih banyak objek daripada MVC tradisional tetapi layak. Anda dapat melihat satu contoh sederhana yang saya buat tahun ini github.com/orafaelreis/cascavel Cascavel seperti proyek dasar untuk menginisialisasi proyek VIPER.
orafaelreis

Luar biasa! Arsitektur VIPER tampaknya dirancang tepat untuk menghindari masalah pengontrol tampilan besar-besaran.
Christophe
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.