BLE очевидное решение. Но, 1) BLE отсутствует на борту МК esp8266. 2) Удаленно, конфигурацию BLE Вы не поменяете. 3) Основной смысл разработки - в ведении реестра устанавливаемых контроллеров и анализа их состояний. BLE, для этих целей не подходит.
На проектах с таким подходом я периодически вижу например следующее - сначала переходим на экран, потом начинаем запрашивать данные, и тут выясняется, что данных-то нет по каким-то причинам, и приходится возвращаться куда-то на предыдущий экран.
Я тоже сталкивался с такой реализацией. Но такой подход хоть и допустимый, но строго не рекомендуемый со стороны 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 решает те же самые задачи (не только он), причем делая транзакции не просто «не локальными», а даже, распределенными во времени.
Вы, видимо, не прочитали статью или не поняли ее смысл и цель проекта.
BLE очевидное решение. Но,
1) BLE отсутствует на борту МК esp8266.
2) Удаленно, конфигурацию BLE Вы не поменяете.
3) Основной смысл разработки - в ведении реестра устанавливаемых контроллеров и анализа их состояний. BLE, для этих целей не подходит.
Потому что 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 к велосипеду.