Apps Conf 2017

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

Я расскажу и покажу весь диапазон современных средств для мониторинга и отладки сетевых запросов: от самых простых до узкоспециальных - с плюсами/минусами каждого из инструментов и областями их применения.

Навигация между экранами - задача, которая появляется в приложении когда экранов становится больше чем один, то-есть сразу. Стандартные подходы к её решению в iOS (segues, present(_:animated), UINavigationController) обычно используются внутри кода экранов, что приводит к их жесткой привязанности друг к другу и к сценарию, в котором они участвуют.

Доклад о том, как вынести решение этой задачи из Presentation-слоя с использованием паттерна Application Coordinator. Основан на опыте построения навигации между экранами в профессиональных приложениях Avito. Будет интересен тем, кто ищет способ сделать экраны независимыми, переиспользуемыми и легко трестируемыми.

- Рассмотрим случаи, когда нам было бы полезно самим писать backend...на Swift'e, конечно же!
- Разбор open-source библиотек, позволяющих вам писать только Swift-код для работы с реквестами. Остальную REST, OAuth, HTTP-магию они делают сами.
- Напишем с вами API для работы с "юзерами", будем записывать данные в базу, делать Basic-авторизацию. В общем, демо будет максимально приближено к "боевым проектам" )
- Выльем наш бэкенд на Heroku и Digital Ocean (что это за звери, я тоже расскажу).
- Ну и, конечно же, в конце похоливарим на тему: "Зачем вам, как Swift-разработчикам под iOS, писать еще и backend". Дискуссия обещает быть жаркой!

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

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

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

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

Зачастую эти идеи так и пылятся в головах людей по самым различным причинам.

В этом докладе поделюсь историями из жизни:
– Как, потратив несколько выходных за год, удалось сделать пять разных проектов (парочка из которых пропиарилась на тематических ресурсах рунета и даже удостоилась внимания Apple, став Featured в App Store).
– Сколько миллионов заработали (нисколько).
– Почему не разочаровались и не прекращаем работать над pet-project'ами.

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

С быстрым ростом команды и приложений мы столкнулись с новыми для нас вызовами. Стало труднее экспериментировать, code review не решал своих задач, а стабилизация релиза занимала непредсказуемое время. Поскольку мы хотим чаще выпускать новые версии приложений и спать при этом спокойно, то, как инженеры, начали решать эти проблемы с технической стороны, активно используя feature toggles.

Расскажу, когда уместен этот подход, как применяем для стабилизации продукта и приближения к сontinuous delivery. Обсудим приемы борьбы с тех. долгом без ущерба корректности работы.

Современные мобильные устройства по уровню "железа" достигли игровых консолей. Почему же уровень real-time графики мобильных игр заметно отстаёт от консолей и ПК? 

Из доклада вы узнаете о неожиданных особенностях разработки мобильной графики с такими современными API, как OpenGL ES и DirectX, о типичных проблемах и способах их решений. Также о том, как разработчики ведут кровавую войну за каждую миллисекунду и о надежде на светлое будущее в роли графических программных интерфейсов нового поколения Vulkan и Metal.

Ни для кого не секрет, что Swift — это mainstream: его активно продвигает Apple, на нем пишутся все новые фреймворки, многие разработчики начинают именно с него. Но так ли просто мигрировать c Objective-С, если твоему приложению 5 лет и оно имеет большую аудиторию? В докладе мы расскажем о том, как сделать это без ущерба для бизнеса. 

Вы узнаете об этапах такого перехода:
1. Какую бизнес-проблему решали? - Ускоряем разработку, уменьшаем количество багов, проще и быстрее находим новых сотрудников, ограждаем от будущих рисков (старых не поддерживаемых фреймворков, устаревших АПИ).

2. Подготовка текущего Objective-С кода в Swift:
а) Поддержка в Objective-С nullabity для всех интерфейсов.
б) Замена старых Objective-С библиотек без поддержки Swift или поиск замены для них.
в) Описание код стайл для Swift внутри команды. 
г) Настройка работы storyboard, assets через swiftgen.

3. Улучшение архитектуры приложения для Swift: 
а) Не было слоя routing как такового, для Swift добавили его.
б) Перестройка под protocol oriented programming.

4. Подводные камни и интересные моменты, которые вскрылись по пути: 
а) Старый код для работы с АПИ очень сложно переписать - нашли решение, как через extension постепенно переписывать. 
б) Увеличилось время загрузки приложения. 
в) Настройка swiftgen. 
г) У ReactiveCocoa нет типизации у сигналов, и без этого работать в ними в Swift не удобно. - разработали решение, как получать типизированые значения.
д) При сериализации ответа от сервера нет уверенности, что поле существует, хоть оно и помечено как nonnull.
е) Генерация из struct классовых proxy-объектов для работы со struct в Objective-С с помощью Sourcery.

iOS-приложения Superjob это: 
• 3 приложения в AppStore для B2C и B2B-аудиторий; 
• более 1 млн. пользователей; 
• стабильные позиции в ТОП-3 приложений в категории «Бизнес»;
• ~60% кода проекта переведено на Swift.

Доклад сделан с большим упором на особенности Objective-C.

Мы поговорим про:
* анализ ошибок средствами llvm;
* статический анализ кода;
* макросы, которые повышают устойчивость вашего кода к рефакторингу;
* Runtime и Unit-тесты;
* проверочные скрипты на этапе сборки.

Clean architecture в связке с MVP - самый распространенный подход к архитектуре Android-приложений. Но подойдет ли он всем? Скорее всего, нет.

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

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

Не так давно Google представил собственное решение для кроссплатформенной разработки, которое выглядит очень интересно. Но стоит ли на него обратить внимание и пробовать использовать? Особенно когда уже есть есть React от Facebook? Как будет работать необходимое вам решение на одной из платформ?

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

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

Изучим имеющиеся фреймворки и сравним лучший из них с серверными компилируемыми языками. Также будут затронуты вопросы микросервисной архитектуры, проблемы и best practices в серверной разработке.

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

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

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

Рассказ основан на личном опыте оптимизации запуска Яндекс.Карт, описывает весь процесс от осознания проблемы до получения результата, подкреплен множеством технических подробностей и реальных примеров. Доклад является концептуальным, содержит конкретные предложения по разработке мобильных приложений с быстрым запуском и будет полезен iOS-разработчикам любого уровня.

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

Уверен, что почти все используют при разработке Lint. Это прекрасный инструмент, который довольно легко расширяется абсолютно любыми проверками. Есть только одно "но" – у Lint очень плохо с документацией и, чтобы разобраться с его расширяемостью, придется довольно много времени потратить за поиском хоть какой-то документации. 

В своём докладе я постараюсь максимально подробно рассказать про расширяемость Lint'а – как оно было раньше, как оно есть сейчас, как всё это дело тестировать и дебажить – и сделаю это на конкретном примере, с которым столкнулась наша команда.

* Почему размер приложения это важно.
* Как формируется размер приложения в AppStore.
* Оптимизация на уровне файлов внутри IPA-пакета. Структура IPA, степень сжатия файлов внутри пакета.
* Оптимизация на уровне исполняемого файла. Структура исполняемого файла. Объектные файлы и их влияние на размер приложения с учетом разных языков (Swift, Objective-C, C++).

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

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

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

Операционная система Android на устройствах, поддерживающих технологию NFC, теперь может рассматриваться в качестве основы для реализации электронных, машино-считываемых персональных идентификационных документов, наподобие заграничного биометрического паспорта гражданина РФ. Благодаря использованию технологии Host-based Card Emulation (HCE), регулирующейся организацией NFC Forum, мобильный телефон теперь может заменить любое приложение, выполняющееся на интеллектуальной карте (смарт-карте) стандарта ISO7816, сохраняя при этом всю инфраструктуру инспекционного контроля неизменной.

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

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

Поговорим о Virtual/Augment/Mixed/Merged Reality - что это такое и как работает.

Более подробно рассмотрим Mobile VR: 
- Samsung Gear VR Powered by Oculus Rift; 
- Google DayDream и Cardboard;
и обсудим, как и с помощью какого инструментария можно разрабатывать приложения.