Рубрика «offline first»

Scuttlebutt — сленговое слово, распространённое среди американских моряков, обозначающее слухи и сплетни. Node.js разработчик Доминик Тарр, живущий на паруснике у берегов Новой Зеландии, использовал это слово в названии p2p сети, предназначенной для обмена новостями и личными сообщениями. Secure Scuttlebutt (SSB) позволяет делиться информацией, используя лишь эпизодический доступ к сети Интернет или даже при полном его отсутствии.

SSB работает уже несколько лет. Функции социальной сети можно протестировать при помощи двух настольных приложений (Patchwork и Patchfoo) и приложения для Android (Manyverse). Для гиков есть ssb-git. Вам интересно как работает offline-first p2p сеть без рекламы и без регистрации? Прошу под кат.

Secure Scuttlebutt — p2p социальная сеть, работающая и в оффлайне - 1
Читать полностью »

Оффлайн-режим на iOS и особенности его реализации на Realm - 1

Автор: Екатерина Семашко, Strong Junior iOS Developer, DataArt

Немного о проекте: мобильное приложение для платформы iOS, написанное на языке Swift. Цель приложения — возможность шаринга дисконтных карт между сотрудниками компании и их друзьями.

Одной из целей проекта было изучить и попробовать на практике популярные технологии и библиотеки. Для хранения локальных данных выбрали Realm, для работы с сервером — Alamofire, для аутентификации использовался Google Sign-In, для загрузки изображений — PINRemoteImage.

Основные функции приложения:

  • добавление карты, ее редактирование и удаление;
  • просмотр чужих карт;
  • поиск карт по названию магазина/имени пользователя;
  • добавление карт в список избранных для быстрого доступа к ним.

Возможность использовать приложением без подключения к сети предполагалась с самого начала, но только в режиме чтения. Т.е. мы могли просматривать информацию о картах, но не могли модифицировать их без интернета. Для этого в приложении всегда была копия всех карт и брендов базы с сервера, плюс список избранных для текущего пользователя. Поиск тоже реализовывался локально.

Позже мы решили расширить оффлайн, добавив режим записи. Информация об изменениях, сделанных пользователем, сохранялась и при появлении интернет-соединения синхронизировалась. О реализации такого read-write оффлайн-режима и пойдет речь.Читать полностью »

Автор — Алекс Расселл, разработчик Chrome, Blink и веб-платформы в Google

TL;DR: бюджеты производительности — существенная, но недооценённая часть успешного продукта и здоровой команды. Большинство наших партнёров не осведомлены об условиях реального мира — и в результате выбирают не те технологии. Мы установили бюджет по времени пять и менее секунд до интерактивности сайта после первой загрузки, а также две или менее секунд при последующих загрузках. При соблюдении этих нормативов мы ограничены типичным устройством из реального мира и типичной сетевой конфигурацией. Это Android-смартфон за $200 на канале 400 Кбит/с, RTT 400 мс. Это означает бюджет ~130-170 КБ ресурсов критического пути, в зависимости от их состава: чем больше JS — тем меньше объём.

За последние несколько лет мы имели удовольствие работать с десятками команд. Работа оказалась просветляющей, иногда в очень неожиданных местах. Один из самых неожиданных результатов — частые случаи «западни JavaScript».

«Нам нужен новый термин для упущенных деловых возможностей из-за современного фронтенда. Может быть, “западня JavaScript”»?

Управленцы, которые дают добро на создание прогрессивных веб-приложений (PWA), часто основным мотивом называют практически беспроблемный охват новых пользователей. В то же время разработчики осваивают инструменты, которые делают возможной достижение такой цели. Никто не хотел плохого. Тем не менее, результаты «готового» проекта PWA часто требуют недель или месяцев болезненной переделки, чтобы обеспечить минимально приемлемую производительность.
Читать полностью »

image

Перед вами перевод заметки «Встречайте Offline First». Некоторые мысли из неё мне показались интересными, да и в целом тренд является положительным – коротко говоря, группа энтузиастов решила устроить коллоквиум, посвящённый проблемам оптимизации мобильных приложений для работы в оффлайне (то есть – автономно, без покрытия сети).

Форма регистрации – offlinefirst.org
Читать полностью »

В этом году на конференции Full Frontal, оффлайн-приложения были популярной темой. Пол Кинлан сделал отличный доклад «Строим веб-приложения будущего. Завтра, сегодня и вчера» (вот его слайды), в котором он сравнивал ощущения пользователей от работы с 50 популярными мобильными приложениями для iOS и Android с ощущениями от веб-сайтов и приложений.

Стоит ли говорить, что нативные приложения зарекомендовали себя с гораздо лучшей стороны, когда соединение с интернетом было недоступно. Оффлайн-режим — очень важная вещь, и стоит думать о нем с самого начала работы над приложением, а не рассчитывать добавить его потом, когда будет время. Работая над сайтом Rareloop, мы с первого дня помнили об оффлайн-режиме. Мобильные клиенты FormAgent тоже были изначально спроектированы для работы в оффлайне, чтобы пользователь мог продолжать работу в отсутствие интернета и прозрачно синхронизироваться, когда связь появляется. В этой статье я описываю принципы и практики, которые, на мой взгляд, очень помогают разрабатывать такие приложения.

Обратите внимание! Я не рассматриваю вопросы кэширования ресурсов приложения — вы можете использовать App Cache или гибридное решение (вроде PhoneGap), это не принципиально [От переводчика: на Хабре есть подробная статья про особенности работы с Application Cache API]. Это руководство посвящено скорее тому, как спроектировать архитектуру веб-приложения для работы в оффлайн-режиме, а не тому, какие механизмы использовать для его реализации.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js