Создатели системы для организации командной работы Pyrus рассказывают о том, как они создали приложение, с которым можно работать без доступа к сети.
Работающих
в офлайне мобильных бизнес-приложений на рынке мало . Наш клиент — активный занятой человек, которому нужна возможность управлять задачами и взаимодействовать с сотрудниками не только в офисе, но и в самолете, в гостинице без WiFi, на сплаве среди дремучего леса и т.д. Поэтому мы изначально ставили себе цель сделать качественное мобильное приложение, работающее в том числе при отсутствии соединения с сетью. Сделать это получилось не сразу. В процессе работы мы совершили несколько ошибок и получили множество
замечаний.
Мы были уверены, что достигнем нашей цели максимум через месяц. На первую версию iOS-приложения ушло почти полгода. В ней можно было увидеть все уже завязанные на тебе в Pyrus задачи. Вот только для того, чтобы все они первоначально подгрузились на устройство, требовалось целых три минуты, что, конечно, было недопустимо. Так что эта версия приложения даже
не появилась в App Store.
Во второй версии мы изменили подход. Приложение ничего не загружало заранее. Пользователь видел в нем заголовки задачи, при каждом клике на которые мобильная система запрашивала с сервера свежую версию задачи. Так все работало
быстрее, но опять же — только с интернетом.
Результат
№1. Полноценный оффлайн
Когда работаешь с информацией клиентов, они могут простить многое — медленную загрузку, неудачный дизайн, периодические сбои в программе. Но они никогда не простят потерю их данных. Вот почему первоочередной задачей было сделать так, чтобы абсолютно все действия пользователей сохранялись в локальной
памяти их мобильного устройства. Как раз на случай непредвиденных ситуаций — типа севшей батарейки или оборвавшегося доступа в интернет.
Тут же выяснилось, что большие объемы данных, с которыми работает приложение, далеко не всегда удается быстро записать на локальный диск мобильного устройства его штатными средствами. Пришлось отказаться от разрекламированной Apple технологии Core Data и искать свое решение. Оно было найдено: библиотека JSONKit для сериализации и
прямая запись в файл.
В результате удалось ускорить работу с диском в 5-10 раз. Теперь в нашем приложении стала возможна полноценная работа в автономном режиме: создание задач, изменение их статусов, написание комментариев. Причем пользователь мог выключить приложение или сам телефон в любой момент — все его данные все равно
оставались сохраненными, и, включив Pyrus на телефоне вновь, он находил их ровно в том виде, в котором и оставил.
Результат №2. Быстрая
синхронизация
Дело оставалось за синхронизацией. Помимо распределения всех процессов в программе на несколько потоков (основной — для обработки интерфейса, несколько дополнительных — для получения и обмена данными
с сервером), созданию быстрой синхронизации помогло еще одно решение.
Число пользователей Pyrus быстро росло. Однажды, анализируя огромный трафик, мы увидели, что 95% от него тратится на загрузку десятков, а то и сотен старых комментариев, которые к тому моменту уже и так были в телефоне клиента и с тех пор никак не изменились. То есть при написании клиентом всего лишь нового комментария сервер помечал всю
задачу как измененную и полностью ее скачивал, затрачивая трафик впустую.
Поменяли принцип. Стали отдельно передавать заголовок задачи (здесь значатся сроки, ответственные и текущее состояние согласований), отдельно – только новые комментарии, которых на устройстве не было ранее. Соответственно, пришлось усложнить логику приложения и хранить для каждой задачи номер последнего комментария, чтобы при поступлении запроса на синхронизацию понимать, появился ли еще один новый комментарий или нет. Это усложнение логики себя полностью оправдало. Синхронизация стала работать заметно быстрее, а трафик снизился в 20 раз! Что очень важно при работе в
медленных сетях 3G или в роуминге с дорогим трафиком.
Скоро к Pyrus начали подключаться и крупные клиенты, для которых список в 6000 контактов — норма. Сделали так, что список контактов стал доступен для них и в офлайне, с привычным удобным поиском по первым буквам. Причем с учетом того, что каждый контакт весит всего около 100 байт и изменяется редко, нам не пришлось даже оптимизировать трафик при пересылке метаданных. Полный список контактов пользователя всегда пересылается целиком при изменении хотя бы в
одном элементе.
Другой маленькой победой стала ликвидация случаев повторной синхронизации данных, в результате которой в приложении у пользователя появлялось сразу несколько дублей одной и той же информации. Проблема возникала при перебоях с доступом в интернет. Мобильное устройство находило связь, приложение синхронизировалось и отправляло данные на сервер. Сервер, в свою очередь, отсылал подтверждение о получении, которое, однако, так и не доходило до телефона из-за потерянного подключения к интернету. Поэтому при возобновлении связи мобильное устройство отправляло данные повторно, а сервер воспринимал их как
новые. Оптимизировав процессы, мы смогли от этого избавиться.
Третье, полностью работающее в оффлайне и хорошо синхронизирующееся с сервером приложение было выпущено в App Store в апреле 2012 года. Оно сохраняло все изменения на диск и при первой же возможности отправляло их на сервер. Pyrus был готов к работе в условиях нестабильной интернет-связи, при переключении между сотовыми операторами, переходе из EDGE в 3G, в поездах, самолетах — в
общем, всегда и везде.
Тем не менее, ошибки, конечно, случались. Последние — осенью 2013 года, когда мобильные устройства Apple переходили на iOS 7. Мы за несколько месяцев до этого разработали обновленную версию приложения и неоднократно ее протестировали. Тем не менее, в день перехода на iOS 7 эта версия перестала исправно работать у 3-5% наших клиентов. Мы поправили все моментально, а вот запрошенный нами у Apple ускоренный режим проверки
приложений перед публикацией затянулся.
Чтобы написать колонку для , ознакомьтесь с требованиями к публикуемым материалам.
About the author