Комментарии 3
По материалу есть ряд вопросов и замечаний:
1. Можно показывать не обычный Alert, а со стилем actionSheet. Он куда интереснее выглядит, позволяя впихнуть приличный список UIAlertAction.
2. Не вижу проблемы в действиях с обычного Alert, а не с кастомной View (если только менеджеры не заставляют выдерживать дизайн). Алерты — естественный способ взаимодействия с системой.
3. Рисовать отдельное окно — ну, странный способ. Он то рабочий, но почему не найти в стеке ViewController тот, который сейчас активен?
4. У NSError есть прекрасный localizedDescription, который отобразит (в большинстве кейсов) адекватное описание ошибки юзеру.
5. Если сеть не доступна, то смысл тыкать «Try Again». Лишнее действие. Лучше предложить пользователю список действий, а при возвращении в приложение (applicationDidBecomeActive), или на конкретный ViewController, перепроверять состояние сети.
P.S. Если верно помню, проверить Airplane Mode просто так не получится.
1. Можно показывать не обычный Alert, а со стилем actionSheet. Он куда интереснее выглядит, позволяя впихнуть приличный список UIAlertAction.
2. Не вижу проблемы в действиях с обычного Alert, а не с кастомной View (если только менеджеры не заставляют выдерживать дизайн). Алерты — естественный способ взаимодействия с системой.
3. Рисовать отдельное окно — ну, странный способ. Он то рабочий, но почему не найти в стеке ViewController тот, который сейчас активен?
4. У NSError есть прекрасный localizedDescription, который отобразит (в большинстве кейсов) адекватное описание ошибки юзеру.
5. Если сеть не доступна, то смысл тыкать «Try Again». Лишнее действие. Лучше предложить пользователю список действий, а при возвращении в приложение (applicationDidBecomeActive), или на конкретный ViewController, перепроверять состояние сети.
P.S. Если верно помню, проверить Airplane Mode просто так не получится.
Добрый день! Спасибо за хороший комментарий. Постараюсь тезисно ответить:
1. Можно, зависит от вас и вашего дизайна.
2. Сам показ алертов — не проблема. История была больше про создание процесса восстановления из ошибок. Это может быть удобно если у вас приложение достаточно слоистое — вы можете спокойно передавать ошибку между разными уровнями, в которой содержится все, чтобы из нее восстановится, когда это понадобится. Возможно, я недостаточно качественно донес эту мысль.
3. Действительно, довольно легко найти активный контролер. Все будет работать. Могут быть следующие корнер кейсы:
— Если вы используете контролер не на полный экран — он может вполне отобразится в нем. Допустим кастомные всплывающее окно. У нас есть кейс с выдвижной по свайпу панелькой. Она занимает 3/4 экрана, это считается верхний контролер и показывается Алерт в нем
— Сейчас не могу проверить, но вроде можно по ошибке найти childViewController как верхний контролер и он тоже будет не на весь экран
Отдельное окно — способ избежать таких проблем. Аналогично рекомендуется поступать при отображении push-уведомлений внутри приложения.
4. Здесь зависит от ваших критериев качества и приоритетов. В некоторых сейчас популярных доставках еды из-за нагрузки я вижу requestTimeOut, ошибки URL и ошибки парсинга данных. Я бы на месте менеджеров хотел бы этого избежать, свести к более нейтральным и общим формулровкам.
5. Звучит разумно для случая полного отсуствия сети/авиарежима. Я под internetError понимал группу ошибок, в которую входит requestTimeOut и всякие ошибки из-за нестабильности сети. Для них tryAgain имеет смысл, так как сеть может вернутся вот прям сейчас.
Проверка applicationDidBecomeActive — является хорошим тоном.
Добавлю — у нас есть обсервинг состояния сети. Допустим мы не смогли загрузить ленту. При восстановлении соединения мы перезапрашвиаем данные и без участия пользователя обновляем интерфейс.
6. Да, удобного API для проверки нет. Тем не менее — есть несколько обходных способов, они за рамками данной статьи.
1. Можно, зависит от вас и вашего дизайна.
2. Сам показ алертов — не проблема. История была больше про создание процесса восстановления из ошибок. Это может быть удобно если у вас приложение достаточно слоистое — вы можете спокойно передавать ошибку между разными уровнями, в которой содержится все, чтобы из нее восстановится, когда это понадобится. Возможно, я недостаточно качественно донес эту мысль.
3. Действительно, довольно легко найти активный контролер. Все будет работать. Могут быть следующие корнер кейсы:
— Если вы используете контролер не на полный экран — он может вполне отобразится в нем. Допустим кастомные всплывающее окно. У нас есть кейс с выдвижной по свайпу панелькой. Она занимает 3/4 экрана, это считается верхний контролер и показывается Алерт в нем
— Сейчас не могу проверить, но вроде можно по ошибке найти childViewController как верхний контролер и он тоже будет не на весь экран
Отдельное окно — способ избежать таких проблем. Аналогично рекомендуется поступать при отображении push-уведомлений внутри приложения.
4. Здесь зависит от ваших критериев качества и приоритетов. В некоторых сейчас популярных доставках еды из-за нагрузки я вижу requestTimeOut, ошибки URL и ошибки парсинга данных. Я бы на месте менеджеров хотел бы этого избежать, свести к более нейтральным и общим формулровкам.
5. Звучит разумно для случая полного отсуствия сети/авиарежима. Я под internetError понимал группу ошибок, в которую входит requestTimeOut и всякие ошибки из-за нестабильности сети. Для них tryAgain имеет смысл, так как сеть может вернутся вот прям сейчас.
Проверка applicationDidBecomeActive — является хорошим тоном.
Добавлю — у нас есть обсервинг состояния сети. Допустим мы не смогли загрузить ленту. При восстановлении соединения мы перезапрашвиаем данные и без участия пользователя обновляем интерфейс.
6. Да, удобного API для проверки нет. Тем не менее — есть несколько обходных способов, они за рамками данной статьи.
Спасибо за ответ! Стало понятнее.
По поводу текста ошибок (вроде requestTimeOut, вместо человеческого языка) — имхо, но это косяк тестеров и менеджмента, пользователь не должен видеть такие ошибки. Плюс, мы используем CodyFire для работы с сетью (надстройка над Alamofire). Очень удобно там обрабатываются ошибки (для наших кейсов — отлично).
По поводу текста ошибок (вроде requestTimeOut, вместо человеческого языка) — имхо, но это косяк тестеров и менеджмента, пользователь не должен видеть такие ошибки. Плюс, мы используем CodyFire для работы с сетью (надстройка над Alamofire). Очень удобно там обрабатываются ошибки (для наших кейсов — отлично).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из ошибки в алерт с действиями