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

Но как организовать архитектуру мобильного приложения с платформенным UI и логикой на C++? Как разделить ответственность компонентов, организовать навигацию, написать кучу биндингов к Swift и Java, и при этом иметь возможность кастомизировать поведение разных платформ? Какие различия в UI iOS и Android и как с этим жить?

Ответы будут на примере развития архитектуры UI одного из наших важнейших приложений.

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

Kotlin/JVM, Kotlin/Native, Gradle, MPP - эта комбинация позволит создавать мобильные приложения, на фреймворках родных для iOS и Android, и при этом не писать весь код дважды.

Доклад акцентирован на разработке под iOS и Kotlin/Native, так как эта сторона мобильной разработки с использованием Kotlin менее известна широкой публике.

TCP был впервые имплементирован в 70-х годах и прекрасно справлялся со своей задачей в эру проводного Интернета. Но беспроводные сети отличаются переменной пропускной способностью, высоким random packet loss, сменой IP и MTU на лету и прочими вещами, которые приводят к деградации TCP-соединения. Поэтому Одноклассники и Google активно занимаются оптимизацией сетевого взаимодействия (новые алгоритмы congestion control) и, в качестве крайней меры, переводом сетевого взаимодействия с TCP на UDP.

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

Мы поговорим о сетевых стеках iOS/Android, проблемах TCP и полностью пройдем путь перевода приложения на UDP.

В докладе будут:
- проблемы беспроводных сетей и стека TCP/IP;
- перевод с TCP на UDP сетевого взаимодействия (API, images, video streaming);
- написание своих UDP-протоколов.

А также: как отменить запрос на фото в своем приложении, если это фото больше не нужно, а запрос уже ушел на сервер, что при этом произойдет с вашим TCP-соединением?

Будут раскрыты: Head-of-line blocking, forward error correction (FEC), fast retransmit vs negative ack, MTU discovery, IPMigration, packet pacer... и многое другое:
- рассмотрим особенности и +/- протокола QUIC от Google;
- напишем протокол, ориентированный на беспроводные сети Wi-Fi и 2/3/4G.

Все будет рассказано на примере OKLive — первого Android-приложения для мобильного стриминга в качестве 1080p и основного клиента Одноклассников.

Пример для тех, кто дочитал ;)
У вас есть приложение — аналог Инстаграм. Открывая приложение, пользователь видит ленту из первых 3 фото на экране ;)
Вам надо как можно быстрее отобразить фото в плохой сети (как Wi-Fi на некоторых конференциях).
RTT 200 мс, фото 200 кб, сеть 1 Мбит/сек, packetLoss 5% (bulk loss) ;)
Варианты решения:
- скачать последовательно по TCP/HTTP1.1 без pipeline, тогда, пока выполняется следующий запрос (за RTT), канал будет простаивать;
- скачать параллельно в 3 потока по TCP/REST;
- скачать последовательно в pipeline HTTP2/TCP;
- скачать по QUIC/UDP.

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

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

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

Как выполнять 1000+ UI тестов на каждый Pull Request и не сойти с ума?

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

I truly believe that quality is not what programmers should care about. They must care only about speed—close tasks as soon as possible— which means make money. Won't this attitude ruin the project and turn the code base into a mess? Yes, it will. If the project doesn't care about its quality either. There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications. I wrote about this: http://www.yegor256.com/2018/03/06/speed-vs-quality.html

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

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

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

Как люди учатся новым навыкам, и какие из этого следствия для программистов. Пять стадий прокачки: новичок, продвинутый, компетентный, специалист, эксперт.

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

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

Мы поговорим:
1. О проектировании API библиотеки: какие особенности и подводные камни могут встретиться.
2. На что обратить внимание при написании кода и тестировании.
3. Как облегчить жизнь своим пользователям и, как следствие, себе.
4. Об особенностях релизного цикла и взаимодействии с другими командами.
5. Что необходимо для публичного релиза, и какой постпродакшн ждёт разработчика библиотеки.

Рассказ будет полон неподдельными историями из жизни команды мобильной библиотеки YandexSpeechKit :)

Истории про разработку игр, от Паскаля до Свифта, от СССР до РФ, от 10 рублей до миллиона долларов. Без нравоучений, запинок и бестолковых советов.

* Можно ли прожить, разрабатывая игры?
* Можно ли прожить, не разрабатывая игры?
* Какие знания, навыки и уроки пригодились для подобной жизни?

Вы получите ответы на любые вопросы, кроме вышеперечисленных.

* Как быстро, азартно и весело распределённой командой сделали странный сервис, заработали немного баксов и теперь не прочь провернуть это снова и снова.
* Почему остановились на выбранной идее?
* Может ли архитектура iOS-приложения приводить в восторг?
* Могут ли видеоблогеры быть полезными обществу?
* Можно ли раскидать юристам Apple, что реджектить приложение — некрасиво?
* Почему наш офис ещё не в Дубаи?

Ответы на эти и другие вопросы под катом.

История развития continuous integration в команде мобильной разработки Авито.

Цель доклада рассказать про голосовые приложения. Что это такое, как они отличаются от графических и как они создаются. На примере приложения для Google Assistant расскажу про все этапы создания таких приложений и поведаю о подводных камнях. Мы пройдёмя от проектирования до разработки, затронем публикацию и тестирование.

Технологии: Google Assistant, Alexa, Алиса, DialogFlow.

* Сколько нужно инженеров, чтобы сделать Uber.
* Что такое кросс-платформенная архитектура.
* Одно приложение на десятки фич – взгляд со стороны одного разработчика.
* Синхронизация работы десятков команд.
* Скорость, качество, полнота исполнения – на что делается акцент.
* Оценка качества.
* Что делать, если все сломалось.

On the paper, everyone agrees that tests are important. And yet, more often than none, tests are still considered the poor cousin in the development industry. In the rare case when we actually take time to write them, we more often than not consider it a cumbersome task, and give it less thoughts than the "real code".

But tests are often as important, if not more, as the code that will be shipped on the Play Store. After briefly explaining the basics of testing, this talk will go through various common mistakes and bad practices found in real-life unit tests, and will give techniques and tips to make those tests cleaner and better.

Часто можно услышать фразу: «Вот, если переписать все с нуля» или «Здесь слишком много legacy-кода, мы тонем. Проще переписать все». Но что значит «переписать работающее приложение с нуля»? Как его улучшить и сделать технологичным и масштабируемым? Так ли это просто?

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

Поделимся bad-практиками с использованием RxJava, Dagger. Покажем на примерах, как unit-тесты спасали нас от непредвиденного изменения кода, и на примере app.zeplin.io расскажем, как дизайнеры помогли разработчикам интегрировать UI.

В App in the Air самописные View и ViewGroup используются и в хвост и в гриву.

На докладе я расскажу о том, что интересного можно делать с Custom View и ViewGroup, почему это может здорово помочь достижению 60 FPS, какие правила по написанию и поддержке этого кода я выработал для себя, и, в качестве бонуса, расскажу о некоторых интересных оптимизациях и о нюансах того, что лежит под капотом.

- Корутины в Котлине. Уже стабильны?
- Как реализовать сетевой запрос на корутинах?
- Как сделать кэш для этого запроса?
- Как убедиться, что нет проблем с жизненным циклом?
- Как протестировать все слои?
- Как правильно обрабатывать ошибки?
- ???
- PROFIT!

Methods to increase app stability, lesser crash rates, observe app behaviours using AndroidVitals.

Расскажу, что такое технологическая платформа Spotify, и как с помощью кастомных Gradle-плагинов мы лечим (делаем) головную боль других разработчиков в компании. Помимо разбора кейсов использования самописных плагинов, поговорим о практических вещах: best practices и способах публикации.

We all have heard stories about modularization, faster builds, quicker iterations and all the good things we get through it. But when it comes to actually breaking your legacy into modules, your code can give you a serious run for money. In this talk I will share how 60+ Android Devs at Booking got together to defeat the legacy and modularized the app to get 10 times faster builds. If you attend this talk you will be able to learn the best practices about modularizing your large code bases and avoid the pitfalls that we discovered in journey.

When promoting Kotlin over Java to your friend the first argument you’ll probably use will be its powerful syntax: in-house nullability support, default arguments, delegated properties, data & sealed classes, etc. These features are really the stuff we’re benefiting from everyday, but if we’ll take Java annotation processors then sadly the only information they can get about our code will be Java-related and no info about Kotlin-specifics. In this talk we’ll find out how to use Kotlin metadata added to the bytecode to get info about Kotlin-specific features in the code and utilise it during annotation processing.

- Чем single-activity лучше чем multy-activity (скорость, анимации, ЖЦ и др.);
- как можно перевести любое приложение на новый подход;
- как выстраивать DI-скоупы для оптимального использования памяти;
- как выстраивать навигацию, чтобы не сойти с ума;
- как обрабатывать deep-link'и;
- как делать общий BottomNavigationBar (и другие общие элементы);
- как делить приложение на модули;
- как обрабатывать клавиатуру и статус-бар...

...список может быть дополнен.

In this talk we are going to see the internals of the new Dexing Compiler D8, introduced in AS 3.0 as experimental, D8 will give us faster and smaller outputs of dex files. We will understand better how is the Dex Processing in Oreo/P from the ART perspective, and how is affected in the new bundle apps.
Additionally, we will see more about R8 a replacement for Proguard used in AS 3.2

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

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

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

SRP, OCP, YAGNI, KISS, SOLID... Чем больше занимаешься разработкой, тем больше новых акронимов узнаешь и тем больше тебя убеждают, что им нужно следовать прямо и неукоснительно. При этом о каждом паттерне или принципе можно сказать:

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

В докладе поговорим о границах применимости пяти основных принципов объектно-ориентированного программирования и о том, к чему может привести over-SOLID engineering.

People are getting interested in functional programming now and designing their software as functions that transform data from one type to another, rather than recipes that sequentially modify some state. The claim is that we can "reason about" our software better, design by contract is about capturing that reasoning as statements about the inputs and outputs of our functions, and connecting those together to make sure that our software works correctly for _any_ valid input, not just the few cases we thought about in unit tests.

Swift is not a functional programming language. Pushing too hard to make it one fights Swift and breaks Cocoa.

But Swift has absorbed some fantastic lessons from the functional world, and while value types may not quite be the present, they are clearly the future. We’ll explore how decades of work in functional languages have influenced Swift, and how you can use those features best while staying true to Swift.

Anatoly will drop some knowledge bombs on how to do ASO, how reviews affect your ratings, how to work with your users in order to get to the top of app stores. Will teach you how to get on the App Store Today tab and why it may be not for the best.

Doubt if you should attend? Doubt no more if you want to learn all insides of ASO and how to develop apps that get to the top of the charts.

"Latency Numbers Every Programmer Should Know". Надеюсь, и вы с ней знакомы. Но, тем не менее, она датируется 2012-м годом и ориентирована на десктопы. А как бы она выглядела для современного iPhone?

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

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

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

В ходе доклада мы научимся понимать Auto Layout. Разберемся, какую задачу он решает и как он это делает. Разберемся, когда его использовать не стоит. И самое главное, научимся "проектировать ограничения", а не "подгонять ограничения под ответ".

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

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

Во время разработки одного приложения передо мной встала проблема выноса множества однотипных частей кода. Долгие поиски и тот факт, что разработка бэкенда – не мой вариант, привели меня к библиотеке JavaScriptCore.

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

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

А также мы более подробно остановимся на различных вариантах реализации частей видеоредактора для платформы iOS на основе AVFoundation, а также посмотрим, как можно применять обычные подходы проектирования к нашей предметной области.

In a perfect world many of us would choose to have a 100 % Swift codebase, while others would choose to have a 100 % Objective-C codebase - both of which are perfectly fine. Would you choose to maintain a mixed codebase? Probably not, but that‘s the reality many of us live in. Legacy Code, don‘t we all love it?

While Mix & Match between Swift and Objective-C works great out of the box, there are many rough edges. Let‘s explore some tricks we can use to bring first-class APIs to both worlds - restoring our sanity, and harmony between both languages.

Поговорим о модели акторов - вероятном будущем модели конкурентности в Swift. Расскажу, кто такие акторы и какие проблемы языка они призваны решить. Что об этом думает К. Латтнер? Есть ли применение модели в iOS-разработке? На сколько граблей нужно будет наступить, чтобы реализовать модель уже сейчас? Расскажу на собственном опыте.

Let's discuss how to use Cipher, what is AES and how to authenticate a message. Dive deep into basic cryptography basic primitives. Let's make it a group therapy session.

Designing simple and expressive libraries is hard, but is a worthy goal. It's too easy to accidentally add complexity. Math can fix that. Math can give us guide-rails that point us to an ideal simple and expressive design. In this talk, we'll use basic abstract algebra to guide us toward a simple and expressive animation library. We'll use animations to help us understand abstract algebra as we discover the true algebraic structure of animations. Only after thinking hard about the structure, do we begin an implementation. In the end, I'll present some examples of working with this animation library we derived over the talk.

Презентация

Accessibility is a very important topic, that is often overlooked or, at best, added as an after-thought. This is very unfortunate, as Apple is doing a great job at providing good and simple to use APIs to make our apps accessible. Apple is fully committed to Accessibility and in providing an equal user experience for all their users, and so should we. The goal of this talk is to give an in-depth look at Accessibility on iOS, as well as outlining the reasons on why to use Accessibility by giving real-world examples of its importance.

Расскажу про опыт разработки, запуска, стабилизации и ускорения функциональных тестов в Авито. Вместе разберем общие проблемы, которые встречаются на пути каждого, кто пытается внедрить тестирование в своем проекте: от самых простых (вида какие тесты писать) до сложных (вроде как прогонять тесты на нескольких симуляторах и физических компьютерах наиболее эффективно). Узнаем, как можно ускорить тесты простыми методами, как вылечивать красные тесты, поддерживать инфраструктуру для прогона тестов на нескольких версиях iOS, обходить ограничения TeamCity, анализировать поведение инфраструктуры во время прогона. Дам идеи, укажу на инструменты, которые используем мы.