Как стать автором
Обновить
19
0

Пользователь

Отправить сообщение

В iOS это делается через Organizer. Раздел Crashes.

Согласен с тем, что координатор очень удобен для перемещения при помощи DeepLink. Но в своих проектах я использую несколько иной подход для реализации DeepLinks - каждый переход представлен объектом, который содержит в себе команду вызова координатора. Т. е. менеджер DeepLink ничего не знает о пути навигации - он вызывает команду, которая сохраняет параметры и вызывает, в свою очередь, координатор с нужным шагом.

Конечно.

Либо откусить последний элемент от массива, либо в путь засеттить конкретный экран:
Допустим, есть путь.
path == ["first", "second", "third", "fourth"]

Либо откусываем "fourth"
model.path = ["first", "second", "third"]
Либо сеттим "third"
model.path = ["third"]

Вопрос 1: почему завернул containered в массив?

Не уверен, что понял вопрос. Массив - потому что нужно было реализовать функциональность стека. Так как коллекция "стек" в Swift отсутствует, то проще всего было использовать именно массив. В целом - это можно делать по-разному.
Если вопрос касался ContainerView, то потому, для инициализации массива мы не можем использовать View или some View.

Вопрос 2: при описанном подходе мы отказываемся от стандартных анимаций переходов между экранами (и от модальных презентаций), а значит должны реализовать кастомные, верно?

Точно такую анимацию как это делается при использовании UINavigationViewController в UIKIt сделать не получается. Но достаточно добавить   .transition(.move(edge: .trailing)) к "навигационному вью" и .transition(.move(edge: .bottom)) - для модального окна - чтоб получить схожее поведение.

Бонус: предлагаю заменить @ObservedObject на @StateObject внутри struct ContentView, ...

Согласен. Для данного примера @StateObject подходит лучше.

Да, совершенно верно.

Вам не кажется, что компенсирующая транзакция - это не транзакция вообще? Просто хотя бы потому, что противоречит ACID.

Здесь правильно сказали до меня, что технология 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 — ума не приложу. Посыл — делить все на Фреймворки и библиотеки — вряд ли можно назвать сколько бы то ни было ООП подходом. Да, можно использовать глобальные оповещения, но это треш еще больший чем «монолитная» но сбалансированная архитектура.
Думаю, Вы ошибаетесь. Этот файл вполне благополучно сейчас работает с cocoapods 1.0.0
HATEOAS и HAL это частные реализации HTTP протокола. Нет нужды подменять ими REST. REST/RESTful повсеместно используется мобильными разработчиками. Поскольку, как правило, мобильный API ограничивается GET и POST запросами, то в тексте упоминается именно REST, а не RESTful, хотя этот факт ни на что не влияет. Кроме того, Вы подменяете HTTP статусы кодами ошибок REST — последние нигде не определены стандартом, и могут меняться разработчиками в широких пределах.
Серверные разработчики могут изменить API таким образом, что его обработка приведет к крешу приложения. Если клиент пишется на готовом API — такая ситуация никогда не возникает. Но вот когда API пишется одновременно с клиентом — такая ситуация возникает сплошь и рядом (заменили поле id на ident). Но даже уже существующее API может вызвать проблему, если, вдруг, отправит вместо int тип double или string. Для языков с нестрогой типизацией это обычное явление.
> Просто попробуйте поработать с git таким способом, и вы увидите, как много времени можно сэкономить.
Вы не поверите сколько времени можно сэкономить если воспользоваться SourceTree или аналогичными инструментами.
Провел 3 недели в Великобритании, в основном, Brodstairs Language School. Ни разу не слышал чтоб кто-то обратился к кому-то по фамилии… Все преподаватели имели на шее бейдж с именами, но без фамилий.
Покажите мне хоть одного пользователя который видел WPF приложение в Appstore. Ну хотя бы на картинке. Я даже не прошу показать само приложение.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность