Comments 2
А можете рассказать, почему не подошли координаторы?
Добрый день!
Там получалась следующая ситуация:
Для добавления нового экрана в конечном итоге требовалось:
— Создать Assembly для этого экрана;
— Создать VewModel и ViewController;
— Добавить все это дело в ControllersList.
В случае с координатором, потребовалось бы создать еще 2 дополнительные сущности:
— Координатор (со своей логикой, которая по сути дублировала бы логику во ViewModel);
— Протокол для координатора.
При появлении дополнительных переходов или необходимости переиспользования экранов это все приходилось бы изменять.
В целом, использование enums показалось более гибким, быстрым и практичным + возможность прикрутить туда координаторы (при необходимости), также осталось.
P.S. я не призываю отказываться от координаторов — с ними код может становится чище и с ViewModel снимается ответственность за принятие решении куда нас отправить дальше. В данном случае, я этим пожертвовал.
Там получалась следующая ситуация:
Для добавления нового экрана в конечном итоге требовалось:
— Создать Assembly для этого экрана;
— Создать VewModel и ViewController;
— Добавить все это дело в ControllersList.
В случае с координатором, потребовалось бы создать еще 2 дополнительные сущности:
— Координатор (со своей логикой, которая по сути дублировала бы логику во ViewModel);
— Протокол для координатора.
При появлении дополнительных переходов или необходимости переиспользования экранов это все приходилось бы изменять.
В целом, использование enums показалось более гибким, быстрым и практичным + возможность прикрутить туда координаторы (при необходимости), также осталось.
P.S. я не призываю отказываться от координаторов — с ними код может становится чище и с ViewModel снимается ответственность за принятие решении куда нас отправить дальше. В данном случае, я этим пожертвовал.
Sign up to leave a comment.
Использование Enum + Associated Values при навигации и передаче данных между экранами в IOS приложениях