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

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

В рамках доклада мы познакомимся с архитектурой Android Automotive. Поговорим о преимуществах и заглянем в Hardware Abstraction Layer, для того чтобы узнать, как происходит интеграция с системами автомобиля. Я расскажу о том, какие возможности на данный момент предоставляет платформа разработчикам, и почему нам стоит обратить свое внимание на рынок Connected Cars.

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

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

Этот подход, скорее всего, не подойдёт аутсорс-командам, так как нужна постоянная связь с продакт-менеджерами и возможность влиять на требования к разработке продукта.

Пользователи ВК на Android очень ждут темную тему. Чтобы их порадовать, нам нужно перекрасить более 300 экранов, пробраться через legacy в верстке и динамически поменять стили без перезагрузки Activity.

Мы часто говорим об удобстве разработки для программиста: “Архитектура, Многомодульность, чистый код…”.
Несмотря на это, не так много приложений могут похвастаться действительно хорошо реализованным UX’ом в проекте.
Поговорим о том, как мы можем менять в лучшую сторону UX приложения с минимальными затратами, и почему это не только задача дизайнера.

1. Что такое Bluetooth low energy. BLE4 и BLE5 - что нового.
2. Архитектура Bluetooth на платформе Android.
3. Как работать с 4 Bluetooth-устройствами и получить минимальную задержку.
4. Как избежать частых ошибок, используя BLE на Android.
5. Известные и неизвестные баги Bluetooth Android, с которыми боремся четвертый год.

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

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

В данном докладе будет рассказано, как и зачем писать UI-тесты, как сэкономить время и переиспользовать код, и раскрыта практика, как научить QA писать тесты.

- Структурный шаблон проектирования прокси;
- Какими способами можно его реализовать на Android, их плюсы и минусы;
- Подробный разбор Dynamic Proxy: как использовать, а главное для чего;
- Разбор внутреннего устройства Dynamic Proxy на Android;
- Обсуждение производительности Dynamic Proxy;
- Пишем свой механизм Dynamic Proxy, путем генерации байткода в runtime
- Составление DEX-файлов голыми руками;
- Динамическая загрузка DEX-файлов во время исполнения, работа с DexClassLoader.

Весной 2017 года в рамках Early Access Program мы ввязались в разработку приложения с мгновенным запуском и за 3 месяца из скудной документации и сырого SDK собрали продукт, готовый к релизу в Play Store. С тех пор прошло два года, технология по-прежнему существует, радикально за это время изменившись. Снизился порог вхождения, а интеграция Instant Apps упростилась до установки одного флага в манифесте.

В процессе доклада мы разберёмся, откуда есть пошли Android App Bundles, причём тут вообще Dynamic Delivery, познакомимся с новыми Gradle-плагинами, попробуем забыть старые, а также попробуем найти все сюрпризы, которые приготовили для нас разработчики SDK.

(Нет, это не тот датабайндинг, который работает через раз и предлагает смешивать XML-вёрстку с Java-выражениями.)

Типичное приложение: парсим из JSON в структуру/DTO, складываем в префы или SQLite, выводим на экран.
По событиям пользовательского ввода отправляем обратно в БД или на сервер.
Это настолько рутинно, что может и должно быть автоматизировано.

Предлагаю единый интерфейс для записи и чтения данных в/из памяти, массива байт, префов, БД (последнее в разработке); подписки на изменения. Готовые методы для привязки свойств вьюшек к этим обзёрвабельным значениям. (Android и JavaFX)

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

В перспективе: потенциал для использования на сервер-сайде, простая реализация метода PATCH, пригодная для кэширования и распределёнки семантика.

Мы разрабатываем несколько приложений для миллионов пользователей по всему миру, и многие фичи запускаются под А/B-тестами. В силу специфики сочетание скорости и качества разработки для нас критично. Однако при такой большой кодовой базе, множестве А/B-тестов и наличии нескольких поколений “легаси” общих UI-компонентов, держать ритм становилось все сложнее.

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

У Badoo и других приложений компании есть долгая история использования одной и той же базовой платформы. Эксперименты с поддержкой различных приложений с разным набором плюшек начались достаточно давно: пробовали использовать одну кодбазу с разным набором условий или просто копипастить. В конечном итоге все это выливалось в трудности с поддержкой и внедрением новых фич.

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

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

В прикладной Android-разработке мы часто сталкиваемся с тем, что нам надо писать код, который мы все так любим: XML-код.

После компиляции приложения мы получаем на выходе те же .xml-файлы внутри apk, но их уже просто так нельзя открыть в тестовом редакторе, потому что оно бинарное и зовётся это чудо Android XML.

В этом докладе мы подумаем, зачем надо было изобретать свой формат, какие варианты реализации (sic!) XML лежат внутри APK/AAR/AAB, а также рассмотрим инструменты, которые можно использовать, чтобы пенетрировать эти форматы всяким образом.

Доклад для всех, кто устал от медленной сборки Android-приложения и тормозящей IDE.

Расскажу, как мы прокачали сборку в монорепозитории с несколькими приложениями. Будет в основном про gradle, оптимизации, метрики и про наши грабли.

1. Оформление IT-бизнеса: Россия VS зарубежные юрисдикции. Плюсы и минусы.
2. Налоговые и корпоративные аспекты при выборе юрисдикции.
3. Оформление отношений между фаундером и инвестором. Корпоративный договор. Соглашение об опционе. Конвертируемый заем.
4. Правовая охрана объектов интеллектуальной собственности. Что нужно и не нужно патентовать?
5. Международная регистрация товарного знака и регистрация в России.
6. Регистрация ПО в России и в зарубежных странах. Депонирование, промышленный образец, Роспатент, Библиотека Конгресса США.
7. Охрана ПО в качестве изобретения: патентование в России и за рубежом. Система PCT.
8. Правильные правоотношения с работниками и подрядчиками. Оформление необходимых договоров и иных документов с целью предотвращения краж интеллектуальной собственности.
9. Установление ноу-хау (секрет производства) на предприятии. Коммерческая тайна.
10. Ответы на вопросы.

* Пользуются ли вашим продуктом клиенты с особенными потребностями?
* В чем потребности таких пользователей?
* Что зависит от дизайнера, разработчика, менеджера?
* Какие есть инструменты?
* Как легко встроить доступность в процесс разработки продукта?

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

Секция будет в стиле BOF.

Переезд в другой город, страну, континент, планету не так уж прост. Разберем по шагам, как сделать это с максимальной выгодой и получить удовольствие вместо нервного тика.

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

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

Что общего у Мерил Стрип, Генри Форда и Альберта Эйнштейна? Все они, несмотря на свои успехи в профессиональной жизни, страдали от различных проблем. Этот доклад не о разработке, а о разработчиках.

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

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

Programming languages, frameworks, paradigms, deployment models, hardware and software configurations change very often and fast. However, there are a few other things that also change, and which scare us. First, it’s the inevitable trend of working out of office and even out of company, in distributed temporary projects – most of us are not ready for that and don’t know how to do it. Second, the attention to the quality of code we were paying ten years ago is not what the future demands from us – programmers become a very expensive component of any project and they must think about the maintainability mess they used to leave behind. Third, the world of open source grows quickly and staying out of it is not an option anymore, however many of us don’t know how to deal with it. Fourth, we are getting closer to customers and this is what many of us are not ready for, since we used to work from behind an army of product owners, project managers, and customer relationship managers – this will be changed in the future and we must be ready. Fifth, the quickly growing arsenal of cloud services makes it very important for programmers to understand DevOps and know how to use not only frameworks and libraries, but also hosted services. These five trends are important to consider and get ourselves ready for them.

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

Design / Test / Repeat.

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

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

В iOS-разработку я пришел, разрабатывая один самых популярных игровых движков - cocos2d. Это очень сильно отпечаталось на моем восприятии software engineering’a и подходу к разработке.

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

Я расскажу о том, как важны эмоции. Не абстрактно важны, а для дела — на работе в IT. Эмпатия — это наше восприятие эмоций, своих и чужих. Я буду рассматривать ее как рабочий инструмент.

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

Мы поговорим о том, как учитывать свои и чужие эмоции, чтобы получать то, что мы хотим легче и быстрее. Упомянем концепцию Non-violent communication Маршала Розенберга, основные принципы когнитивно-поведенческой терапии (CBT) и даже "эмоциональный интеллект".

Расскажу, как мы строили автотестирование в Авито. Что получилось хорошо, а что хотелось бы исправить. С чем непременно придется столкнуться тем, кто начнет этим заниматься "с нуля", и с чем столкнулись мы, когда казалось, что все успешно сделано.

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

В своём докладе я расскажу о тех элементах функционального стиля программирования, которые уже проникли в промышленные языки программирования, такие как Swift и Kotlin, а также о том, что пока туда не попало (но может когда-нибудь попасть!). Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому они смогли сделать удобным его применение «в малом», предусмотрев многие, хотя и не все необходимые компоненты. Впрочем, чем дальше, тем качественнее и полнее соответствующая поддержка реализуется.

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

В приложении нам часто приходится выполнять запросы для получения данных из сети. Но зачастую этим и ограничивается использование инструментов URL Loading System.

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

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

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

- Для начала рассмотрим, что из себя представляют, как устроены in-app-покупки, и как с ними работать на базовом уровне;
- затем теоретически расскажу о максимально "правильном" способе обработки покупок, с валидацией чеков и максимальной защищенностью;
- как устроены автопродляемые подписки, в чем их особенности, как работает триальный период, подводные камни;
- как жить без сервера и почему это путь в никуда, если вы анализируете прибыль подписок по различным рекламным компаниям;
- серверные уведомления об изменении в подписках и как с ними работать;
- отличия между iOS- и Android-платформами.

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

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

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

Для платформ Apple плавность интерфейса - это не опция. UIKit и AppKit не являются потокобезопасными и все операции с интерфейсом могут выполняться только на главном потоке. Таких операций приходится делать крайне много. Учитывая это, возникает потребность планировать задачи главного потока таким образом, чтобы пользователь воспринимал интерфейс отзывчивым.

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

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

Можно допустить ошибку в расчетах, забыть учесть режим Slide Over на iPad, а может отказаться так, что система отдаст Вам какие-то невалидные координаты клавиатуры, и они будут за пределами экрана устройства, или вообще окажется, что система создала второе клавиатурное окно.

В своем докладе я расскажу про эти и другие проблемные места, которые могут возникнуть при работе с клавиатурой, а также поделюсь опытом обнаружения вышеперечисленных проблем – сбор логов, отправка статистики и вывод графиков на dashboard, реализация watchdog’а.

Доклад поднимет широкоизвестный паттерн "Координатор" на реактивный уровень.

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

- Исторический контекст, который привёл к появлению Protocol-Oriented Programming (POP);
- суть POP и основные характерные черты, которые отсутствуют в других парадигмах;
- практические примеры использования POP;
- набор материалов для дальнейшего погружения в тему.

Мы привыкли считать процесс доставки push-уведомлений чем-то неподвластным разработке. Мы добавляем пуши в наши приложения, настраиваем, обвешиваем метриками, но на вопросы, почему пользователи видят лишь часть информации, разводим руками. Apple чётко указывает наше место: ”the delivery of remote notifications is not guaranteed”.

Но, несмотря на отсутствие возможности повлиять на работу APNs-сервиса, всё не так уныло и безнадёжно, как может показаться на первый взгляд. По крайней мере, так подумали мы в команде мобильной почты и подошли к вопросу с другой стороны: что, если мы просто узнаем, какие пуши пользователь не получил, и перезапросим их?

Я расскажу:
* какие жизненные трудности заставили нас встать на эту скользкую дорожку;
* как организован процесс перезапроса пушей;
* про возможности и ограничения push extension'а;
* и неизменно - какие грабли мы собрали в ходе работы.

Как только APNs-сервис перестанет выкидывать наши пуши и увеличит их доставляемость, всё, о чём я собираюсь вам рассказать, станет бесполезным, но AppsConf Moscow 2019 однозначно наступит раньше. Так что заходите узнать, как вы сами можете повлиять на этот процесс.

Расскажу, как начать писать функциональные UI-тесты, сократить регрессионное тестирование огромного приложения до нескольких часов и закончить со стабильным и зеленым на 95% тест-суитом, с запуском тестов на каждый pull request, расскажу, как можно достичь "сотни" в плане зелёности UI-тестов.

Конкретные техники, приемы и наши находки в Авито, которые универсальны и помогут каждому. Доклад будет посвящен iOS, тем не менее, некоторые наши практики могут перенять также команды Android и Web.

Практически любой экран можно представить как набор компонентов. А что, если построить систему, в которой работа над фичей сводится к созданию компонента и написанию логики для него?

Обсудим, как и зачем мы построили такую систему, что из этого поняли и что собираемся делать с этим дальше.

Когда на WWDC 2018 анонсировали возможность создания навигационных приложений под Apple CarPlay, мы решили засунуть наш навигатор пользователям в автомобили. Однако, уже начиная с Keynote, Apple начала вставлять нам палки в колеса.

Я расскажу, как начать разработку под CarPlay, с чем придется столкнуться и какие костыли придется навертеть из-за багов в CarPlay.framework. Поговорим о документации, инструментах разработки и семпл-приложении с WWDC.