"А во Flurry пользователей больше!"... Пожалуй, каждый проект сталкивался с отличающимися значениями метрик в разных платформах аналитики. А что, если эти метрики являются для нас ключевыми? По каким отчетам ориентироваться, принимая решение?

- Поделимся опытом AppMetrica — за полтора года разработки собственной системы аналитики мы прошли все стадии принятия неизбежного.
- Расскажем про отличия в расчетах разных платформ аналитики и чем они обусловлены.
- Поделимся опытом сотрудничества с продуктовыми командами разных Яндекс.Приложений, благодаря которым мы выработали собственный подход к расчету основных метрик и можем сказать, что такое "сессия" и кто такой "пользователь".
- Разберем сценарии, когда ни один из готовых подходов не подходит.

Deep Dive в онтологию систем мобильной аналитики — как сделать свою и начать ей доверять.

- Бессерверная архитектура бэкендов.
- Микросервисная архитектура.
- Мобильные бэкенды.
- Облачные технологии.

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

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

Некоторое время назад компания Apple опубликовала исходные коды языка Swift. С тех пор LLVM получил еще более широкую популярность в среде мобильных разработчиков. Тем не менее, не все понимают роль LLVM в процессе компиляции, и не все осознают мощь этого фреймворка.

Цель моего доклада — рассказать о том, как использовать LLVM в связке с языком Swift и показать, что это не "rocket science".

В своем докладе я расскажу о том:

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

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

- WatchDog. Что это такое? Схема реализации с таймером и схема реализации на RunLoop'e.
- Как собирать результат работы WatchDog. Примеры того, что можно таким образом найти, и что мы нашли на проекте ICQ.
- Как работать с полученными результатами. Анализ стеков потоков. Профилирование с учетом расходов на синхронизацию.
- Проблемы при работе с WatchDog. Системные механизмы и популярные библиотеки, вызывающие проблемы. Методы обхода этих проблем. Итоговые параметры, применяемые на проекте ICQ.

- Что такое "чистая" архитектура приложений. Чем грозит "грязная" архитектура, чем от нее отличается "чистая" архитектура, и какой от нее профит.
- История появления VIPER.
- Идея VIPER. Как изменяется структура приложения при применении этого подхода.
- Опыт использования VIPER в Rambler&Co. Что мы изменили и добавили.
- Работа с VIPER на примере user story из реального приложения.
- Выводы: чем помогает VIPER и когда его использовать не стоит.

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

В докладе мы рассмотрим не только возможности, которые предоставляет система для продвинутого форматирования, но и все тонкости, которые с этим связаны:
- основные термины типографики применительно к iOS;
- символьные атрибуты — какие из них наиболее подходят к конкретной задаче;
- отличия отрисовки текста в UITextView и UILabel;
- TextKit и способы расширения его возможностей.

А чтобы теория не была такой утомительной, вместо скучных слайдов будет интерактивное демо с примерами!

В данном докладе рассмотрим, как сегодня чувствует себя вредоносный программный код на устройствах с ОС iOS без jailbreak. И конечно, ответим на вопрос о том, дают ли последняя версия ОС и отсутствие jailbreak на устройстве гарантию, что на нем нет вредоносного кода.

В своём докладе я расскажу о подходе к построению навигации в больших приложениях на примере демо-проекта, приближенного по архитектуре к приложению Avito.

Данная архитектура позволяет поддерживать DeepLink’и и iPad в существующем приложении, показывать плашки Push-уведомлений в верхнем видимом модуле, совершать переходы из верхнего видимого модуля, вызванные корневым модулем приложения, а также централизовано управлять анимацией переходов.

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

По ходу доклада я также расскажу о том, как выглядела навигация в приложении Avito раньше; о том, какой она стала с началом использования архитектуры VIPER; о проблемах, которые мы увидели, и об итоговом решении. Также вкратце рассмотрим, что же скрывается под капотом у этой системы.

1. Описание предметной области, объектов и понятий, с которыми работает приложение.
2. Выделение сущностей и связей между сущностями, представление в терминах ORM.
3. Описание конфигурации ORM и ObjectCache.
4. Работа с БД
- применение паттерна Команда и Компоновщик для выполнения операций на БД;
- конфигурация исполнителя команд;
- команда как транзакция в БД;
- инструменты, доступные ORMLite для реализации транзакций.
5. Проблема доступа из UI потока к данным, изменяемым в других потоках.
6. Memoization подход для решения проблемы доступа из разных потоков.
7. Описание архитектуры кэшей с применением memoization.
8. Задача поддержания когерентности кэшей;
- использование HaMeR framework для актуализации UI кэша;
- использование механизма блокировок и батч-операций над данными в кэшах.
9. Ограничения ORM ObjectCache при работе с объектами DAO.
10. Реализация DAO с расширенными возможностями работы с ObjectCache.

1. Обзор паттернов и средств, которые применялись для построения архитектуры android приложений.
2. Обзор "новых старых" паттернов программирования, которые сейчас модны в построении архитектуры — Clean architecture, MVP, MVVM, DI. Краткий их обзор, чем они лучше/хуже предыдущих паттернов.
3. Обзор новых инструментов, которые сейчас используются при написании приложений — Dagger 2, RxJava и других.
4. Как все эти паттерны и инструменты помогут нам написать "тестируемый код".
5. Рассмотрение самых различных примеров, которые помогут понять, как конкретную задачу необходимо декомпозировать на различные уровни ответственности (какая часть должна быть в data, какая в business, какая в ui), и как должно происходить взаимодействие этих уровней. И как тесты помогают "выпрямлять" архитектуру.

Мотивация: MVP, Clean architecture и т.д. — это все очень хорошо, но создается такое ощущение, что у каждого разработчика свой способ реализации данных паттернов. И к своей реализации он приходит через определенную боль.Для тех, кто только начинает пробовать, существует проблема. Нигде нет конкретных, жизненных примеров, которые чуть более сложнее, чем тривиальные, как писать, да и вообще, с чего начинать.

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

Доклад будет полезен абсолютно всем android разработчикам.

Opus, Ogg, NDK и другие подводные камни.

1) Зачем иногда необходимо использовать нативный код в Android разработке;
2) когда не нужно этого делать;
3) что для этого необходимо настроить в проекте;
4) кодек для сжатия аудио Opus (чем хорош, кто использует);
5) контейнер Ogg (преимущества перед другими);
6) практический пример записи голоса, сжатия кодеком opus и упаковка в Ogg контейнер.

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

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

В процессе разработки нашего Enterprise-ready продукта HyperHive — http://eigenmethod.com/products/hh/ (бренд EigenMethod создан для продвижения продукта на Запад, не удивляйтесь другому домену) мы столкнулись с необходимостью реализации ряда задач на нескольких платформах: iOS, Android, Cordova (Android и iOS), а в перспективе и под Windows для мобильных устройств.

Был вариант реализации под каждую платформу на родных языках, но мы выбрали путь создания кроссплатформенного фреймворка на C++ с последующим его портированием под все целевые платформы.

Функционал фреймворка:
1. Параллельные потоки загрузки данных с сервера и записи в базу (sqlite) и передачи на сервер в рабочих потоках (без блокирования UI).
2. Поддержка Дельта-обновлений при передаче данных (пересылается только разность между двумя версиями данных).
3. Шифрование трафика и базы данных алгоритмами ГОСТ и RSA.
4. Сжатие трафика.
5. Аутентификация и авторизация на сервере, поддержка сессий.
6. Обработка push-уведомлений (MQTT).
7. API для мобильных приложений для предоставления данных, в том числе в оффлайн-режиме.
8. Логирование действий мобильного клиента на сервере.

С задачей успешно справились, но, так как задача нетривиальна и мало освещена в сети, были сложности — как технические, так и в подходе к разработке.

— Космическая скорость разработки приложения (iOs-приложение за неделю);
— Сравнение типичного экрана со списком данных на Objective-C и React Native;
— Поддержка приложения, Debugging;
— Ограничения React Native, которые следует учитывать;
— Бонус: при написании приложения для iOs — 80% Android приложения в подарок :)