Каждый раз когда надо обновить данные View запрашивает это у Intent, если нужно до обогатить данные, Intent делает это, если нет тогда сразу передает ивент в Model, тот в свою очередь обновляет данные для показа и View показывает
На каждом шаге, каждый раз необходимо проходить этот круг.
И еще насколько это будет проще по сравнению с двунаправленной архитектурой, где все шаги вы можете обозначить в одном методе?
В двунаправленных архитектурах все эти шаги можно обозначить одной функцией, в однонаправленных нужно делать круг. Как я писал выше это один из моментов критики таких архитектур
2 - потокобезопасности и не должно быть, это сокращение кода работы с userdefault, он по умолчанию не потокобезопасен. Тут уже каждый сделает как удобно, если это нужно, а нужно не всегда. Стоит помнить что потокобезопасность может понижать производительность. Если есть потребность никто не мешает модифицировать ?
Обертку не первый год использую, не в синглтонах (все сваливается и сохраняется в UserDefaults.standard во всех копиях), полет отличный
Если нужно сравнить отдельные части, то этот протокол не подойдет, если нужно сравнить на полное соответствие, а это большинство случаев, то очень хороший способ
Чем глубже и подробнее проработать 1 шаг тем лучше может быть результат. Первый раз, по незнанию, это может занять много времени. Стоит ли ваша идея этого времени? Так как это делается для себя то можно этот шаг весь пропустить или любую его часть.
Да, я рассматривал статью с точки зрения разработчика, у которого есть идея и навыки создания приложений и как, имея такую комбинацию, можно сделать классно. Курсы предпринимательства могут помочь сильно расширить свои горизонты и по другому взглянуть на ситуацию. Спасибо за рекомендацию и комментарий.
Спасибо за отзыв. Кажется что самые высокие затраты уходят на этапе написание кода и продвижения. Если самому писать код то самое весомые затраты будут в продвижении.
Увидел. Когда с одного экрана можно перейти на десяток других и нужно показывать разные Alert, основная View очень сильно «загрязняется», тогда возникает потребность вынести навигацию в отдельный слой Router. Также это снимает обязанность View следить за навигацией и выносит эту обязаность в отдельную сущность, что хорошо (принцип SOLID всегда выручают). Ваш вариант хороший, вопрос «загрязненного» основного View остается.
@StateObject немного изменяет цикл жизни атрибута. Внутри Router, если это надо, использовать можно и нужно. У кого минимальная версия iOS 14, я бы рекомендовал заменить
@ObservedObject private var intent: RootIntent
на
@StateObject private var intent: RootIntent
@StateObject доступен только с iOS 14. Этот значит, не все могут воспользоваться таким вариантом. В статье я писал, и еще раз озвучу, что эта реализация, не единственно верная. Я хотел бы увидеть реализацию на @StateObject.
Когда оставляют замечания и просят поправить то что не относится к задаче, пусть это небольшие правки, это отнимет время разработчика:
Отвлечься от текущей задачи (разработчик теряет контекст и включение обратно может занять 10-15 минут)
Прейти в ветку и поправить код
Сделать сборку проекта и запусти его (убедиться что ничего не поломано)
Это отнимает время других разработчиков, они теряют контекст своей текущей задачи, тратят время на просмотр исправления.
Я отнес этот пункт к социальным аспектам, данные комментарии могут восприниматься негативно разработчиками. Могу добавить что у меня были случаи когда небольшое замечание и быстрая правка в одну строчку влекло большие изменения в проекте, которые никто не увидел, и это приводило к рефакторингу на несколько дней. Не все разработчики могут остановится в процессе рефакторинга и сказать что это не быстрая правка.
И все же, полностью согласен с Вами, это вопрос договоренности. Люди разные и что работает в одной команде, может не работать в другой.
Я не глубоко знаю тему, могу что-то не учесть и что-то не знать. На мой взгляд, у Extreme Programming плюсы ровно в том в чем и минусы.
Социальные аспекты работают всегда. Когда 2 человека работают за 1 компьютером, это сильно социализирует, что должно положительно сказываться на разработке и текучке кадров. Так и наоборот, разработчики могут разругаться в рабочем процессе, или может они не очень хорошо друг к другу относятся, то преимущество такого подхода становится недостатком
Code review помогает найти слабые места и неточности кода, команда с этим справится лучше чем пара, пары не обсуждают централизовано код других пар. На Code review вся команда знает об изменениях, на парном программировании нет. Code review это инструмент куда лучше позволяет следить за кодом.
По бизнес процессам, трогать не будут, определенно в правильном месте это лучший вариант.
Каждый раз когда надо обновить данные View запрашивает это у Intent, если нужно до обогатить данные, Intent делает это, если нет тогда сразу передает ивент в Model, тот в свою очередь обновляет данные для показа и View показывает
View —(событие)—> Intent —(до обогащенное данными событие)—> Model —(новое состояние)—> View
На каждом шаге, каждый раз необходимо проходить этот круг.
В двунаправленных архитектурах все эти шаги можно обозначить одной функцией, в однонаправленных нужно делать круг. Как я писал выше это один из моментов критики таких архитектур
Контейнером мы усложним себе жизнь и какой-то серьезной проблемы не решим. В любом случае, каждый может модифицировать и менять под свои нужды?
Да, про это я не упоминал в статье. Спасибо что подсказали. Поправил статью и расширил код чтобы было удобнее с этим работать
1 - не очень понял, можно подробнее описать
2 - потокобезопасности и не должно быть, это сокращение кода работы с userdefault, он по умолчанию не потокобезопасен. Тут уже каждый сделает как удобно, если это нужно, а нужно не всегда. Стоит помнить что потокобезопасность может понижать производительность. Если есть потребность никто не мешает модифицировать ?
Обертку не первый год использую, не в синглтонах (все сваливается и сохраняется в UserDefaults.standard во всех копиях), полет отличный
Не все такое любят и мой опыт показывает, так мало кто делает, цвета кодом пишут, но это мой опыт
Если нужно сравнить отдельные части, то этот протокол не подойдет, если нужно сравнить на полное соответствие, а это большинство случаев, то очень хороший способ
материала на очень много статей, буду постепенно выкладывать
Так и планировалось, но там есть ограничение на кол. символов. Не все влезает
Чем глубже и подробнее проработать 1 шаг тем лучше может быть результат. Первый раз, по незнанию, это может занять много времени. Стоит ли ваша идея этого времени? Так как это делается для себя то можно этот шаг весь пропустить или любую его часть.
Да, я рассматривал статью с точки зрения разработчика, у которого есть идея и навыки создания приложений и как, имея такую комбинацию, можно сделать классно. Курсы предпринимательства могут помочь сильно расширить свои горизонты и по другому взглянуть на ситуацию. Спасибо за рекомендацию и комментарий.
Спасибо за отзыв и что нашли опечатку. Поправил.
Спасибо за отзыв. Кажется что самые высокие затраты уходят на этапе написание кода и продвижения. Если самому писать код то самое весомые затраты будут в продвижении.
_intent = StateObject(wrappedValue: HomeIntent(model: model))Спасибо, будет полезно. От множественного вызова консруктора, к сожалению, не спасает, но делает работу чуть удобнее.
Поправил статью, убрал про это, чтобы не вводить людей в заблуждение.
@StateObject немного изменяет цикл жизни атрибута. Внутри Router, если это надо, использовать можно и нужно. У кого минимальная версия iOS 14, я бы рекомендовал заменить
@ObservedObject private var intent: RootIntent
на
@StateObject private var intent: RootIntent
Это отнимает время других разработчиков, они теряют контекст своей текущей задачи, тратят время на просмотр исправления.
Я отнес этот пункт к социальным аспектам, данные комментарии могут восприниматься негативно разработчиками. Могу добавить что у меня были случаи когда небольшое замечание и быстрая правка в одну строчку влекло большие изменения в проекте, которые никто не увидел, и это приводило к рефакторингу на несколько дней. Не все разработчики могут остановится в процессе рефакторинга и сказать что это не быстрая правка.
И все же, полностью согласен с Вами, это вопрос договоренности. Люди разные и что работает в одной команде, может не работать в другой.
Социальные аспекты работают всегда. Когда 2 человека работают за 1 компьютером, это сильно социализирует, что должно положительно сказываться на разработке и текучке кадров. Так и наоборот, разработчики могут разругаться в рабочем процессе, или может они не очень хорошо друг к другу относятся, то преимущество такого подхода становится недостатком
Code review помогает найти слабые места и неточности кода, команда с этим справится лучше чем пара, пары не обсуждают централизовано код других пар. На Code review вся команда знает об изменениях, на парном программировании нет. Code review это инструмент куда лучше позволяет следить за кодом.
По бизнес процессам, трогать не будут, определенно в правильном месте это лучший вариант.