Перед вами перевод заметки «Встречайте Offline First». Некоторые мысли из неё мне показались интересными, да и в целом тренд является положительным – коротко говоря, группа энтузиастов решила устроить коллоквиум, посвящённый проблемам оптимизации мобильных приложений для работы в оффлайне (то есть – автономно, без покрытия сети).
Форма регистрации – offlinefirst.org
В данный момент некоторые члены нашей команды путешествуют: занимаются организацией конференций, участвуют в различных мероприятиях, проводят мастер-классы, перемещаясь из страны в страну. В связи с этим мы не только испытали на своей шкуре все прелести плохого качества связи и интернета, но также пообщались с другими людьми из разных уголков мира – у каждого нашлись свои истории и проблемы.
Наблюдая частые обрывы мобильного интернета, даже в самых цивилизованных и наиболее развитых городах, мы пришли к выводу, что нет, проблемы с покрытием/скоростью нигде не решатся сами собой в ближайшем будущем.
Обычно мы относимся к данной проблеме довольно оптимистично, считая, что в будущем покрытие и пропускная способность сети будут постепенно расти. Однако наш недавний опыт показал, что такие суждения попросту наивны. Проблемы нагрузки сети, переменного качества покрытия, наличие зон с отсутствием покрытия, слабые сигналы (wi-fi, например) и другие проблемы, проявляющие себя во время путешествий – всё это будет существовать почти всегда.
Географию не переделаешь, как и архитектуру. Путешественники попадают под двойной удар: мало того, что в транспорте успешного покрытия не сыщешь (метро, высокоскоростные поезда, самолёты), так ещё и вымогательские цены за роуминг от ОпСоСов – приходится носить с собой коллекцию сим-карт, как будто вы Агент 007. И это всё с западно-европейской точки зрения.
Товарищ Gregor провёл последние 6 недель путешествуя через Африку на AfricaHackTrip, а мы в свою очередь имели возможность поговорить с людьми со всех концов света на мероприятии Mozfest в Лондоне. Здесь, как и во многих других случаях, мы заметили серьёзную озабоченность вопросами использования мобильных приложений без покрытия сети – люди горели желанием иметь лучшую поддержку автономного режима, как в веб-приложениях, так и нативных.
МЫ НЕ МОЖЕМ ПРОДОЛЖАТЬ СОЗДАВАТЬ ПК-ПОДОБНЫЕ ПРИЛОЖЕНИЯ, ПРЕДПОЛАГАЯ ПОСТОЯННЫЙ И БЫСТРЫЙ КАНАЛ СВЯЗИ, КОГДА ВРЕМЕННОЕ ОТКЛЮЧЕНИЕ ОТ СЕТИ ИЛИ МАЛАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ СЧИТАЮТСЯ ПРОБЛЕМОЙ И ТРАКТУЮТСЯ КАК ОШИБКА.
Мобильные сети попросту не могут обеспечить такой же уровень качества и стабильности, уже давно пора было начать адаптироваться к такой реальности. Это как если бы разрабатывать приложение «в первую очередь для мобильных устройств», но с учётом такого положения дел – имеет место быть разработка «в первую очередь для автономности». Под автономным режимом мы подразумеваем не только специальный план действий на случай возникновения ошибок, но и фундаментально более гибкий и отказоустойчивый путь дизайна приложений.
Вместе с нашей командой, мы разработали архитектуру, позволяющую создавать автономные приложения с относительной лёгкостью. Мы не держим это в секрете, но соблюдаем конфиденциальность насчёт технических аспектов касательно нашего синхронизирующего движка и того, каким образом он обеспечивает автономность. Внезапно мы столкнулись с обилием новых, до сих пор неизвестных и неизученных сценариев использования, которые стали доступны большинству разработчиков только сейчас.
Это буквально новый рубеж, за которым находится неизведанное, полное интересных проблем и невообразимых частных случаев. В других сферах дизайна приложений мы обладаем наследием паттернов UX/UI, которые можем с лёгкостью применить. Но описанная нами «автономия приложений» – самая настоящая terra incognita.
АВТОНОМНОСТЬ СТАЛА РЕАЛЬНОСТЬЮ
Вот так внезапно, автономность становится нечто большим, чем просто обработка ошибок. Автономность стала нависшей реальностью, в которой, ага, некоторые части вашего приложения перестанут работать – независимо от того, нужна ли им сеть или нет. В связи с этим возникает множество фундаментальных вопросов:
- Должно ли приложение уведомлять человека о текущем состоянии подключения? Касается ли его эта информация? Если да, то каким образом лучше всего?
- Можем ли мы давать пользователям надежду, что приложение корректно запомнило своё состояние, и что никакие данные не будут потеряны, вне зависимости от состояния сети?
- Как сообщить пользователю, что он может продолжать работать с приложением в автономном режиме, и что данные, введённые пользователем на данном этапе будут корректно отправлены/обработаны в будущем?
- Как интерфейс должен отображать все те изменения, что произошли с момента последнего выхода в сеть? Что делать с удалёнными объектамии и так далее
- Как сделать так, чтобы неминуемое разрешение конфликта было максимально безболезненным и интуитивным для пользователя?
- Как насчёт преждевременной загрузки некоторых данных, которые, по мнению программы, могут пригодиться пользователю в автономном режиме?
- Какие метрики использовать для принятия решений о механизме преждевременной загрузки?
Конечно, на самом деле вопросов намного больше. Нам нужно было с чего-нибудь начать и наш семинар на Mozfest – «Offline First Application Design» прояснил для нас всё. Пред нами встала целая новая парадигма, которую мы готовы оседлать. Мы хотим помочь пользователями hood.ie создавать надёжные, где-угодно-работающие приложения, причём не только с технической точки зрения, но и с новыми паттернами и методами UX и UI. Вы можете присоединиться к обсуждению на offlinefirst.org.
АБЗАЦ ОТ АВТОРА ПЕРЕВОДА
На мой взгляд, темы актуальнее не найти. Неделю назад приобрёл смартфон и уехал за город – в 20км от Москвы остался лишь EDGE, а по приезде на место (40км) канал перекрылся окончательно. Бываю там на протяжении 5 лет подряд и за этот период у MTS с покрытием в том районе не изменилось ничего, несмотря на мои вопросы к службе поддержки. Сеть есть, интернета – нет, даже если заплатить (или заплакать). В принципе, я не собирался ничего делать с телефоном, когда рядом есть ноутбук и мегафон-модем с идеальным 3G, но есть одно но. Скорость у MTS-EDGE есть – это около 3-5кбайт/с, её хватает для проверки почты и так далее. Но через такой канал отправить фотографию в тот же Instagram невозможно. Программа не знает, что я готов ждать весь день. Она шлёт первые 50кбайт на скорости 3кбайт/с и затем выдаёт «Upload Failed». Интереснее всего дела обстояли с поддержкой Twitter в операционке WP7.5 год назад – там ошибка не выдавалась, но и продолжать загрузку при появлении коннекта система не собиралась, бесконечно показывая мнимый progress-bar. Ах да, при отмене весь твит терялся. Подписи к фоточкам в Instagram тоже теряются. Короче, так нельзя, пора менять подход, народ.
~~~~~
А какие у вас найдутся невесёлые истории? Пишите в комментариях, соберём российский набор.
Замечания по переводу принимаются в личку.
Автор: Xlab
