Добрый день! Спасибо за хороший комментарий. Постараюсь тезисно ответить:
1. Можно, зависит от вас и вашего дизайна.
2. Сам показ алертов — не проблема. История была больше про создание процесса восстановления из ошибок. Это может быть удобно если у вас приложение достаточно слоистое — вы можете спокойно передавать ошибку между разными уровнями, в которой содержится все, чтобы из нее восстановится, когда это понадобится. Возможно, я недостаточно качественно донес эту мысль.
3. Действительно, довольно легко найти активный контролер. Все будет работать. Могут быть следующие корнер кейсы:
— Если вы используете контролер не на полный экран — он может вполне отобразится в нем. Допустим кастомные всплывающее окно. У нас есть кейс с выдвижной по свайпу панелькой. Она занимает 3/4 экрана, это считается верхний контролер и показывается Алерт в нем
— Сейчас не могу проверить, но вроде можно по ошибке найти childViewController как верхний контролер и он тоже будет не на весь экран
Отдельное окно — способ избежать таких проблем. Аналогично рекомендуется поступать при отображении push-уведомлений внутри приложения.
4. Здесь зависит от ваших критериев качества и приоритетов. В некоторых сейчас популярных доставках еды из-за нагрузки я вижу requestTimeOut, ошибки URL и ошибки парсинга данных. Я бы на месте менеджеров хотел бы этого избежать, свести к более нейтральным и общим формулровкам.
5. Звучит разумно для случая полного отсуствия сети/авиарежима. Я под internetError понимал группу ошибок, в которую входит requestTimeOut и всякие ошибки из-за нестабильности сети. Для них tryAgain имеет смысл, так как сеть может вернутся вот прям сейчас.
Проверка applicationDidBecomeActive — является хорошим тоном.
Добавлю — у нас есть обсервинг состояния сети. Допустим мы не смогли загрузить ленту. При восстановлении соединения мы перезапрашвиаем данные и без участия пользователя обновляем интерфейс.
6. Да, удобного API для проверки нет. Тем не менее — есть несколько обходных способов, они за рамками данной статьи.
Прикольно! Не знал, что Джордж Лукас был владельцем Pixar. Интересно, как он мог проморгать их технологии, если использовал для своих фильмов 🤔
1. Можно, зависит от вас и вашего дизайна.
2. Сам показ алертов — не проблема. История была больше про создание процесса восстановления из ошибок. Это может быть удобно если у вас приложение достаточно слоистое — вы можете спокойно передавать ошибку между разными уровнями, в которой содержится все, чтобы из нее восстановится, когда это понадобится. Возможно, я недостаточно качественно донес эту мысль.
3. Действительно, довольно легко найти активный контролер. Все будет работать. Могут быть следующие корнер кейсы:
— Если вы используете контролер не на полный экран — он может вполне отобразится в нем. Допустим кастомные всплывающее окно. У нас есть кейс с выдвижной по свайпу панелькой. Она занимает 3/4 экрана, это считается верхний контролер и показывается Алерт в нем
— Сейчас не могу проверить, но вроде можно по ошибке найти childViewController как верхний контролер и он тоже будет не на весь экран
Отдельное окно — способ избежать таких проблем. Аналогично рекомендуется поступать при отображении push-уведомлений внутри приложения.
4. Здесь зависит от ваших критериев качества и приоритетов. В некоторых сейчас популярных доставках еды из-за нагрузки я вижу requestTimeOut, ошибки URL и ошибки парсинга данных. Я бы на месте менеджеров хотел бы этого избежать, свести к более нейтральным и общим формулровкам.
5. Звучит разумно для случая полного отсуствия сети/авиарежима. Я под internetError понимал группу ошибок, в которую входит requestTimeOut и всякие ошибки из-за нестабильности сети. Для них tryAgain имеет смысл, так как сеть может вернутся вот прям сейчас.
Проверка applicationDidBecomeActive — является хорошим тоном.
Добавлю — у нас есть обсервинг состояния сети. Допустим мы не смогли загрузить ленту. При восстановлении соединения мы перезапрашвиаем данные и без участия пользователя обновляем интерфейс.
6. Да, удобного API для проверки нет. Тем не менее — есть несколько обходных способов, они за рамками данной статьи.