Использование Enum + Associated Values при навигации и передаче данных между экранами в IOS приложениях

В этом посте мне бы хотелось затронуть извечный вопрос об организации навигации и передачи данных между экранами в IOS приложениях. В первую очередь, я хотел бы донести концепт своего подхода, а не убедить вас использовать его как волшебную таблетку. Тут не будут рассматриваться различные архитектурные подходы или возможность использования UlStoryboard с segues, в целом я опишу еще один возможный способ достигнуть желаемого со своими плюсами и минусами. И так, начнем!

Предыстория:

Безусловно, на реализацию навигации и организацию транспорта данных в проекте влияет выбор архитектурного подхода, однако и сам подход складывается из ряда обстоятельств: состав команды, time to market, состояние ТЗ, масштабируемость проекта и многое др., определяющими факторами для меня стали:

• обязательное использование MVVM;
• возможность быстро добавлять новые экраны(контроллеры, и их вью модели) в процесс навигации;
• изменения в бизнес- логике не должны затрагивать навигацию;
• изменения в навигации не должны затрагивать бизнес-логику;
• возможность быстро переиспользовать экраны без внесения исправлений в навигацию;
• возможность быстро получить представление о существующих экранах;
• возможность быстро получить представление о зависимостях в проекте;
• не повысить порог вхождения разработчиков на проект.

Ближе к делу

Стоит отметить, что конечное решение было сформировано не за один день, не лишено своих минусов и подходит скорее для маленьких и средних проектов. Для наглядности, тестовый проект можно посмотреть тут: github.com/ArturRuZ/NavigationDemo

1. Чтобы была возможность быстро получить представление о существующих экранах было принято решение завести enum с однозначным названием ControllersList.

enum ControllersList {    case textInputScreen    case textConfirmationScreen }

2. По ряду причин в проекте не хотелось использовать сторонние решения для DI, a DI получить хотелось, в том числе с возможностью быстрого просмотра зависимостей в проекте, поэтому было решено использовать Assembly для каждого отдельного экрана (закрытого протоколом Assembly) и RootAssembly – в качестве общего scope.

 protocol Assembly {    func build() -> UIViewController }  final class TextInputAssembly: Assembly {    func build() -> UIViewController {       let viewModel = TextInputViewModel()       return TextInputViewController(viewModel: viewModel)    } }  final class TextConfirmationAssembly: Assembly {    private let text: String        init(text: String) {       self.text = text    }        func build() -> UIViewController {       let viewModel = TextConfirmationViewModel(text: text)       return TextConfirmationViewController(viewModel: viewModel)    } } 

3. Для передачи данных между экранами(там, где это действительно необходимо) ControllersList превратился в enum с Associated Values:

enum ControllersList {    case textInputScreen    case textConfirmationScreen(text: String) }

4. Для того чтобы ни бизнес-логика не влияла на навигацию, ни навигация на бизнес-логику, а также для быстрого переиспользования экранов, потребовалось навигацию вынести в отдельный слой. Так появился Coordinator и протокол Coordination:

 protocol Coordination {    func show(view: ControllersList, firstPosition: Bool)    func popFromCurrentController() }  final class Coordinator {        private var navigationController = UINavigationController()    private var factory: ControllerBuilder?        private func navigateWithFirstPositionInStack(to: UIViewController) {       navigationController.viewControllers = [to]    }    private func navigate(to: UIViewController) {       navigationController.pushViewController(to, animated: true)    } }  extension Coordinator: Coordination {    func popFromCurrentController() {       navigationController.popViewController(animated: true)    }    func show(view: ControllersList, firstPosition: Bool) {       guard let controller = factory?.buildController(for: view) else { return }                  firstPosition ?  navigateWithFirstPositionInStack(to: controller) : navigate(to: controller)    } }  

Тут важно отметить, что протокол может описывать больше методов, в т.ч. как и Coordinator может реализовывать различные протоколы, в зависимости от нужд.

5. При всем при этом, хотелось еще и ограничить набор действий, которые требовалось совершить разработчику, добавляя новый экран в приложение. На текущий момент требовалось помнить о том, что где-то надо прописать зависимости, и возможно сделать еще какие-либо действия для того чтобы навигация заработала.

6. Совсем не хотелось создавать дополнительные роутеры и координаторы. Более того, создание дополнительной логики для навигации могло значительно усложнить как восприятие навигации, так и переиспользование экранов. Все это привело к цепочке изменений, которые в конечном итоге выглядели следующим образом:

 //MARK - Dependences with controllers associations fileprivate extension ControllersList {    typealias scope = AssemblyServices       var assembly: Assembly {       switch self {       case .textInputScreen:          return TextInputAssembly(coordinator: scope.coordinator)       case .textConfirmationScreen(let text):          return TextConfirmationAssembly(coordinator: scope.coordinator, text: text)       }    } }  //MARK - Services all time in memory fileprivate enum AssemblyServices {    static let coordinator: СoordinationDependencesRegstration = Coordinator()    static let controllerFactory: ControllerBuilderDependencesRegistration = ControllerFacotry() }  //MARL: - RootAssembly Implementation final class  RootAssembly {    fileprivate typealias scope = AssemblyServices       private func registerPropertyDependences() { //     this place for propery dependences    } }   // MARK: - AssemblyDataSource implementation extension RootAssembly: AssemblyDataSource {    func getAssembly(key: ControllersList) -> Assembly? {       return key.assembly    } } 

Теперь при создании нового экрана, разработчику достаточно было просто внести изменения в ControllersList, а далее компилятор уже сам показывал, где надо еще внести изменения. Добавление новых экранов в ControllersList никак не влияли на текущую схему навигации, а логика управления зависимостями легко прослеживалась. Также, используя ControllersList, можно легко найти все точки вхождения в тот или иной экран, а переиспользовать экраны стало просто.

Заключение

Данный пример является упрощенной реализацией идеи и не покрывает всех кейсов использования, тем не менее сам подход показал себя достаточно гибким и адаптивным.

Из недостатков данного подхода можно выделить следующее:

• Сложно сказать, что координатор в этой реализации действительно координатор, больше это напоминает роутер с областью видимости на весь проект. Также ControllersList можно переименовать в NavigationEvents, а сами кейсы на похожий мотив, но это скорее вопрос восприятия;
• В ряде случаев, наоборот хочется ограничить возможную навигацию и тогда разумнее использовать роутеры и координаторы;
• Возможно могут быть кейсы, которые не покрывает данное решение, или оно потребует глобального переосмысления. В любом случае, перед использованием такого подхода следует оценить потенциальные риски и проблемы для вашего проекта.

Большая часть постов о навигации и передачи данных в IOS приложениях затрагивает либо использования координаторов и роутеров (на каждый или группу экранов), либо навигацию через segue, singleton и т.п., но не один из этих вариантов не подходил мне по тем или иным причинам.

Возможно и вам для решения задач подойдет такой подход, спасибо за уделённое время!