Stachka.Mobile

Section Curator: Dmitry Peterson

Hello! I am Dmitry Peterson, Director at mobile.Simbirsoft. We have been developing mobile applications for more than 10 years and we are included in the leading group of companies according to many specialized ratings.

The market of mobile applications and its profit are growing from year to year. It is a huge industry now, and its growth will not stop. Our works take prizes in competitions, because we know how to make applications convenient, useful and competitive.

We want to share our experiences on how to make high-quality mobile applications. We divided the reports of the section according to the degree of complexity and focused them on different levels of development skills.

The beginner mobile developers will learn about the basic tools and ways to work with them. We will show what architectures are used in projects; their pros and cons, what features you should pay attention to at the beginning of your professional development. These reports will also be of interest to developers of other areas who are interested in the mobile sphere. Experienced developers will be offered the reports on the ways to solve non-trivial tasks.

The speakers will talk about problems that may arise when choosing the wrong ways to solve them. At the same time, we will pay special attention to new technologies and modern practices in the development of mobile applications.

As part of the discussion club, technical experts from well-known mobile development companies will review current trends, and tell about the main points that should be noted in the practice of mobile development. The viewers will be able to ask questions to the invited experts.

Questions and suggestions on the section can be sent here:
E-mail: dmitry.peterson@simbirsoft.com
Facebook: https://www.facebook.com/dmitry.peterson


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

Android становиться все более разнообразным. Формально, это уже не одна операционная система, а целый букет – к привычным Android, Android Wear и Android TV теперь добавились Android Things и Android Automotive (и это не то же самое, что и Android Auto). А ведь есть еще Android One и Android Go. Данный доклад это попытка разобраться в данном многообразии и немного его систематизировать: мы сделаем короткий обзор каждой системы, поймем, чем она отличается от классического Андроида и попробуем написать кросс-Андроидное приложение, которое подойдет под все перечисленные версии.

В докладе речь пойдет о целесообразности использования ФРП (Functional Reactive Programming) в современной мобильной разработке на примере RxSwift под iOS. Еще год назад мне казалось, что невозможно писать код без использования Rx, а все самописные велосипеды, призванные в очередной раз реализовать паттерн Observer - от лукавого. Во всех проектах, в которых мне довелось поучаствовать, Rx стал одной из главных библиотек, насквозь пронизывающей все слои приложения. В последнее время мое отношение к Rx стало гораздо более прагматичным в силу ряда причин, о которых я расскажу в докладе. Цель моего доклада - поглубже посмотреть на устройство одного из самых популярных фреймворков для ФРП под iOS - RxSwift и на его примере показать, что Rx как и любой инструмент - это лишь удобный способ решения определенного спектра задач. Мы поговорим о best practises при использовании Rx, тонкостях использования различных компонент любого современного Rx фреймворка, таких как Subject, Scheduler, Trait и других, рассмотрим способы тестирования сложных time-dependent фич, коснемся вопросов о контрактах Rx и многом другом, а главное, попытаемся понять, помогут ли все эти знания сделать наш проект более понятным, поддерживаемым и bug-free

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

Мир изменился. Я чувствую это в медленном выпуске фичей. Чувствую это в немасштабируемости решений. Чувствую в увеличении размера мобильных команд. Многое, что когда-то было преимуществом... теперь утеряно. Потому что никого, кто помнил это, нет более среди команды. Были выкованы Великие Модули. Часть из них были кор-модулями, могучими правителями сети и баз данных. Часть из них были фича-модулями, в них содержалось могущество и воля, для того чтобы править каждой из фич. Но они все были обмануты. Ибо в стране Мордор, в жерле Роковой горы были созданы DI и Routing, чтобы подчинить себе все приложение.

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

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


Поговорим о том, как мы умудряемся не переписывать всё заново уже три года подряд В программе: - Реальная история о масштабированиях команды - Как жить, когда твоя архитектура — единорог - Почему нельзя просто взять и переделать вообще всё - Но иногда можно взять и переделать почти всё, затронув ничего

Александр Едунов
iOS разработчик @ Kenkou
Санкт-Петербург
Большую часть времени мы тратим на разработку UI не потому что это сложно, а потому, что требования дизайнеров не всегда соотносятся с доступными из коробки средствами кастомизации. Как результат, нам бывает сложно подготовить действительно переиспользуемый компонент. Я покажу как можно уменьшить пропасть между дизайнерами и разработчиками, как быстро и удобно переводить макет в код.

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

В современном мире сложно представить бизнес-приложение которое бы не работало с Сетью. Часто источником данных для мобильного приложения является собственный веб-сервис заказчика, а для транспорта данных выбирается проверенная временем связка HTTP+REST+JSON. Однако, все чаще можно встретить gRPC как замену этому подходу. Давайте внимательно посмотрим на эту технологию. План доклада: — Чем плох REST? — Как появился gRPC и какие преимущества он дает. — Запросы и стримы gRPC. — Интеграция в iOS-приложение. — Проблемы и решения.

Google активно пытается захватывать все рынки, до которых только дотягивается. Firebase это их попытка закрыть все нужды мобильной разработки в серверной части разом и перенаправить мобильный трафик на свои сервера. В докладе я отвечу на следующие вопросы: - Можно ли уволить всех back-end разработчиков и не сойти с ума? - Так ли Firebase хорош как его малюет Google? - Можно ли обойтись без него в Android разработке? - На кой он вообще iOS разработчикам? - Придется ли продавать последние штаны если стартап c Firebase выстрелил? - Есть альтернативы или мы уже под колпаком? - Какие задачи можно закрыть с помощью Firebase, if you're brave enough

В мире быстрых изменений и хайпа стоит иногда остановиться и вспомнить старые добрые понятия. Такие как панк-рок и Clean Architecture. Давайте же окинем Clean свежим взглядом, и я объясню, почему эти архитектурные принципы все ещё актуальны. Мы вспомним их суть, разберем старые заблуждения и обдумаем новые идеи. Тезисы: - Почему люди продолжают не понимать Clean Architecture и почему архитектура важна. Что такое хорошая архитектура. Рассмотрим заблуждения о том, что архитектура не нужна. - На чем основана Clean Architecture. Истоки, подробные принципы, что привносит в проект. - Подробнее рассмотрим Clean Architecture и ее основную схему: что значат круги и что за этим кроется. Dependency Rule, слои. Заблуждения раскрытые тут: количество слоев, невозможность объединения с делением по фичам. - Круги и сущности. Рассмотрим подробнее и с примерами. А также развеем старые добрые заблуждения. - Entity, одна из самых сложных для осознания тем. Покажу пример и разжую, что же это такое. Заблуждения: Entities vs DTO, что за логика, зачем писать хорошие Entity. - Interactor. Приведу пример и поясню отличия. Заблуждения: UseCase vs Interacor, отдельные или объединенные. Это часть терминологии, которая запутала множество людей. Я напомню что есть что и буду топить за отдельные Interactor'ы, как более удобный способ организации и переиспользования кода. - Адаптеры интерфейсов. Поясню что это такое, что входит в слой. Разберем подробнее что такое Repository или Gateway и как они трактуются. (Заблуждения: Объединять ли Interactor и Repository. Расскажу почему так делать не надо, какие принципы это нарушит.) - Слой фреймворков, детали. Станет ясно, что такое детали и что дает нам выделение их во внешний слой. - Посмотрим на развернутую схему. Разберем подробно пересечение границ. Что такое Boundaries и зачем они нужны. Что может пересекать слои. Нужен ли маппинг. - Пройдем типичный сценарий. Станет ясно течение данных в проекте с Clean Architecture с расстояния. Уложится в голове общая схема. Ещё несколько новых мыслей: - Расскажу используются ли Boundaries в проектах c RxJava, покажу схему. - Поясню про Controllers и способ их применения и в мобильных приложения. - Поделюсь личным заблуждением из статьи и тем как называется этот паттерн, чем плох. - Hot! Хайпанем, разобрав популярные сравнения Clean Architecture c другими «архитектурами». Пройдемся по MVP, MVVM, VIPER, MVI.

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