Контролер масивного перегляду - IOS - Рішення

Я впевнений, що у кожного нового розробника iOS є така проблема: Контролери перегляду дуже швидко переповнюються кодом для різних цілей, легко отримуючи 500 + рядків коду.

Ось як це виглядає для двох основних і загальних екранів:

1) Екран форми:

2) Екран контролера подання таблиці

Поки що я читав про два різні рішення:

1. Перше рішення: https://bendyworks.com/single-responsibility-principle-ios/ . Це засновано на сповіщеннях, він повністю відокремлює контролер перегляду від моделі (наміри) і таким чином зменшує код у контролері подання. Я думаю, що він має і зворотній бік порушення коду, подібний до структур Go-To. Це виглядає приблизно так:

2. Друге рішення зберігає ті ж переповнені контролери перегляду (дії кнопок виконуються всередині VC тощо). але використовує такі бібліотеки, як TPKeyboardAvoiding , BlocksKit або інші рішення, більшість з яких засновані на категоріях. За допомогою цього другого рішення код різко зменшується, але контролер перегляду все ще несе велику відповідальність.

Що ви думаєте про ці рішення? Який краще? Чи є кращий?

Ми можемо використовувати MVVM для вирішення цієї проблеми.

Модель-View-ViewModel або MVVM-зразок, як це відомо, - це модель дизайну інтерфейсу. VM бере всю логіку щодо підготовки модельних даних для інтерфейсу користувача від VC.

Приклад: У
вас є об’єкт моделі з деякими полями, ви хочете відформатувати деякі з них, зробити обчислення та об'єднати їх.

У випадку MVC вся ця логіка знаходиться у ViewController.
У MVVM ви переміщуєте все це з VC на VM.

VM підготує всі дані для інтерфейсу користувача, а VC просто встановлює його так.

(у класі ВК)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Підручники та теми:

• Вступ до МВВМ
• Підручник з MVVM з ReactiveCocoa
• Шаблони дизайну iOS: MVC та MVVM

Мені раніше доводилося розкручувати код у контролерах великого розміру, і це спочатку перешкоджало моїй здатності орієнтуватися по вмісту. Одне важливе, що я зрозумів, це те, що лише розмір контролера перегляду не був достатньою причиною, щоб розбити речі. Є складність у тому, щоб мати 1 великий файл, а також складність у купі невеликих файлів. Ось декілька поважних причин, щоб Refactor розбити контролер перегляду на більш дрібні частини:

MVC

Контролер перегляду не повинен робити більше, ніж бути клеєм, що з'єднує між Поглядом і Моделью. Якщо у вас багато коду підключення до мережі, код маніпулювання зображенням тощо, тоді подумайте про їх розбиття на допоміжні класи.

Кілька елементів керування за допомогою контролера перегляду як джерела даних

Якщо у вас є набір елементів керування на екрані, у яких ваш Контролер подання даних є джерелом даних, розгляньте можливість їх розбиття на окремі об’єкти джерела даних, і вони повинні бути джерелом даних. Або ви також можете розбити їх на окремі контролери перегляду (наприклад, якщо ви переглядаєте контролер перегляду таблиць на додаток до іншого контролера, ви можете розбити його на власний клас контролера табличного перегляду).

Дублікат коду

Якщо у вас є однаковий код у різних контролерах перегляду, розмістіть його в одному спільному місці. Це зробить ваш код багаторазовим і допоможе керувати складністю.

Ось кілька додаткових порад щодо мінімізації складності перегляду контролера:

Розмальовка замість програмної

Створення елементів перегляду - це багато коду, а геометрія кадру - це також велика робота. Якщо ви вже не розглядаєте можливість використання обмежень щодо автоматичного планування та розміщення якомога більшої кількості елементів перегляду в дошці розкадрування.

Непотрібний код / ​​коментарі

Також обов’язково видаліть непотрібний код / ​​коментарі. Багато разів новий файл Контролера перегляду буде надходити з методами, які ви не використовуєте. Якщо ви не використовуєте подібний метод, didReceiveMemoryWarningто його безпечно вийняти. Крім того, оскільки файл контролера перегляду настільки великий, іноді страшно видаляти старий код або коментарі. Не відкладайте цього! Це лише додає складності.

Сповіщення

Щоб відповісти на ваше запитання щодо сповіщень: сповіщення - це не Золотий молоток, який можна використовувати з усім. Я вважаю сповіщення корисним, коли кілька контролерів перегляду потрібно оновлювати одночасно через 1 певну дію. Будьте уважні до сповіщень, однак, надмірне використання їх може заподіяти вам багато болю, намагаючись відстежити їх.

Є одна особлива архітектура, яку вони називають VIPER (Перегляд, Інтерактор, Презентатор, Сутність та Маршрутизація). Я спробую відновити тут те, що вам потрібно знати:

Вид

• вони манекени;
• містять такі об'єкти, як UIView, UIViewController, UILabel тощо;
• чекає вмісту від ведучого ;
• обробляти взаємодію з користувачем та передавати його на шар Presenter .

Ведучий

• не знає об’єктів інтерфейсу;
• отримувати входи з шару View ;
• обробляти логіку перегляду (метод додавання представить інший екран);

Маршрутизація

• обробляти логіку навігації та анімацію переходу;
• знає такі об'єкти, як UINavigationController, UIWindow тощо;

Отже, що я думаю, ви очистите у своєму коді:

• перевірка даних буде переміщена до рівня Presenter ;

• навігація переміститься до об'єктів Wireframe ( шар маршрутизації );

• розділити контролер перегляду, дотримуючись принципу DRY ;

• Складні екрани матимуть два чи більше переглядів та презентацій.

Ви повинні побачити наступне посилання про архітектуру VIPER http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

Удачі!