Лого vc.ru

Опыт стартапа Pyrus: Как создать приложение, работающее в офлайне

Опыт стартапа Pyrus: Как создать приложение, работающее в офлайне

Создатели системы для организации командной работы 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, в поездах, самолетах — в общем, всегда и везде.


Чтобы написать колонку для ЦП, ознакомьтесь с требованиями к публикуемым материалам.

Статьи по теме
Pyrus — сервис для организации командной работы03 сентября 2014, 16:51
Инструменты для общения внутри компании: опыт стартапов с «Трибуны»11 августа 2014, 19:40
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Теперь написанное без багов приложение - это повод для статьи?

Баги есть всегда! Lol))

Вот об этом я писал 2 года назад им) Они "работают" над этим, не всё сразу))

0

Одна из лучших систем, пользовались и Мегапланами и т/п. Куча наворотов, оч сложно.
Спасибо Пирус, аскетично, удобно, понятно интуитивно!

Было время я каждую статью на ЦП читал. Сейчас процентов 50 всего контента читаю. Фидбек вам вот такой небольшой и повод задуматься.

И Гагарин в космосе, ага.

0

Очень странно с точки зрения iOS разработки выглядит заявление "Помимо распределения всех процессов в программе на несколько потоков (основной — для обработки интерфейса, несколько дополнительных — для получения и обмена данными с сервером)".

Выделение интерфейса в iOS основной поток происходит автоматически и обойти этот принцип ну никак нельзя, а дополнительные потоки для загрузки данных - 100% необходимость. Странно видеть описание элементарных и абсолютно обязательных подходов в статье.

Вы не правы, выделение интерфейса в главный поток не происходит автоматически. Может быть (и бывает), что вызов UI происходит в фоне. В таком случае вызов либо не выполнится вообще, либо выполнится неправильно, либо вообще приведет к эксэпшину. Поэтому, если есть вероятность вызова из другого потока, нужно всегда проверять и делать вызов из главного потока.

Я вел речь о том, что создание UI элементов (к примеру в сториборде) всегда происходит в главном потоке, так что вы меня неправильно поняли. А то, что обойти этот принцип нельзя - вы сами и подтвердили, значит он либо выполняется, либо приложение падает и не работает. Вероятность всего есть всегда, но это не значит что заявлением "мы выделили интерфейс в главный поток, а сеть и тд - в дополнительные" можно гордиться. Это практически дефолтное поведение.

0

Да, видимо неправильно понял, но поток все-равно надо проверять 😉
Достижением это назвать сложно.. Согласен

"Оно было найдено: библиотека JSONKit для сериализации и прямая запись в файл."

За это особое спасибо

0

А чем вам SQLite не угодил? Выборки-то в json делать умаешься, да и с синхронизациями проще всякими. Переносимость опять же.

0

Да тут уйма вариантов, что мешает с помощью NSCoding писать в файл. Потом нет никаких проблем с выборками и с сохранением тоже.

jsonkit и файлы это быстрое решение? т.е. про оперативку вы не в курсе?
Локальная память устройства стабильней, чем сервер в сети?
Про комменты смешно. Классическая репликация. Есть время апдейта и всё, что было после.
gzip то хоть включили? ))

Делал софтину под иос, html5 со всеми плюшками. На выходе 830 килобайт (обычный клиент-сервер, до 10 экранов, аналоги весят 15-25 метров). Работает в оффлайне, обновляется автоматом, когда есть сеть (полное обвноление кода занимает 180 килобайт и позволяет исправить любые баги без апрува аппстора). Ну и pouch+couchbase творят чудеса, прозрачная репликация без заморочек.
Чего и вам советую )

Сказ о том, как сделали всё через жопу, а потом исправляли баги ))

Месяца три назад перешла с Асаны на Пайрус, очень довольна. Всё прекрасно синхронизируется.

"Работающих в оффлайне бизнес-приложений мало" - это факт.

Колонка хорошая. Искреннюю исповедь про баги и их исправление всегда интересно почитать))

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Николай Сафронов
Google

Лидеры, лидеры про которых только в СНГ и слышали))

Wargaming приобрела финскую мобильную студию бывших сотрудников Rovio
0
Vladislav Eliseev

У нас, в России, вдруг просто так не происходит. Если появились у кого-то проблемы, значит кто-то их создал. Создают проблемы по разным причинам: может быть банальный отжим бизнеса, недружественное поглощение, борьба за контроль между заинтересованными лицами внутри структуры, попытка сбить цену на актив. Причин может быть не мало. Не знаю как с ИКЕА поступят, но для других - это вполне рабочие схемы. Завести уголовное дело или найти претензии по налогам стоит совсем не дорого.

IKEA оспорит арест 9 млрд рублей на счетах российской «дочки»
0
Vladislav Eliseev

Чтобы делать все продуманно сразу, нужно сделать хотя бы раз не продуманно! Опыт других нас не учит, нужно набить своих шишек, чтобы понять КАК не надо делать. В конце концов лучше заплатить за грамотную консультацию тому, кто сможет сказать КАК нужно сделать.

IKEA оспорит арест 9 млрд рублей на счетах российской «дочки»
1
Filipp Lyakh

> а год выпуска написан винтажным шрифтом.

Пиксельный шрифт — новый винтаж)

15 примечательных винных бутылок: шрифт Брайля, зашифрованный портвейн и посадочный талон
0
Александр Кадетов

Вот эту вкладку можно вообще навсегда удалить.

Кейс из России: Зачем команда «Альфа-Мобайл​» меняет дизайн своего приложения
0
Показать еще