На проектах с таким подходом я периодически вижу например следующее - сначала переходим на экран, потом начинаем запрашивать данные, и тут выясняется, что данных-то нет по каким-то причинам, и приходится возвращаться куда-то на предыдущий экран.
Я тоже сталкивался с такой реализацией. Но такой подход хоть и допустимый, но строго не рекомендуемый со стороны Apple. Я тщательно его избегаю, если это вообще возможно.
Хотя правильным решением было бы показать loading на предыдущем экране (в вашем случае это какой-то рутовый экран), потом показать alert с ошибкой - без переходов.
Совершенно верно. Если использовать команды DeepLink Service без получения входящего URL, то внутри самой команды, осуществляется загрузка данных из персистивного хранилища (CD/SD) или из сети, а потом происходит активация координатора. В случае необходимости - UI перенаправляется на координатор, который содержит Alert.
И как тогда быть со Storage? Сохранять последнюю ошибку и экран, куда нужно вернуться?
P.S. рассматриваю не только deep links, а более общую ситуацию - в том числе, когда нужно просто от одного экрана перейти к другому.
Как видите из предыдущих комментариев задача легко решается без дерганий экранов туда-сюда.
Заметьте, я статьях я не рассматриваю отображение модальных окон, которые, по сути, и являются алертами. Прежде всего потому, что они не входят в StackNavigation иерархию. У меня они отображаются в отдельном ZStack слое от имени той сущности, которая инициирует ошибку (Команда DeepLink или ViewModel).
Вы, видимо, недостаточно вникли в код. Здесь не три маршрута, а три разделенных координатора. Если каждый координатор содержит 18 экранов, то Вы получаете 54! (факториал) уникальных роута. Можете играть в блек-джек.
Вложенные enum используются чтоб разбить координатор на несколько частей. В прошлых частях я писал - что когда количество экранов в приложении несколько сотен - это вызывает очень большие проблемы по сопровождению кода, особенно, когда над кодом работают несколько разработчиков.
Я не вижу никакой ценности в том, чтоб ограничивать View входящим типом модели. Тем более, что вью не использует модель напрямую, а передает ее во вью-модель. Так пусть вью-модель несет ответственность за тип обрабатываемых данных - в строго типизированной среде обобщенные данные будут всегда иметь нужный тип.
А вот в том, чтоб исключить ошибку при парсинге строкового пути я вижу очень высокую ценность, в особенности, если этот путь формируется строкой на стороне сервера. Если пренебрегать этим, то возможен диапазон негативных сценариев от провала навигации до креша приложения в продакшине по вине банальной опечатки бэкенд разработчика.
Согласен с тем, что координатор очень удобен для перемещения при помощи DeepLink. Но в своих проектах я использую несколько иной подход для реализации DeepLinks - каждый переход представлен объектом, который содержит в себе команду вызова координатора. Т. е. менеджер DeepLink ничего не знает о пути навигации - он вызывает команду, которая сохраняет параметры и вызывает, в свою очередь, координатор с нужным шагом.
Либо откусить последний элемент от массива, либо в путь засеттить конкретный экран: Допустим, есть путь. path == ["first", "second", "third", "fourth"]
Либо откусываем "fourth" model.path = ["first", "second", "third"] Либо сеттим "third" model.path = ["third"]
Не уверен, что понял вопрос. Массив - потому что нужно было реализовать функциональность стека. Так как коллекция "стек" в Swift отсутствует, то проще всего было использовать именно массив. В целом - это можно делать по-разному. Если вопрос касался ContainerView, то потому, для инициализации массива мы не можем использовать View или some View.
Вопрос 2: при описанном подходе мы отказываемся от стандартных анимаций переходов между экранами (и от модальных презентаций), а значит должны реализовать кастомные, верно?
Точно такую анимацию как это делается при использовании UINavigationViewController в UIKIt сделать не получается. Но достаточно добавить .transition(.move(edge: .trailing)) к "навигационному вью" и .transition(.move(edge: .bottom)) - для модального окна - чтоб получить схожее поведение.
Бонус: предлагаю заменить @ObservedObject на @StateObject внутри struct ContentView, ...
Согласен. Для данного примера @StateObject подходит лучше.
Здесь правильно сказали до меня, что технология deprecated. Однако, MS пропагандируют новую итерацию: Microsoft Flow (совместно с Office 365). Вообще говоря, вещь была сногсшибательная, но как всегда, MS пустила весь курятник с курами несущими золотые яйца под нож.
Разумеется. Только Вы, как автор сервиса, можете ответить на вопрос, нужно ли это делать. Любые формы пассивизации лучше чем хранение данных в оперативной памяти. Но тут Вам нужно учесть накладные расходы — не будет ли это затратно по времени, или не будет ли это трудоемко по сопровождению. К примеру, если Вам нужно обслуживать профиль пользователя, то не обязательно сохранять его в CoreData. Но, для списков или объектов, которые должны быть доступны между сессиями — пассивизация и восстановление — предпочтительней, чем загрузка из сети и использование в виде сервисов. Локатор сервисов — это не серебряная пуля. Он удобен, но не может покрыть весь скоп задач мобильной разработки.
Не согласен с Вами. Действительно, у сторибордов были детские болезни во времена до iOS 9. Но, сейчас — против сторибордов больше предубеждений чем реальных причин их не использовать. Хотя и случаев их неправильного использования тоже очень велико. Начиная с iOS13 я не уверен, в том, что это следует делать, так как еще не разбирался с SwiftUI, но в этом промежутке — их преимущества неоспоримы, но это тема отдельной статьи.
Добавлю к ответу endymion:
Как правило, клиентское приложение точно знает базовый адрес, и, соотвественно, получает ресурс (путь) относительно него. Тогда же, когда путь определен не относительно базового адреса, а «за пределами домена адресов» использование прямой ссылки более оправдано, чем прикручивание HATEOAS к велосипеду.
Выглядит как машина состояний, применительно к ACID транзакциям. Windows Flow решает те же самые задачи (не только он), причем делая транзакции не просто «не локальными», а даже, распределенными во времени.
Удивило, что нет возможности бесплатной работы микрокоманд (до 10 человек). Такие команды платную версию, как правило, покупать не будут (нет средств не столько на продукт, сколько на обеспечение работы бухгалтерии) и, скорее всего, рассмотрят альтернативные варианты, наподобие Trello.
В заголовке статьи и в тегах ни слова не говорится о том, что речь идет о сервер-сайд разработке. Как применить этот подход в рамках клиентских приложний, положим, для .Net Core (через pipe-WCF) я представляю. Но вот как делать это для мобильных приложений на Obj-C / Swift — ума не приложу. Посыл — делить все на Фреймворки и библиотеки — вряд ли можно назвать сколько бы то ни было ООП подходом. Да, можно использовать глобальные оповещения, но это треш еще больший чем «монолитная» но сбалансированная архитектура.
Потому что enum дает однозначный маппинг строки, который опирается на название константы.
Я тоже сталкивался с такой реализацией. Но такой подход хоть и допустимый, но строго не рекомендуемый со стороны Apple. Я тщательно его избегаю, если это вообще возможно.
Совершенно верно. Если использовать команды DeepLink Service без получения входящего URL, то внутри самой команды, осуществляется загрузка данных из персистивного хранилища (CD/SD) или из сети, а потом происходит активация координатора. В случае необходимости - UI перенаправляется на координатор, который содержит Alert.
Как видите из предыдущих комментариев задача легко решается без дерганий экранов туда-сюда.
Заметьте, я статьях я не рассматриваю отображение модальных окон, которые, по сути, и являются алертами. Прежде всего потому, что они не входят в StackNavigation иерархию. У меня они отображаются в отдельном ZStack слое от имени той сущности, которая инициирует ошибку (Команда DeepLink или ViewModel).
Вы, видимо, недостаточно вникли в код. Здесь не три маршрута, а три разделенных координатора. Если каждый координатор содержит 18 экранов, то Вы получаете 54! (факториал) уникальных роута. Можете играть в блек-джек.
Вложенные enum используются чтоб разбить координатор на несколько частей. В прошлых частях я писал - что когда количество экранов в приложении несколько сотен - это вызывает очень большие проблемы по сопровождению кода, особенно, когда над кодом работают несколько разработчиков.
Я не вижу никакой ценности в том, чтоб ограничивать View входящим типом модели. Тем более, что вью не использует модель напрямую, а передает ее во вью-модель. Так пусть вью-модель несет ответственность за тип обрабатываемых данных - в строго типизированной среде обобщенные данные будут всегда иметь нужный тип.
А вот в том, чтоб исключить ошибку при парсинге строкового пути я вижу очень высокую ценность, в особенности, если этот путь формируется строкой на стороне сервера. Если пренебрегать этим, то возможен диапазон негативных сценариев от провала навигации до креша приложения в продакшине по вине банальной опечатки бэкенд разработчика.
Вся же статья посвящена именно этому вопросу.
В iOS это делается через Organizer. Раздел Crashes.
Согласен с тем, что координатор очень удобен для перемещения при помощи DeepLink. Но в своих проектах я использую несколько иной подход для реализации DeepLinks - каждый переход представлен объектом, который содержит в себе команду вызова координатора. Т. е. менеджер DeepLink ничего не знает о пути навигации - он вызывает команду, которая сохраняет параметры и вызывает, в свою очередь, координатор с нужным шагом.
Конечно.
Либо откусить последний элемент от массива, либо в путь засеттить конкретный экран:
Допустим, есть путь.
path == ["first", "second", "third", "fourth"]
Либо откусываем "fourth"
model.path = ["first", "second", "third"]
Либо сеттим "third"
model.path = ["third"]
Не уверен, что понял вопрос. Массив - потому что нужно было реализовать функциональность стека. Так как коллекция "стек" в Swift отсутствует, то проще всего было использовать именно массив. В целом - это можно делать по-разному.
Если вопрос касался ContainerView, то потому, для инициализации массива мы не можем использовать View или some View.
Точно такую анимацию как это делается при использовании UINavigationViewController в UIKIt сделать не получается. Но достаточно добавить .transition(.move(edge: .trailing)) к "навигационному вью" и .transition(.move(edge: .bottom)) - для модального окна - чтоб получить схожее поведение.
Согласен. Для данного примера @StateObject подходит лучше.
Да, совершенно верно.
Вам не кажется, что компенсирующая транзакция - это не транзакция вообще? Просто хотя бы потому, что противоречит ACID.
https://docs.microsoft.com/en-us/dotnet/framework/windows-workflow-foundation/
https://habr.com/ru/company/luxoft/blog/181562/
https://ru.wikipedia.org/wiki/Windows_Workflow_Foundation
https://balka-book.com/programmirovanie-v-net-401/osnovyi_windows_workflow_foundation-1334
Здесь правильно сказали до меня, что технология deprecated. Однако, MS пропагандируют новую итерацию: Microsoft Flow (совместно с Office 365).
Вообще говоря, вещь была сногсшибательная, но как всегда, MS пустила весь курятник с курами несущими золотые яйца под нож.
Как правило, клиентское приложение точно знает базовый адрес, и, соотвественно, получает ресурс (путь) относительно него. Тогда же, когда путь определен не относительно базового адреса, а «за пределами домена адресов» использование прямой ссылки более оправдано, чем прикручивание HATEOAS к велосипеду.