Tamtam messenger


TamTam | Чаты и Каналы

Совсем недавно, а точнее в мае 2017 года Mail.Ru Group анонсировала выход нового мобильного приложения, которое получило название Tam Tam messenger. Данная программа была создана с целью, обеспечить комфортное общение между пользователями. Причем они могут находиться в любой точке мира и поддерживать связь между собой, если их устройства будут подключены к глобальной сети.

Особенности Tam Tam

Российский мессенджер создан на базе «ОК Сообщения» — это приложение популярной социальной сети «Одноклассники», которое было разработано за год до выхода нового софта от Mail.Ru Group. Данная утилита сразу же привлекла внимание большого количества пользователей. Тем более она была разработана с целью замены «ОК Сообщения», которое очень востребовано среди участников знаменитой соцсети. Их число составляет примерно 290 млн человек. Именно такое количество пользователей уже сразу перешло в приложение TamTam.

Новая программа для мобильных платформ позволяет людям общаться практически без ограничений, используя для этого следующие возможности софта:

  • Отправка личных сообщений.
  • Беседы в групповых чатах.
  • Обмен стикерами.
  • Отправка и получение gif-анимации.
  • Обмен фотографиями.
  • Передача друг другу небольших видеороликов.
  • Отправка музыкальных файлов.

При этом пользователи смогут выполнять все вышеперечисленные действия, даже если устройство будет иметь не очень хорошее интернет-подключение. Кроме того, тамтам мессенджер позволяет отправлять сообщения другим абонентам при нахождении в оффлайн-режиме. Их доставка собеседнику осуществится в автоматическом режиме, когда девайс попадает в зону действия, например, Wi-Fi.

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

Представители Mail.Ru объяснили создание нового приложения тем, что у них возникло желание предоставить возможность людям использовать усовершенствованный продукт, разработанный на базе старой программы. При этом у корпорации появился шанс как сэкономить средства, так и сразу же получить приличное количество «живых» пользователей.

Примечание! У холдинга уже имеется подобное приложение под названием ICQ. Однако аудитория данного мессенджера неуклонно уменьшается. Поэтому в Mail.Ru было принято решение создать другую программу, которая позволит улучшить позиции корпорации на рынке ПО.

В связи с тем, что Там там мессенджер еще молодой софт. Поэтому его будущее на 100% неизвестно. Однако данная программа имеет хорошие перспективы. Если надежды на нее оправдаются, тогда существует большая вероятность, что уменьшится популярность такого известного мессенджера, как Viber. Данное мнение высказали некоторые эксперты в этой области. Они основывались на том, что Viber использует много пользователей, которые являются участниками социальной сети «ОК». Эксперты считают реальной возникновение ситуации, когда из Вибера может перейти в TamTam примерно 15% пользователей.

Доступность нового мессенджера TamTam

У пользователей имеется возможность TamTam messenger скачать бесплатно на устройства, управление которых осуществляется двумя популярными операционными системами. Одной из них является iOS, а другой — Андроид. Для того чтобы воспользоваться предоставленной возможностью человек может посетить официальный сайт утилиты или сразу же открыть один из магазинов в соответствии с ОС своего девайса.

 

 

 

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

Несмотря на небольшое количество версий программы, у людей все же имеется возможность установить мессенджер на компьютер, но для этого им необходимо дополнительно использовать эмулятор Android-среды.

TamTam от одноклассники

Под конец мая 2017 года холдинг Mail.Ru Group представил на суд публики приложение TamTam от одноклассники. Оно представляет собой обновленную версию популярного сервиса «ОК Сообщения», который использовало для общения почти 300 млн человек. Все эти люди, по планам разработчика программы, станут использовать именно новый софт, чтобы общаться как со своими родственниками и друзьями, так и коллегами. Стоит отметить, что «ОК Сообщения» был запущен всего лишь в июле 2016 года.

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

Разработчик tam tam одноклассники сообщает, что утилита в ближайшее время будет интегрирована с разными сервисами компании, а не только с популярной соцсетью. При этом пользователям не обязательно осуществлять привязку к «ОК». Они имеют полное право регистрировать новые аккаунты. Кроме того, авторизоваться пользователи смогут с помощью учетной записи Google.

С помощью нового приложения mail ru тамтам людям предоставляется возможность осуществлять переписку между собой посредством коротких текстов или участвовать в групповых чатах. Еще они могут отправлять и получать:

  • фотоснимки;
  • стикеры;
  • анимацию;
  • видеофайлы;
  • музыкальные композиции.

Кроме перечисленных возможностей, пользователи смогут в tamtam mail создавать каналы. Управление ими разрешено осуществлять средствам массовой информации, разным блогерам, брендам и так далее. Разработчик еще обещает в скором времени создать веб-версию мессенджера, а также добавить такие функции, как видео и голосовые звонки.

tamtam-download.ru

TamTam на компьютер. Скачать ТамТам для компьютера

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

Разработчик выпустил в настоящее время версии, предназначенные для установки на устройствах, функционирующих под управлением таких OS, как iOS и Android. Однако он заявил, что в будущем свет увидит веб-версия приложения. Она позволит использовать софт непосредственно через установленный на ПК браузер. Помимо этого, пользователи еще могут надеяться, что у них появится возможность скачать тамтам на компьютер. Однако сегодня для установки программы на десктоп или ноутбук им придется дополнительно использовать эмулятор Android-среды.

Таких утилит существует достаточно много. Какой именно применить эмулятор — это самостоятельный выбор каждого пользователя. Однако большинство владельцев PC предпочитают использовать BlueStacks 3. Этот софт отличается стабильной работой и интуитивно понятным интерфейсом. Он доступен на официальном сайте совершенно бесплатно.

Установка программы

Процесс установки программы Bluestacks 3 на компьютер идентичен первому запуску любого смартфона на ОС Android, все эти шаги будут вам знакомы, если вы когда либо держали в руках новый смартфон на платформе Андроид, но в нашей статье мы разберем все по пунктам, данная информация пригодится для установки на компьютер любого приложения из Google магазина

1. Скачайте установочный файл BlueStacks 3, кликнув на картинку ниже, вы автоматически загрузите файл с официального сайта www.bluestacks.com:

Скачать BlueStacks 3 с официального сайта

2. Запустите скачанный файл от имени администратора:

3. Нажмите на кнопку «Установить сейчас«, приняв соглашение Лицензии ПО:

4. Далее пройдет процесс установки, дождитесь его окончания:

5. После успешной установки BlueStacks 3 программа автоматически запустится и вы попадете в окно с выбором языка:

6. В следующем окне программа предложит зайти под существующим Google Account или создать новый:

7. Нажимаем продолжить, вводим данные существующего аккаунта Google, такие как логин и пароль, нажимаем стрелку вправо, выскочит сообщение об Условиях использования приложения и политики кампании, нажимаем ОК, ждем пока произойдет вход в систему под вашими данными:

8. Вход в систему:

9. В следующем окне, программа предложит восстановить резервную копию, если такова имеется, вы можете оставить все без изменения либо убрать галочки о местоположении и т.д.:

10. Добавьте имеющуюся кредитную или дебетовую карточку, либо аккаунт paypal для совершения дальнейших покупок платных приложения как и на любом смартфоне, либо пропустите процесс, нажав слева «Нет, Спасибо«:

11. По умолчанию загрузятся данные вашего Google аккаунта. При желании вы можете их изменить, Фамилию и Имя

На этом этап установки Bluestacks 3 на компьютер успешно закончен, если Вы сделали все как описано выше, то перед вами откроется окно Google Play магазина как и на обычном телефоне, в открывшемся окне справа с верху будет значок поиска, нажав на него введите слово TamTam Messenger либо на русском языке ТамТам, автоматически всплывут подсказки всех вариантов названия кликните на любое:

Установка ТамТам приложения в BlueStacks

1. Итак мы попали на страницу программы ТамТам Мессенджер в Google Play, жмем на кнопку Установить:

2. Соглашаемся с условиями установки, нажав на кнопку «Принять»

3. Процесс установки запущен:

4. После успешной установки там там мессенджера на эмулятор Bluestacks появится ярлык с логотипом на желтом фоне, запускаем его:

На следующем этапе перед человеком появится окно приветствия приложения. Здесь ему придется пройти процедуру авторизации. Ее осуществить можно, если использовать:

  1. Смартфон (по номеру телефона).
  2. Аккаунт в социальной сети под названием «Одноклассники».
  3. Google аккаунт.

Вход в приложение ТамТам по номеру телефона

1. Введите номер телефона с кодом страны:

2. Подтвердите правильность ввода номера телефона, затем вам поступит смс уведомление с кодом подтверждения на указанный номер, введите его:

3. Как только процедура авторизации будет завершена, процесс скачивания TamTam для компьютера считается оконченным. Теперь можно приступать к его использованию для общения с другими пользователями.

Для дальнейшего запуска TamTam на компьютере при помощи эмулятора Bluestacks, вы можете воспользоваться созданным ярлыком на рабочем столе:

tamtam-download.ru

как мы делали новый мессенджер / Блог компании Mail.Ru Group / Хабрахабр

Привет, Хабр! Меня зовут Юрий Буянов, я разработчик мессенджера TamTam. Сегодня я хочу рассказать вам немного о том, как он создавался и как устроен изнутри. TamTam — это новый мессенджер Mail.Ru Group, который был разработан на базе приложения «ОК Сообщения». В 2016 году мы сделали отдельный мессенджер в Одноклассниках для тех, кто часто переписывается в соцсети и кому удобнее это делать с помощью отдельного приложения.

Эксперимент получился удачным, поэтому в начале года мы решили развивать «ОК Сообщения» как отдельный от соцсети мессенджер под собственным брендом TamTam, но уже с набранной стартовой аудиторией. Уже за первые недели после запуска в TamTam появились десятки тысяч каналов, а аудитория продолжила общаться так же активно, как и в «ОК Сообщениях». Это стало возможным в том числе благодаря быстрой работе приложения и нескольким техническим фишкам. О них я расскажу подробнее.

Сложности, которые натолкнули на идеи

Начнём со сложностей: именно они принесли нам идеи, которые потом реализовались в продукте и в итоге превратились в преимущества приложения. Речь прежде всего о быстрой и стабильной работе мессенджера.

Стартовая аудитория TamTam — из самых разных уголков мира, в том числе с нерегулярным покрытием мобильной сети (а иногда и с полным отсутствием стационарного интернета). В некоторых странах СНГ за пределами крупных городов 2G-соединение — вообще фактически единственное окно в интернет.

Важно было и то, что далеко не все потенциальные пользователи TamTam каждый год бегут покупать новый айфон или ГОРЯЧУЮ НОВИНКУ от Samsung. По статистике, самый популярный девайс под iOS у наших пользователей — iPhone 5s, а под Android — недорогие Galaxy выпуска 2014—2015 годов. При этом у TamTam достаточно молодая аудитория: 28 % дневной аудитории — это люди в возрасте 27—34 лет, а более половины пользователей (54 %) — младше 35 лет.

Поэтому одним из приоритетных направлений в разработке мессенджера для нас с самого начала была оптимизация приложения с точки зрения как быстродействия, так и работы с сетью. Словом, требовалось незаметно для пользователей сделать так, чтобы приложение работало при любом уровне подключения. И при любом росте аудитории тоже. TamTam в первые же месяцы показывает неплохие цифры: число установок уже приближается к 3 миллионам, а число каналов уже больше 50 000.

Как мы делали приложение быстрым

Быстродействие с точки зрения пользователя — это в первую очередь скорость запуска. Время, которое проходит до отображения нового контента (например, при открытии чата с новым сообщением по push-уведомлению). Плавность работы в целом — в частности скролла. В iOS-команде мы стараемся тестировать и замерять быстродействие на iPhone 5 и iPhone 4S. Андроид-команда имеет в распоряжении Galaxy S3 и Мегафон логин за 1000 рублей. Как следствие, на более мощных девайсах приложение просто летает.

В каждой тестовой сборке можно включить счётчик кадров в секунду, а в логи и в систему статистики записывается длительность выполнения операций в узких местах.

Например, на этом графике показано время с момента запуска приложения при открытии по пушу до момента, когда пользователь увидит это конкретное сообщение на экране. Два падения на графике соответствуют включению контент-пушей на половину и на всех пользователей.

Несмотря на обилие инструментов и метрик, главным инструментом оценки быстродействия приложения остаются субъективные ощущения. Никто не может точно ответить, какая задержка в миллисекундах допустима при открытии экрана сообщения, но практически каждый может сказать, есть ли у него ощущение того, что приложение «тупит».

Как мы оптимизируем? В первую очередь выносим всё, что можно, из главного потока: работу с БД (об этом чуть ниже), работу с сетью, сериализацию и десериализацию данных, процессинг картинок и даже вычисления, связанные с вёрсткой текста.

Когда мы запускаем приложение или открываем экран чата, выполнение тяжелых операций в фоне не спасёт от видимой задержки. Так что одни операции вроде вёрстки бабблов всё равно нужно оптимизировать по времени, а другие лучше делать сразу при получении сообщения и кешировать результат их выполнения в базе.

При выборе сторонних решений и библиотек в узких местах мы тоже старались учитывать быстродействие и компактность. В частности, именно поэтому мы выбрали MessagePack (причём для iOS специально делали бенчмарк разных реализаций), поменяли библиотеку для маппинга данных в объекты с Mantle на YYModel и остановились на lz4 в качестве алгоритма компрессии трафика.

Кроме того, для достижения плавности работы интерфейса мы симптоматически оптимизируем рендеринг:

  • избегаем offscreen-рендеринга, нагружающего процессор;
  • заранее в фоне ресайзим картинки вместо использования работающих в главном потоке стандартных UIViewContentMode;
  • делаем наши иерархии UI более «плоскими» и простыми;
  • кешируем те объекты и данные, создание которых слишком затратно. Начиная с высоты ячеек с текстом и заканчивая YYTextLayout (объект, который хранит информацию об отображении текста в библиотеке YYText), NSAttributedStrings и даже самими UIViews.

Во всех списках идёт ручная вёрстка без auto layout. Хотя auto layout мы тоже очень любим и используем декларативную вёрстку с помощью Masonry в коде — но только там, где это целесообразно.

Офлайн и работа при плохом интернете

При работе с сетью мы стараемся минимизировать трафик и задержки за счёт выбора быстрого компактного протокола и агрессивного кеширования.

В качестве способа общения с сервером мы используем только TCP-сокеты и бинарный протокол. Это позволяет нам как получать обновления с сервера в реальном времени, так и работать в более привычном режиме «запрос — ответ».

Сам API, т. е. набор команд поверх низкоуровневого протокола, можно в будущем при желании реализовать поверх другого транспорта, например на веб-сокетах. При всём этом нам не придётся трогать верхнеуровневую логику работы приложения.

Сами пакеты состоят из заголовка фиксированной длины со служебной информацией: код команды, версия протокола, длина пэйлоада. Ответы на запросы могут приходить в разном порядке и вперемешку с командами сервера, поэтому в заголовке есть sequence number, позволяющий связать запрос и ответ.

В качестве формата для пэйлоада мы решили попробовать messagepack. Он не требует жёсткого задания схемы, очень компактный и имеет довольно шустрые библиотеки сериализации под множество платформ. По сути, это эффективный бинарный аналог JSON. Для того чтобы ещё более снизить потребление трафика, мы сжимаем пэйлоад алгоритмом lz4. Его мы также выбрали за скорость и небольшую нагрузку на CPU и батарейку.

Один из главных способов обеспечить нормальную работу приложения в условиях плохой сети — максимальная поддержка офлайн-режима. Приложение должно кешировать максимум данных, тратить меньше времени и трафика на синхронизацию и уметь откладывать отправку команд до появления соединения. Причём соединение может вернуться даже при следующем запуске приложения, т. е. все отложенные задачи по отправке надо уметь сохранять в БД.

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

С историей сообщений в чате всё чуть сложнее. Грузить заранее всю историю всех чатов бессмысленно, но что мы один раз получили — то мы кешируем и стараемся больше не запрашивать. Если посмотреть на то, какие участки истории чата закешированы, мы увидим, что в истории есть «разрывы». Например, с обновлением списка чатов после логина мы увидели, что последнее сообщение в чате изменилось. При этом у нас в БД есть участок (или несколько участков) истории чата, закешированный в ходе предыдущей сессии. Кроме того, мы не знаем, сколько сообщений есть на сервере между последним сообщением в чате и предыдущим закешированным сообщением, и это добавляет своих сложностей.

Поэтому, кроме самих сообщений, мы храним метаданные о непрерывных кусках истории — чанках, которые мы закешировали. При скролле чата мы используем эту информацию: она помогает нам определить, грузить следующую страницу из БД или отправлять запрос на сервер. А может быть, делать и то, и другое. При получении новых участков истории с сервера эти чанки меняют размер и сливаются друг с другом (в случае если клиент понимает, что только что полученный участок истории соединяет два разрозненных чанка, имеющихся в БД).

Поскольку многие операции можно выполнять в офлайне, мы разработали механизм сохранения задач. Он умеет запускать задачи, дожидаться их выполнения, сохранять их состояние в БД или загружать и запускать при старте приложения.

Задачи могут сохраняться в БД, они инкапсулируют в себя всю логику выполнения. Поскольку зависимости от других задач и от состояния приложения могут быть довольно сложными, то слежение за ними тоже реализовано в самих задачах. Например, задача отправки сообщения с фотографией должна убедиться в том, что фотография обработана, загружена на CDN (за это отвечают отдельные задачи), дождаться (при необходимости) сетевого подключения и только потом непосредственно попытаться отправить само сообщение.

Два приёма для плавной работы приложения

Немного расскажу о паре приёмов, которые мы использовали для обхода ограничений системы, мешающих нам сделать дружелюбный и плавный интерфейс. На примере iOS-приложения.

Одной из сложностей при разработке стал бесконечный скролл в чате, т. е. незаметная для пользователя подгрузка истории сообщений при прокрутке чата вверх. В 99 % случаев пользователь находится именно внизу чата и хочет проскроллить его вверх для того, чтобы прочитать старые сообщения. Здесь мы столкнулись с двумя проблемами.

Во-первых, постоянное натыкание на верхнюю границу списка сообщений и ожидание подгрузки каждые несколько экранов раздражает. Эту проблему было не очень сложно решить: мы не дожидаемся, пока пользователь доскроллит до самого верха и увидит там «крутилку», а стараемся заранее запрашивать предыдущие страницы истории еще во время скролла: как из локального кеша, так и с сервера. При наличии сообщений в кеше или на быстром соединении пользователь просто не успеет доскроллить до самого верха к тому моменту, как мы сможем отобразить новую пачку сообщений.

Вторая проблема оказалась гораздо серьезнее: после вставки такой страницы в начало списка сообщений (сделанного на основе UITableView) contentOffset для уже загруженного участка сдвигается, и скролл «прыгает». Конечно, мы можем посчитать размер вставляемой страницы и изменить contentOffset обратно, но это приводит к резкой остановке анимации скролла, что некрасиво и обескураживает пользователя. Мы пытались делать это различными способами, включая такие, например, как отслеживание contentSize таблицы через KVO, но неизменно терпели неудачу: UITableView просто хронически не приспособлен к тому, чтобы элементы добавлялись в начало списка.

В итоге после ряда попыток мы смогли решить эту проблему, применив своего рода «хак»: переворачиваем список вверх ногами с помощью .transform, а затем переворачиваем каждую ячейку в обратном направлении. Пользователь ничего не замечает, но теперь contentOffset отсчитывается снизу, и подгрузка старых сообщений никак на него не влияет.

У этого решения есть ряд подводных камней, но их мы тоже сумели обойти, и нам они не мешают. Во-первых, необходимо конвертировать перевёрнутые индексы ячеек в индексы в вашей модели данных, и обратно. Если у вас больше одной секции, вычисления будут очень сложными, так что лучше ограничиться одной. Конечно, это не даёт нам использовать плавающие заголовки секций, которые на экране чата пригодились бы, например, для отображения разделителей по дням в истории. Но плавающие разделители в итоге оказалось не так сложно сделать вручную.

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

Вторая сложность, с которой мы столкнулись, — это анимированные и асинхронные обновления списков. Если несколько независимых обновлений происходят почти одновременно (например, подгружается страница истории вверху чата и приходит новое сообщение внизу), то данные, используемые делегатом tableView, могут измениться, даже если не закончилась анимация предыдущего обновления.

Это может привести к тому, что UITableView отрендерит неправильную ячейку или вообще упадёт: это ещё более вероятно, если вы используете предыдущий хак. Можно, конечно, обратиться к методу reloadData, синхронному в UITableView, однако это приводит к морганиям, остановке скролла и прочим раздражающим пользователя вещам.

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

Persistence

Для кеширования данных в iOS-клиенте мы используем библиотеку YapDatabase.

YapDatabase — это Key-Value хранилище поверх SQLite с очень большим набором возможностей. Мне эта библиотека кажется гораздо более простой и гибкой, чем CoreData. Здесь можно выбрать механизм сериализации объектов в базе: по умолчанию это NSCoding, а мы используем всё тот же MessagePack.

YapDatabase не требует наследования объектов от базового класса или реализации какого-то протокола, не привязывает объекты к контексту. Чтение и запись производятся с помощью синхронных или асинхронных транзакций.

А при помощи системы расширений доступны все те же возможности, что и в «настоящей» БД: произвольные SQL-запросы и индексирование нескольких полей, полнотекстовый поиск, подписка на изменения (как в NSFetchedResultsController), подключаемое шифрование, работа с CloudKit и т. д. Hello-world примеры работы с БД приводить здесь не буду, они есть в вики на github.

На мой вкус, YapDatabase повышает продуктивность и понятность кода, но некоторые мои коллеги её не очень любят. И их можно понять: после длительной работы с CoreData для перехода на YapDatabase нужно действительно несколько вывернуть мозг.

Кроме того, при асинхронной работе с базой через несколько соединений нужно хорошо понимать, как база обрабатывает параллельные запросы на чтение и запись: через одно или разные соединения. А ещё помнить, что объекты обновляются в БД целиком. Нельзя просто сохранить тот экземпляр, который вы прочитали какое-то время назад и модифицировали. Необходимо прочитать объект из базы, изменить его так, как вам нужно, и записать обратно в рамках одной транзакции. В противном случае можно случайно записать в БД устаревшие данные.

Вообще работа с базой очень удобно встраивается в наш реактивный стиль написания кода. Асинхронные шаблоны транзакций (чтение/запись/модификация отдельного объекта) очень просто завернуть, например, в сигналы ReactiveCocoa, и встраивать работу с базой в одну цепочку с отправкой и обработкой сетевых запросов.

Архитектура приложения

Много рассказывать про архитектуру не буду, но совсем не упомянуть о её законах жанра, как говорится, не позволяют. Докладов и статей про MVVM уже очень много (например, классический туториал в версии для Objective-C b RAC: часть 1, часть 2, или статья о реализации этого паттерна для Swift).

Под слоем ViewModels есть набор сервисов, который реализует (и по возможности инкапсулирует) бизнес-логику, логику работы с протоколом и кеширование. Навигация в приложении осуществляется с помощью так называемого роутера, т. е. объекта, инкапсулирующего код, необходимый для открытия того или иного экрана. На самом деле роутеров в процессе стало несколько, поскольку у роутера есть тенденция становиться эдаким очень жирным God Object. Поэтому там, где это возможно, мы стараемся его декомпозировать. Например, за весь процесс регистрации/аутентификации пользователя отвечает отдельный роутер.

По опыту предыдущих проектов мы знали, что Dependency Injection очень упрощает структуру приложения и здорово облегчает изменения в архитектуре. В самом начале мы использовали для DI фреймворк Typhoon, но в ходе оптимизации времени запуска приложения выяснили, что разрешение зависимостей занимает непозволительно долгое время на старте приложения (единицы секунд на слабых устройствах). Поэтому мы перешли на ручной DI через property-based injection. Не сказал бы, что кода стало больше: уровень сервисов в приложении обычно настраивается в одном классе, а вся конфигурация сервисов легко читается. Для share и imessage экстеншенов, естественно, сервисы конфигурируются отдельно, поскольку в этом случае нужен гораздо меньший их набор.

Таким образом, связанность кода была изначально не очень большой, и даже через довольно продолжительное время после начала разработки мы без особого труда смогли вынести часть сервисов и обслуживающего кода в отдельную библиотеку (точнее, даже набор библиотек), которая реализует бо́льшую часть внутренней логики мессенджера, включая работу с протоколом и кеширование, и которую можно встраивать в другие приложения.

Заключение

Быстродействие приложения или работа в офлайне — для нас это не желание быть в тренде, а скорее реальный способ дать удобную возможность для общения конкретным пользователям. Тем, у кого дорогой мобильный трафик или просто плохой интернет. И это довольно серьёзная мотивация, чтобы сделать хорошо. Как получилось в итоге — оценивать пользователям, так что предлагаю вам установить мессенджер и поделиться в комментариях своим фидбеком. Буду рад ответить на вопросы.

habrahabr.ru

Новый российский мессенджер TamTam: что в нем хорошего

Коммуникация между людьми существенно изменилась с появлением мобильного телефона, а способы общения стремительно развиваются. Все началось с электронных писем и сообщений в соцсетях, а сейчас уже 60% владельцев смартфонов пользуются различными мессенджерами. Все чаще появляются недовольные возгласы о нежелательных звонках с призывом перенести общение в мессенджер. Это не просто тренд, а новый устоявшийся способ общения.

В конце мая российские разработчики представили новый мобильный мессенджер TamTam – в нем, как и в других подобных приложениях, можно общаться с друзьями и подписываться на небольшие тематические блоги, каналы. Мы решили сделать обзор TamTam и понять, что же в нем интересного.

С кем общаться

Важный момент – после установки приложения вы сможете найти своих знакомых и сразу им написать. Что вообще редкость для новых мессенджеров или социальных сетей. Все дело в том, что TamTam был создан на базе приложения «ОК Сообщения» – аудитория этого мессенджера досталась новому приложению в наследство.

Еще в TamTam можно найти пользователей социальной сети Одноклассники. Если у вас есть аккаунт в ОК и вы зашли с помощью него в TamTam, то в разделе «Контакты» сможете найти любого человека с профилем в этой социальной сети и написать ему. Таким образом, установив TamTam, вы останетесь на связи с друзьями.

Если аккаунта нет и вы зашли просто по номеру телефона, то подгрузятся контакты из вашей телефонной книги – таких здесь тоже может быть немало. Например, у автора этой статьи в мессенджере нашлись и родственники, и близкие люди, и даже старые знакомые, живущие в регионах. Хороший повод написать друзьям или тем, с кем давно не общался.

Ожидать, что все ваши знакомые уже здесь, конечно, не стоит – приложению всего месяц. То, как быстро они здесь окажутся — в ваших руках. Нравится общаться в TamTam — приглашайте друзей с помощью специальной кнопки в разделе «Контакты».

После установки приложения вы сможете найти своих знакомых и сразу им написать Фото: пресс-служба TamTam

Как общаться

Здесь есть все то, к чему вы привыкли в мессенджерах: можно отправлять не только текстовые сообщения, но и фотографии, записывать видео или аудио, пользоваться эмоджи, гифками, стикерами. Можно даже загрузить прямо внутрь приложения прямую трансляцию – например, из сервиса OK Live. Вставьте ссылку в чате на свой прямой эфир – и собеседник (или несколько собеседников – если это групповой чат) сможет открыть ее прямо внутри мессенджера.

А еще в TamTam есть интересные анимированные стикеры – создатели приложения называют их «живыми». Это и кадры из фильмов, и смешные гифки с животными или детьми, и вообще – все, что может проиллюстрировать мысль лучше всяких слов. Чтобы стикер было проще подобрать, есть поиск: откройте витрину стикеров, введите любое слово: хоть «спасибо», хоть «до встречи» – приложение подберет для вас самые подходящие эмоции.

TamTam – новое приложение, которое активно развивается и дорабатывается, поэтому в нем, справедливости ради, пока есть не все возможности для общения. Однако в скором времени разработчики обещают добавить даже возможность звонить прямо из приложения – в аудио или видеоформате. Говорят, появятся и новые функции, которые помогут разнообразить общение.

Что почитать и посмотреть

Одна из основных функций нового приложения – тематические блоги, или каналы. Это ленты сообщений на определенную тему, на которые можно подписаться и регулярно получать от них обновления. Каналы в TamTam отображаются в том же списке сообщений, что и основные чаты.

Каналы в мессенджере уже ведут самые разные люди: простые пользователи, которые делятся интересными мыслями, видео и фотографиями; знаменитости – например, певица Глюкоза, и популярный журналист и телеведущий Юрий Дудь; крупные СМИ, в том числе Комсомольская правда. Есть каналы с новостями и юридическими советами, каналы про гаджеты и историю, каналы блогеров и журналистов. В общем, в TamTam можно не только общаться, но и есть что почитать – и даже посмотреть: многие авторы выкладывают фотографии и интересные видео.

Каналы в мессенджере уже ведут самые разные люди, в том числе и певица Глюкоза Фото: пресс-служба TamTam

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

В следующем материале мы расскажем, как развиваются каналы в современных российских и зарубежных мессенджерах и почему скоро они станут неотъемлемой частью нашего с вами мобильного общения.

Подписывайтесь на канал Комсомольской правды в TamTam

www.kp.ru

ТамТам - Политика конфиденциальности

1. Общие положения

1.1. ООО «Мэйл.Ру» (ОГРН 1027739850962, Россия, 125167, г.Москва, Ленинградский проспект д.39, стр.79), именуемое в дальнейшем «Компания» или «Лицензиар», обязуется соблюдать конфиденциальность данных и информации, предоставляемых пользователями (далее – «Лицензиат» или «Пользователь») при использовании программы для ЭВМ приложения «ТамТам» для мобильных устройств на платформе Android и iOS (далее – «Мессенджер»).

1.2. Данной Политикой устанавливаются правила, в соответствии с которыми Компания осуществляет сбор и/или обработку данных и информации, которые предоставляет Лицензиат или которые становятся доступны Компании в процессе использования Лицензиатом Мессенджера.

1.3. Условием использования Мессенджера является согласие Лицензиата с настоящей Политикой, размещенной на Сайте Компании по адресу: team.tamtam.chat/policy. При каждом доступе и/или фактическом использовании Мессенджера Лицензиат соглашается с условиями настоящей Политики, а также с условиями лицензионного соглашения, доступного по адресу team.tamtam.chat/license (далее – «Соглашение»), в редакциях, которые действовали на момент фактического использования Мессенджера

Значение некоторых терминов, используемых в настоящей Политике, определяется Соглашением.

2. Обрабатываемые Компанией данные и иная информация

2.1. Учетные данные и иные данные Лицензиата обрабатываются Лицензиаром в целях надлежащего исполнения Соглашения.

2.2. Под учетными данными понимаются сведения, которые Лицензиат предоставляет самостоятельно на этапе регистрации в Мессенджере путем заполнения регистрационной формы (в случае регистрации по номеру телефона) и некоторые из предоставляемых в процессе его использования.

2.3. Регистрация в Мессенджере возможна через другие сервисы Лицензиара или сервисы третьих лиц, как например Одноклассники или Google (далее — «Аккаунт в социальной сети»). Используя эту функциональную возможность, Лицензиат соглашается с тем, что Лицензиар получает доступ к определенной информации Лицензиата из Аккаунта в социальной сети, публикует и хранит ее в Мессенджере.

2.4. Под иными данными понимаются связанные с Лицензиатом данные, которые становятся доступными Лицензиару в процессе использования Лицензиатом Мессенджера и/или сервисов аффилированных лиц и/или партнеров. Такие данные могут включать в себя в том числе информацию о технических средствах (устройствах) и способах технологического взаимодействия с Мессенджером и/или сервисами аффилированных лиц и/или партнеров (в т. ч. IP-адрес хоста, вид операционной системы Лицензиата, тип браузера, географическое положение, данные о провайдере и иное), об активности Лицензиата, а также иные данные, получаемые указанными способами.

2.5. В целях исполнения Лицензионного соглашения и предоставления Лицензиату доступа к использованию функционала Мессенджера, Лицензиар развивает, совершенствует, оптимизирует и внедряет новый функционал Мессенджера (включая сервисы и продукты информационного, рекламного, образовательного, развлекательного и иного характера), в том числе с участием аффилированных лиц и/или партнеров. Для обеспечения реализации указанных целей Лицензиат соглашается и поручает Лицензиару осуществлять с соблюдением применимого законодательства обработку (включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), сопоставление, извлечение, использование, обезличивание, блокирование, удаление и уничтожение) учетных и иных данных Лицензиата, включая результаты автоматизированной обработки таких данных, в том числе в виде целочисленных и/или текстовых значений и идентификаторов, их передачу аффилированным лицам и/или партнерам во исполнение такого поручения на обработку, а также осуществлять сбор (получение) его учетных и иных данных от аффилированных лиц и/или партнеров.

2.6. Лицензиару может быть доступна иная информация, относящаяся к Лицензиату и оставленная последним по своему усмотрению в процессе использования Мессенджера, которая не обрабатывается Лицензиаром, в том числе для достижения вышеуказанных целей.

2.7. Обработка учетных и иных данных Лицензиата осуществляется в течение всего периода времени с момента регистрации в Мессенджере и до момента его удаления, если иное не предусмотрено действующим законодательством. Лицензиат может отозвать свое согласие на обработку учетных и иных данных путем направления соответствующего уведомления Лицензиару по адресу, указанному в разделе 5 настоящей Политики. В таком случае Лицензиат должен прекратить использование Мессенджера.

2.8. В целях надлежащего исполнения условий Лицензионного соглашения, Лицензиар принимает меры по обеспечению безопасности. Для реализации указанных целей Лицензиат соглашается, что учетные и иные данные могут быть переданы третьим лицам, в том числе в случаях, предусмотренных применимым законодательством, в объеме, необходимом для выявления, расследования и пресечения противоправных действий.

2.9. Лицензиат соглашается на отражение его учетных и иных данных, а также иной информации в профиле Лицензиата в рамках функционала Мессенджера, а также на то, что такие данные будут считаться общедоступными, если иной режим доступа к ним не был выбран Лицензиатом в пределах функционала Мессенджера. Лицензиат соглашается, что информация, включая учетные и иные данные, может быть доступна другим пользователям сети Интернет с учетом существующего функционала Мессенджера (который может изменяться время от времени Лицензиаром). Лицензиар может ограничивать использование третьими лицами информации из Мессенджера, в том числе в коммерческих целях. Использование информации Лицензиаром определяется настоящим Соглашением.

3. Применимое право

Обработка данных Пользователей осуществляется на основании законодательства РФ.

4. Действие настоящей Политики

Компания оставляет за собой право вносить изменения и дополнения в настоящую Политику. Новая редакция Политики вступает в силу с момента её размещения на сайте по адресу: team.tamtam.chat/policy. Лицензиат обязуется самостоятельно регулярно знакомиться с новыми редакциями Политики.

5. Обратная связь

Лицензиат может сообщить свое мнение о принципах Компании по вопросам соблюдения конфиденциальности, направив письмо по адресу на [email protected]

team.tamtam.chat

как мы делали новый мессенджер

Привет! Меня зовут Юрий Буянов, я разработчик мессенджера TamTam. Сегодня я хочу рассказать вам немного о том, как он создавался и как устроен изнутри. TamTam — это новый мессенджер Mail.Ru Group, который был разработан на базе приложения «ОК Сообщения». В 2016 году мы сделали отдельный мессенджер в Одноклассниках для тех, кто часто переписывается в соцсети и кому удобнее это делать с помощью отдельного приложения.

Эксперимент получился удачным, поэтому в начале года мы решили развивать «ОК Сообщения» как отдельный от соцсети мессенджер под собственным брендом TamTam, но уже с набранной стартовой аудиторией. Уже за первые недели после запуска в TamTam появились десятки тысяч каналов, а аудитория продолжила общаться так же активно, как и в «ОК Сообщениях». Это стало возможным в том числе благодаря быстрой работе приложения и нескольким техническим фишкам. О них я расскажу подробнее.

Сложности, которые натолкнули на идеи

Начнём со сложностей: именно они принесли нам идеи, которые потом реализовались в продукте и в итоге превратились в преимущества приложения. Речь прежде всего о быстрой и стабильной работе мессенджера.

Стартовая аудитория TamTam — из самых разных уголков мира, в том числе с нерегулярным покрытием мобильной сети (а иногда и с полным отсутствием стационарного интернета). В некоторых странах СНГ за пределами крупных городов 2G-соединение — вообще фактически единственное окно в интернет.

Важно было и то, что далеко не все потенциальные пользователи TamTam каждый год бегут покупать новый айфон или ГОРЯЧУЮ НОВИНКУ от Samsung. По статистике, самый популярный девайс под iOS у наших пользователей — iPhone 5s, а под Android — недорогие Galaxy выпуска 2014—2015 годов. При этом у TamTam достаточно молодая аудитория: 28 % дневной аудитории — это люди в возрасте 27—34 лет, а более половины пользователей (54 %) — младше 35 лет.

Поэтому одним из приоритетных направлений в разработке мессенджера для нас с самого начала была оптимизация приложения с точки зрения как быстродействия, так и работы с сетью. Словом, требовалось незаметно для пользователей сделать так, чтобы приложение работало при любом уровне подключения. И при любом росте аудитории тоже. TamTam в первые же месяцы показывает неплохие цифры: число установок уже приближается к 3 миллионам, а число каналов уже больше 50 000.

Как мы делали приложение быстрым

Быстродействие с точки зрения пользователя — это в первую очередь скорость запуска. Время, которое проходит до отображения нового контента (например, при открытии чата с новым сообщением по push-уведомлению). Плавность работы в целом — в частности скролла. В iOS-команде мы стараемся тестировать и замерять быстродействие на iPhone 5 и iPhone 4S. Андроид-команда имеет в распоряжении Galaxy S3 и Мегафон логин за 1000 рублей. Как следствие, на более мощных девайсах приложение просто летает.

В каждой тестовой сборке можно включить счётчик кадров в секунду, а в логи и в систему статистики записывается длительность выполнения операций в узких местах.

Например, на этом графике показано время с момента запуска приложения при открытии по пушу до момента, когда пользователь увидит это конкретное сообщение на экране. Два падения на графике соответствуют включению контент-пушей на половину и на всех пользователей.

Несмотря на обилие инструментов и метрик, главным инструментом оценки быстродействия приложения остаются субъективные ощущения. Никто не может точно ответить, какая задержка в миллисекундах допустима при открытии экрана сообщения, но практически каждый может сказать, есть ли у него ощущение того, что приложение «тупит».

Как мы оптимизируем? В первую очередь выносим всё, что можно, из главного потока: работу с БД (об этом чуть ниже), работу с сетью, сериализацию и десериализацию данных, процессинг картинок и даже вычисления, связанные с вёрсткой текста.

Когда мы запускаем приложение или открываем экран чата, выполнение тяжелых операций в фоне не спасёт от видимой задержки. Так что одни операции вроде вёрстки бабблов всё равно нужно оптимизировать по времени, а другие лучше делать сразу при получении сообщения и кешировать результат их выполнения в базе.

При выборе сторонних решений и библиотек в узких местах мы тоже старались учитывать быстродействие и компактность. В частности, именно поэтому мы выбрали MessagePack (причём для iOS специально делали бенчмарк разных реализаций), поменяли библиотеку для маппинга данных в объекты с Mantle на YYModel и остановились на lz4 в качестве алгоритма компрессии трафика.

Кроме того, для достижения плавности работы интерфейса мы симптоматически оптимизируем рендеринг:

  • избегаем offscreen-рендеринга, нагружающего процессор;
  • заранее в фоне ресайзим картинки вместо использования работающих в главном потоке стандартных UIViewContentMode;
  • делаем наши иерархии UI более «плоскими» и простыми;
  • кешируем те объекты и данные, создание которых слишком затратно. Начиная с высоты ячеек с текстом и заканчивая YYTextLayout (объект, который хранит информацию об отображении текста в библиотеке YYText), NSAttributedStrings и даже самими UIViews.

Во всех списках идёт ручная вёрстка без auto layout. Хотя auto layout мы тоже очень любим и используем декларативную вёрстку с помощью Masonry в коде — но только там, где это целесообразно.

Офлайн и работа при плохом интернете

При работе с сетью мы стараемся минимизировать трафик и задержки за счёт выбора быстрого компактного протокола и агрессивного кеширования.

В качестве способа общения с сервером мы используем только TCP-сокеты и бинарный протокол. Это позволяет нам как получать обновления с сервера в реальном времени, так и работать в более привычном режиме «запрос — ответ».

Сам API, т. е. набор команд поверх низкоуровневого протокола, можно в будущем при желании реализовать поверх другого транспорта, например на веб-сокетах. При всём этом нам не придётся трогать верхнеуровневую логику работы приложения.

Сами пакеты состоят из заголовка фиксированной длины со служебной информацией: код команды, версия протокола, длина пэйлоада. Ответы на запросы могут приходить в разном порядке и вперемешку с командами сервера, поэтому в заголовке есть sequence number, позволяющий связать запрос и ответ.

В качестве формата для пэйлоада мы решили попробовать messagepack. Он не требует жёсткого задания схемы, очень компактный и имеет довольно шустрые библиотеки сериализации под множество платформ. По сути, это эффективный бинарный аналог JSON. Для того чтобы ещё более снизить потребление трафика, мы сжимаем пэйлоад алгоритмом lz4. Его мы также выбрали за скорость и небольшую нагрузку на CPU и батарейку.

Один из главных способов обеспечить нормальную работу приложения в условиях плохой сети — максимальная поддержка офлайн-режима. Приложение должно кешировать максимум данных, тратить меньше времени и трафика на синхронизацию и уметь откладывать отправку команд до появления соединения. Причём соединение может вернуться даже при следующем запуске приложения, т. е. все отложенные задачи по отправке надо уметь сохранять в БД.

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

С историей сообщений в чате всё чуть сложнее. Грузить заранее всю историю всех чатов бессмысленно, но что мы один раз получили — то мы кешируем и стараемся больше не запрашивать. Если посмотреть на то, какие участки истории чата закешированы, мы увидим, что в истории есть «разрывы». Например, с обновлением списка чатов после логина мы увидели, что последнее сообщение в чате изменилось. При этом у нас в БД есть участок (или несколько участков) истории чата, закешированный в ходе предыдущей сессии. Кроме того, мы не знаем, сколько сообщений есть на сервере между последним сообщением в чате и предыдущим закешированным сообщением, и это добавляет своих сложностей.

Поэтому, кроме самих сообщений, мы храним метаданные о непрерывных кусках истории — чанках, которые мы закешировали. При скролле чата мы используем эту информацию: она помогает нам определить, грузить следующую страницу из БД или отправлять запрос на сервер. А может быть, делать и то, и другое. При получении новых участков истории с сервера эти чанки меняют размер и сливаются друг с другом (в случае если клиент понимает, что только что полученный участок истории соединяет два разрозненных чанка, имеющихся в БД).

Поскольку многие операции можно выполнять в офлайне, мы разработали механизм сохранения задач. Он умеет запускать задачи, дожидаться их выполнения, сохранять их состояние в БД или загружать и запускать при старте приложения.

Задачи могут сохраняться в БД, они инкапсулируют в себя всю логику выполнения. Поскольку зависимости от других задач и от состояния приложения могут быть довольно сложными, то слежение за ними тоже реализовано в самих задачах. Например, задача отправки сообщения с фотографией должна убедиться в том, что фотография обработана, загружена на CDN (за это отвечают отдельные задачи), дождаться (при необходимости) сетевого подключения и только потом непосредственно попытаться отправить само сообщение.

Два приёма для плавной работы приложения

Немного расскажу о паре приёмов, которые мы использовали для обхода ограничений системы, мешающих нам сделать дружелюбный и плавный интерфейс. На примере iOS-приложения.

Одной из сложностей при разработке стал бесконечный скролл в чате, т. е. незаметная для пользователя подгрузка истории сообщений при прокрутке чата вверх. В 99 % случаев пользователь находится именно внизу чата и хочет проскроллить его вверх для того, чтобы прочитать старые сообщения. Здесь мы столкнулись с двумя проблемами.

Во-первых, постоянное натыкание на верхнюю границу списка сообщений и ожидание подгрузки каждые несколько экранов раздражает. Эту проблему было не очень сложно решить: мы не дожидаемся, пока пользователь доскроллит до самого верха и увидит там «крутилку», а стараемся заранее запрашивать предыдущие страницы истории еще во время скролла: как из локального кеша, так и с сервера. При наличии сообщений в кеше или на быстром соединении пользователь просто не успеет доскроллить до самого верха к тому моменту, как мы сможем отобразить новую пачку сообщений.

Вторая проблема оказалась гораздо серьезнее: после вставки такой страницы в начало списка сообщений (сделанного на основе UITableView) contentOffset для уже загруженного участка сдвигается, и скролл «прыгает». Конечно, мы можем посчитать размер вставляемой страницы и изменить contentOffset обратно, но это приводит к резкой остановке анимации скролла, что некрасиво и обескураживает пользователя. Мы пытались делать это различными способами, включая такие, например, как отслеживание contentSize таблицы через KVO, но неизменно терпели неудачу: UITableView просто хронически не приспособлен к тому, чтобы элементы добавлялись в начало списка.

В итоге после ряда попыток мы смогли решить эту проблему, применив своего рода «хак»: переворачиваем список вверх ногами с помощью .transform, а затем переворачиваем каждую ячейку в обратном направлении. Пользователь ничего не замечает, но теперь contentOffset отсчитывается снизу, и подгрузка старых сообщений никак на него не влияет.

У этого решения есть ряд подводных камней, но их мы тоже сумели обойти, и нам они не мешают. Во-первых, необходимо конвертировать перевёрнутые индексы ячеек в индексы в вашей модели данных, и обратно. Если у вас больше одной секции, вычисления будут очень сложными, так что лучше ограничиться одной. Конечно, это не даёт нам использовать плавающие заголовки секций, которые на экране чата пригодились бы, например, для отображения разделителей по дням в истории. Но плавающие разделители в итоге оказалось не так сложно сделать вручную.

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

Вторая сложность, с которой мы столкнулись, — это анимированные и асинхронные обновления списков. Если несколько независимых обновлений происходят почти одновременно (например, подгружается страница истории вверху чата и приходит новое сообщение внизу), то данные, используемые делегатом tableView, могут измениться, даже если не закончилась анимация предыдущего обновления.

Это может привести к тому, что UITableView отрендерит неправильную ячейку или вообще упадёт: это ещё более вероятно, если вы используете предыдущий хак. Можно, конечно, обратиться к методу reloadData, синхронному в UITableView, однако это приводит к морганиям, остановке скролла и прочим раздражающим пользователя вещам.

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

Persistence

Для кеширования данных в iOS-клиенте мы используем библиотеку YapDatabase.

YapDatabase — это Key-Value хранилище поверх SQLite с очень большим набором возможностей. Мне эта библиотека кажется гораздо более простой и гибкой, чем CoreData. Здесь можно выбрать механизм сериализации объектов в базе: по умолчанию это NSCoding, а мы используем всё тот же MessagePack.

YapDatabase не требует наследования объектов от базового класса или реализации какого-то протокола, не привязывает объекты к контексту. Чтение и запись производятся с помощью синхронных или асинхронных транзакций.

А при помощи системы расширений доступны все те же возможности, что и в «настоящей» БД: произвольные SQL-запросы и индексирование нескольких полей, полнотекстовый поиск, подписка на изменения (как в NSFetchedResultsController), подключаемое шифрование, работа с CloudKit и т. д. Hello-world примеры работы с БД приводить здесь не буду, они есть в вики на github.

На мой вкус, YapDatabase повышает продуктивность и понятность кода, но некоторые мои коллеги её не очень любят. И их можно понять: после длительной работы с CoreData для перехода на YapDatabase нужно действительно несколько вывернуть мозг.

Кроме того, при асинхронной работе с базой через несколько соединений нужно хорошо понимать, как база обрабатывает параллельные запросы на чтение и запись: через одно или разные соединения. А ещё помнить, что объекты обновляются в БД целиком. Нельзя просто сохранить тот экземпляр, который вы прочитали какое-то время назад и модифицировали. Необходимо прочитать объект из базы, изменить его так, как вам нужно, и записать обратно в рамках одной транзакции. В противном случае можно случайно записать в БД устаревшие данные.

Вообще работа с базой очень удобно встраивается в наш реактивный стиль написания кода. Асинхронные шаблоны транзакций (чтение/запись/модификация отдельного объекта) очень просто завернуть, например, в сигналы ReactiveCocoa, и встраивать работу с базой в одну цепочку с отправкой и обработкой сетевых запросов.

Архитектура приложения

Много рассказывать про архитектуру не буду, но совсем не упомянуть о её законах жанра, как говорится, не позволяют. Докладов и статей про MVVM уже очень много (например, классический туториал в версии для Objective-C b RAC: часть 1, часть 2, или статья о реализации этого паттерна для Swift).

Под слоем ViewModels есть набор сервисов, который реализует (и по возможности инкапсулирует) бизнес-логику, логику работы с протоколом и кеширование. Навигация в приложении осуществляется с помощью так называемого роутера, т. е. объекта, инкапсулирующего код, необходимый для открытия того или иного экрана. На самом деле роутеров в процессе стало несколько, поскольку у роутера есть тенденция становиться эдаким очень жирным God Object. Поэтому там, где это возможно, мы стараемся его декомпозировать. Например, за весь процесс регистрации/аутентификации пользователя отвечает отдельный роутер.

По опыту предыдущих проектов мы знали, что Dependency Injection очень упрощает структуру приложения и здорово облегчает изменения в архитектуре. В самом начале мы использовали для DI фреймворк Typhoon, но в ходе оптимизации времени запуска приложения выяснили, что разрешение зависимостей занимает непозволительно долгое время на старте приложения (единицы секунд на слабых устройствах). Поэтому мы перешли на ручной DI через property-based injection. Не сказал бы, что кода стало больше: уровень сервисов в приложении обычно настраивается в одном классе, а вся конфигурация сервисов легко читается. Для share и imessage экстеншенов, естественно, сервисы конфигурируются отдельно, поскольку в этом случае нужен гораздо меньший их набор.

Таким образом, связанность кода была изначально не очень большой, и даже через довольно продолжительное время после начала разработки мы без особого труда смогли вынести часть сервисов и обслуживающего кода в отдельную библиотеку (точнее, даже набор библиотек), которая реализует бо́льшую часть внутренней логики мессенджера, включая работу с протоколом и кеширование, и которую можно встраивать в другие приложения.

Заключение

Быстродействие приложения или работа в офлайне — для нас это не желание быть в тренде, а скорее реальный способ дать удобную возможность для общения конкретным пользователям. Тем, у кого дорогой мобильный трафик или просто плохой интернет. И это довольно серьёзная мотивация, чтобы сделать хорошо. Как получилось в итоге — оценивать пользователям, так что предлагаю вам установить мессенджер и поделиться в комментариях своим фидбеком. Буду рад ответить на вопросы.

Автор: Digal

Источник

www.pvsm.ru

ТамТам - Политика конфиденциальности

1. Общие положения

1.1. ООО «Мэйл.Ру» (ОГРН 1027739850962, Россия, 125167, г.Москва, Ленинградский проспект д.39, стр.79), именуемое в дальнейшем «Компания» или «Лицензиар», обязуется соблюдать конфиденциальность данных и информации, предоставляемых пользователями (далее – «Лицензиат» или «Пользователь») при использовании программы для ЭВМ приложения «ТамТам» для мобильных устройств на платформе Android и iOS (далее – «Мессенджер»).

1.2. Данной Политикой устанавливаются правила, в соответствии с которыми Компания осуществляет сбор и/или обработку данных и информации, которые предоставляет Лицензиат или которые становятся доступны Компании в процессе использования Лицензиатом Мессенджера.

1.3. Условием использования Мессенджера является согласие Лицензиата с настоящей Политикой, размещенной на Сайте Компании по адресу: team.tamtam.chat/policy. При каждом доступе и/или фактическом использовании Мессенджера Лицензиат соглашается с условиями настоящей Политики, а также с условиями лицензионного соглашения, доступного по адресу team.tamtam.chat/license (далее – «Соглашение»), в редакциях, которые действовали на момент фактического использования Мессенджера

Значение некоторых терминов, используемых в настоящей Политике, определяется Соглашением.

2. Обрабатываемые Компанией данные и иная информация

2.1. Учетные данные и иные данные Лицензиата обрабатываются Лицензиаром в целях надлежащего исполнения Соглашения.

2.2. Под учетными данными понимаются сведения, которые Лицензиат предоставляет самостоятельно на этапе регистрации в Мессенджере путем заполнения регистрационной формы (в случае регистрации по номеру телефона) и некоторые из предоставляемых в процессе его использования.

2.3. Регистрация в Мессенджере возможна через другие сервисы Лицензиара или сервисы третьих лиц, как например Одноклассники или Google (далее — «Аккаунт в социальной сети»). Используя эту функциональную возможность, Лицензиат соглашается с тем, что Лицензиар получает доступ к определенной информации Лицензиата из Аккаунта в социальной сети, публикует и хранит ее в Мессенджере.

2.4. Под иными данными понимаются связанные с Лицензиатом данные, которые становятся доступными Лицензиару в процессе использования Лицензиатом Мессенджера и/или сервисов аффилированных лиц и/или партнеров. Такие данные могут включать в себя в том числе информацию о технических средствах (устройствах) и способах технологического взаимодействия с Мессенджером и/или сервисами аффилированных лиц и/или партнеров (в т. ч. IP-адрес хоста, вид операционной системы Лицензиата, тип браузера, географическое положение, данные о провайдере и иное), об активности Лицензиата, а также иные данные, получаемые указанными способами.

2.5. В целях исполнения Лицензионного соглашения и предоставления Лицензиату доступа к использованию функционала Мессенджера, Лицензиар развивает, совершенствует, оптимизирует и внедряет новый функционал Мессенджера (включая сервисы и продукты информационного, рекламного, образовательного, развлекательного и иного характера), в том числе с участием аффилированных лиц и/или партнеров. Для обеспечения реализации указанных целей Лицензиат соглашается и поручает Лицензиару осуществлять с соблюдением применимого законодательства обработку (включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), сопоставление, извлечение, использование, обезличивание, блокирование, удаление и уничтожение) учетных и иных данных Лицензиата, включая результаты автоматизированной обработки таких данных, в том числе в виде целочисленных и/или текстовых значений и идентификаторов, их передачу аффилированным лицам и/или партнерам во исполнение такого поручения на обработку, а также осуществлять сбор (получение) его учетных и иных данных от аффилированных лиц и/или партнеров.

2.6. Лицензиару может быть доступна иная информация, относящаяся к Лицензиату и оставленная последним по своему усмотрению в процессе использования Мессенджера, которая не обрабатывается Лицензиаром, в том числе для достижения вышеуказанных целей.

2.7. Обработка учетных и иных данных Лицензиата осуществляется в течение всего периода времени с момента регистрации в Мессенджере и до момента его удаления, если иное не предусмотрено действующим законодательством. Лицензиат может отозвать свое согласие на обработку учетных и иных данных путем направления соответствующего уведомления Лицензиару по адресу, указанному в разделе 5 настоящей Политики. В таком случае Лицензиат должен прекратить использование Мессенджера.

2.8. В целях надлежащего исполнения условий Лицензионного соглашения, Лицензиар принимает меры по обеспечению безопасности. Для реализации указанных целей Лицензиат соглашается, что учетные и иные данные могут быть переданы третьим лицам, в том числе в случаях, предусмотренных применимым законодательством, в объеме, необходимом для выявления, расследования и пресечения противоправных действий.

2.9. Лицензиат соглашается на отражение его учетных и иных данных, а также иной информации в профиле Лицензиата в рамках функционала Мессенджера, а также на то, что такие данные будут считаться общедоступными, если иной режим доступа к ним не был выбран Лицензиатом в пределах функционала Мессенджера. Лицензиат соглашается, что информация, включая учетные и иные данные, может быть доступна другим пользователям сети Интернет с учетом существующего функционала Мессенджера (который может изменяться время от времени Лицензиаром). Лицензиар может ограничивать использование третьими лицами информации из Мессенджера, в том числе в коммерческих целях. Использование информации Лицензиаром определяется настоящим Соглашением.

3. Применимое право

Обработка данных Пользователей осуществляется на основании законодательства РФ.

4. Действие настоящей Политики

Компания оставляет за собой право вносить изменения и дополнения в настоящую Политику. Новая редакция Политики вступает в силу с момента её размещения на сайте по адресу: team.tamtam.chat/policy. Лицензиат обязуется самостоятельно регулярно знакомиться с новыми редакциями Политики.

5. Обратная связь

Лицензиат может сообщить свое мнение о принципах Компании по вопросам соблюдения конфиденциальности, направив письмо по адресу на [email protected]

team.tamtam.chat


Смотрите также