Русский
Русский
English
Статистика
Реклама

Mobius

Программа Mobius Android, iOS и всё, что между ними

31.03.2021 14:23:38 | Автор: admin


Совсем скоро пройдёт очередной Mobius (13-16 апреля, онлайн). И теперь, когда известна его программа, пришло время рассказать Хабру, что за доклады там представят.


У конференции будет четыре параллельных трека:
iOS
Android
кроссплатформенный (Flutter, Kotlin Multiplatform)
универсальный (мобильные темы, не зависящие от платформы)


Порой сложно нащупать грань между разными категориями: в iOS-треке есть пара докладов, которые тоже рассматривают Kotlin Multiplatform, но конкретно с iOS-стороны. Поэтому учтите, что где-то деление оказывается условным. А теперь, с этим осознанием, можно погружаться.


Оглавление




iOS


Введение в Apple Metal, Георгий Остроброд


Многих непосвящённых Metal пугает, но этот доклад поможет перестать бояться: позволит освоиться, начав с самых основ. Мы узнаем, что это такое, из чего состоит, как с этим работать и почему это несложно. Будут затронуты следующие темы: сам Metal (рендер и вычисления), MetalKit, Metal Performance Shaders, базовые инструменты для профилирования и отладки.


Чем хороша тема: Докладов и в целом информации про Metal очень мало, а на русском её вообще практически нет.


Чем хорош спикер: Георгий работает в компании, которая делает самый известный на рынке инструмент для художников/иллюстраторов на iOS Procreate. Экспертиза этой компании и лично Георгия в работе с GPU очень высока.




Оптимизация графики на Metal, Георгий Остроброд


После объяснения основ Metal в предыдущем докладе Георгий перейдёт к более продвинутым вещам. Этот доклад рассказывает о методах профилирования и оптимизации графики на Metal, возможных слабых местах и их преодолении, оптимизации подготовки данных, отрисовки и шейдеров, использование compute-шейдеров и их оптимизации.


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


Кому будет полезно: Всем, кто хочет перейти на Metal с OpenGL или с CoreGraphics, или просто хочет начать работать с Metal: любой быстро столкнётся с тем, что его код надо будет оптимизировать.




Оптимизируем размер приложения на практике, Дениз Каплан


Каким бы многофункциональным ни было ваше приложение, оно не должно быть слишком большим. А современные банковские приложения очень многофункциональные поэтому кому рассказывать о снижении размера, как не крупному банку. Дениз на примере работы над приложением Сбербанк Онлайн расскажет:


  • как правильно считать размер приложения;
  • какие метрики важны для оптимизации размеров;
  • как внедрить On Demand Resources в приложение;
  • как снизить размер приложения, не останавливая разработку.

Чем хорош спикер: Дениз является ключевым инженером в Core-команде основного приложения Сбера.


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




Как переписать сетевой слой так, чтобы не пришлось переписывать его снова, Александр Аносов


История о том, как в iOS-приложении Delivery Club переписали сетевой слой. Предпосылки совершенно банальные и до боли знакомы каждому: старое, покрытое пылью легаси, баги с разлогинами, код, запутанный похлеще, чем у Да Винчи. Решение элегантное новый сетевой слой, адаптер для старого протокола, фасад для выбора на основе feature toggle, постепенная раскатка через Firebase, мониторинг нефатальных ошибок. В итоге, без единого изменения на уровне сервисов, все запросы ходят в сеть по-новому.


Изюминку этому рассказу придаёт тот факт, что автор нового сетевого слоя ушел из команды еще до того, как его раскатали на пользователей. Казалось бы, новый сетевой слой, не успев проявить себя, сразу превратится в легаси? Но нет, он действительно оказался качественно продуман, спроектирован и реализован.




Make widget great again, Александр Верестников


Близится год со дня, когда Apple презентовала виджеты на WWDC 2020, но по-прежнему далеко не все умеют с ними работать. Пора это исправить.


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


Чем хорош спикер: Реализовал виджет в своём приложении, поэтому знает о некоторых подводных камнях, с которыми поделится.


Чем хороша тема: Виджетов пока мало меньше, чем стоило бы. Это стоит исправить.




Отслеживание установок на iOS без эвристики и AdvertisementID, Дмитрий Куркин


Apple закрывает доступ к AdvertisementID. Все сервисы трекинга во главе с Facebook воют, что все пропало и так жить нельзя. Вероятность того, что пользователь согласится дать доступ к идентификаторам, очень низка.


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


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


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




Разработка на Kotlin/Native и Swift: Новые технологии и их внутренности, Айдар Мухаметзянов


По очевидным причинам тулинг и технологии вокруг Kotlin Multiplatform несколько отставали на платформах от Apple. Все-таки Kotlin полноправный гражданин в Android-разработке, но не в iOS-мире.


Айдар (JetBrains) расскажет, что делается, чтобы это исправить. Вы узнаете про Kotlin/Native-плагин для AppCode: для чего он был создан и что умеет на данный момент. Спикер покажет свежие разработки в области Kotlin Multiplatform, которые ещё толком не оформились в конечные продукты, и расскажет, как они работают изнутри.


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


Чем хороша тема: Детали работы IDE и нюансы компиляции под капотом интригующая тема, интересно узнать о том, как работают инструменты, которыми пользуешься.




Kotlin Multiplatform Driven Development, Степан Мирский


Доклад об использовании библиотек, написанных на Kotlin Multiplatform (далее KMM), с точки зрения iOS-разработки. Разработку и поддержку каких бизнес-процессов можно оптимизировать с помощью KMM-библиотек? Какую эволюцию KMM-библиотеки прошли в компании спикера? Как там работают с элементами UIKit в связке с KMM?


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


Чем хороша тема: KMM растёт и развивается, всё больше людей используют технологию, и у них возникают проблемы, которые пока не освещены на конференциях.





Android


A/V Sync в Android. Как это работает, Федор Цымбал


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


Из данного доклада вы узнаете о теоретических основах A/V-синхронизации, а также о том, как это реализовано в Android.


Чем хорош спикер: Федор лично работал над синхронизацией видео и звука для созвонов в настольном видео-телефоне (название приложения под NDA)


Чем хороша тема: Решение задачи по синхронизации видео и звука и раньше было полезно, а теперь стало ещё актуальнее.




Как переписать приложение с нуля и потерпеть фиаско, Александр Агейченко


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


Чем хорош спикер: Спикер является тимлидом описанного в докладе проекта и непосредственным участником событий.


Чем хороша тема: Задумывались ли вы когда-либо о том, чтобы переписать приложение с нуля? Александр расскажет интересный кейс, как они попытались это сделать и через какие испытания они прошли на этом пути: проблемы одновременной поддержки двух приложений и разработки фич для двух кодовых баз, сложности с git, раскол и конфликты в команде. Не допускайте подобных ошибок ведь они уже совершили их за вас.




Gradle на прокачку, Сергей Лапин


Доклад про погружение в мир оптимизации Gradle-билдов на нескольких уровнях:


  • Basic для тех, у кого мало ресурсов, но хочется хоть немного оптимизировать сборку;
  • Intermediate для тех, кто готов потратить силы и разок покопаться в билд-пайплайнах;
  • Advanced тем, кто готов заниматься оптимизацией на постоянной основе.
    Всё то, о чем будет рассказано, активно применяется на проекте Vivid Money и постоянно развивается.

Чем хорош спикер: У Сергея большой практический опыт работы с Gradle, и он очень заинтересован в донесении темы до людей.


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




Воркшоп. Распознавание поз: Камасутра с CameraX, Денис Неклюдов


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


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


Чем хорош спикер: Google Developer Expert по Android, Pay и IoT.
Внес лепту в мобильные приложения нескольких стартапов в России, Азии и Европе, сейчас работает в Lyft в солнечной Калифорнии.
Денис внедряет CameraX и Camera2 в одном из проектов Lyft


Чем хороша тема: Возможности работы с CameraX и Camera2 в Android-разработки почти не раскрыты, но API используются во многих проектах




Как мы делаем Яндекс.Карты для Android: DI, Денис Загаевский


Денис расскажет, как приложение делится на модули и как внедряется DI в получившемся многомодульном приложении. Покажет несколько фишек с использованием Dagger 2.


Доклад предполагает, что аудитория что-то знает про Dagger 2, но будет полезен и тем, кто его лично не использует. Подход позволяет его не использовать или использовать только частично (а также постепенно переходить на Dagger 2 или постепенно от него отказываться).


Чем хорош спикер: У спикера 10 лет опыта Android-разработки.


Чем хороша тема: Денис рассказывает интересный кейс использования Dagger 2 в многомодульном проекте. Есть интересные технические решения, которые могут натолкнуть на нестандартные подходы к применению Dagger 2.




UI-тесты в вашем проекте, или Паровозик, который смог, Александр Крылов и Севастьян Жуков


Александр Крылов и Севастьян Жуков хотят рассказать про запуск и поддержку UI-тестирования Android-проекта.


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


Чем хорош спикер: Последние годы спикеры работают в infrastructure team и непосредственно занимаются настройкой Gradle, CI/CD, разработкой и поддержкой инфраструктуры. Александр возглавляет эту команду.


Чем хороша тема: Рассказывают весь путь совершенствования CI/CD инфраструктуры в компании: и почему были внедрены те или иные решения, и почему впоследствии от них отказались.




Я тебя создал, я тебя и отменю. Разбираемся как правильно работать с отменой корутин, Павел Ильичев


Корутины все чаще используются в Android-проектах, но вот тема их отмены недостаточно раскрыта. Павел Ильичёв исправит это своим докладом: он расскажет в каких случаях может потребоваться отменить рабочую корутину вручную, как это сделать правильно, а также как отловить сам момент отмены. Если вы уже пользуетесь корутинами или хотите начать, вам пригодится этот доклад.


Чем хорош спикер: У Павла наработан большой опыт эффективной работы с корутинами в различных задачах.


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




Оптимизация сборок Android-приложений: ProGuard, D8, R8. Тайны обфускации, Валерий Петров


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


  • определим место оптимизации сборки в вопросе оптимизации приложения;
  • разберем, как работают инструменты, которыми мы привыкли пользоваться в паре строк;
  • приоткроем завесу обфускации. Покритикуем существующие реализации. Решим, как с этим жить;
  • станем зрителями гонки вооружений. Разберем сравнительные анализы создателей ProGuard и R8. Проведем свои собственные эксперименты и наконец ответим: что же лучше?

Чем хорош спикер: Плотно работал с ProGuard, R8, D8 и написал большую статью о них.


Чем хороша тема: Каждый Android-разработчик знает о ProGuard, R8, D8. Но вот практической информации о том, как лучше работать с ними, в сети мало.





Кроссплатформа (Flutter, Kotlin Multiplatform)


Как Kotlin разрабатывает фичи на примере корутин и инлайн-классов, Ильмир Усманов


Хотите посмотреть на развитие Kotlin со стороны команды Kotlin-компилятора?


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


Чем хорош спикер: Спикер работает в Kotlin Language Research Team и непосредственно отвечает за разработку корутин и инлайн классов.


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




Kotlin Multiplatform Advanced. Делаем общий DI для iOS и Android, Анна Жаркова


Анна Жаркова расскажет, как организовать работу с DI в приложении на Kotlin Multiplatform:


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

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


Чем хороша тема: Про KMM уже были доклады (в том числе и на Mobius), но это первый Advanced-доклад, рассказывающий про построение DI на уровне мультиплатформенного кода.




Flutter for TV, или Как запилить приложение под умные телевизоры, Александр Денисов


Flutter for Mobile в релизе, Flutter for Web в бете, Flutter for Desktop (MacOS, Linux и Windows) в альфе круто, что Flutter официально поддерживает целых шесть платформ. Но что, если мы хотим запустить свое приложение на телевизоре? К сожалению, о Flutter for TV ничего не слышно, кроме чего-то подобного: Since no official support is there yet, presumably you'll be on your own if you try.


В проекте, над которым Александр сейчас работает, поддерживаются Android TV и Apple TV. Да, приложение Flutter можно запустить на ТВ. В этом выступлении спикер расскажет, как это сделать, с какими трудностями и проблемами можно столкнуться и как их решить.


Чем хорош спикер: Dart & Flutter GDE и лид Flutter-компетенции в EPAM.


Чем хороша тема: Доклад основан на уникальном опыте. Никто еще не пробовал запускать Flutter-приложения на тех платформах, про которые будет рассказывать спикер.




Jetpack Compose for Desktop: Делать UI просто и приятно, Николай Иготти


Сейчас разработчиков уже не удивить названием Jetpack Compose но в том случае, когда речь идёт об Android. А на Mobius будет кое-что новенькое: рассказ об применении этого фреймворка для десктопа и о переиспользовании кода между Android и десктопом.


Переносом Jetpack Compose для этой цели занимается компания JetBrains а Николай Иготти именно оттуда, так что информация из первых рук.


Чем хорош спикер: Николай является лидом разработки проекта Compose Desktop в JB
Чем хороша тема: Сейчас Compose Desktop новое и уникальное решение для разработки UI под десктопные платформы.




Воркшоп. Flutter app: Телеграм на минималках, Андрей Савостьянов


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


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


Чем хорош спикер: Flutter-разработчик с большим опытом. Работает в Surf, в компании, одной из первых в России собравших большую команду Flutter-разработчиков.


Чем хороша тема: К 2021-му "Hello world" на Flutter все уже освоили, а вот наглядная информация по более продвинутым сценариям полезна.




Генерация кроссплатформенной аналитики, Александр Лавриненко


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


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


В ManyChat придумали кроссплатформенное решение, которое помогает не только держать один source of truth, но еще и минимизировать ручной труд. Они живут с этим решением уже полгода, а теперь Александр Лавриненко поделится им и с вами.


Чем хорош спикер: Хорошо знаком сразу с обеими платформами (iOS и Android), ранее уже успешно выступал на Mobius.


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




Круглый стол. Очищаем Flutter от ванили. Как мы искали и нашли архитектурный Грааль, Ярослав Магин и Артем Зайцов


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


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


Чем хорош спикер: Артём и Ярослав авторы своих собственных архитектурных решений. Оба специалиста независимо пошли по одному и тому же пути.


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





Универсальное


Функционал съемки панорам в мобильном приложении от А до Прод. Пилим, внедряем, используем, Геннадий Васильков


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


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


  • Stiching 1 шт. Кроссплатформенная библиотека на C++, собственная разработка;
  • Мобильные приложения 2 шт. iOS и Android;
  • CI/CD 1 шт. Jenkins.
  • Взболтать, но не смешивать. Добавить разработчиков.



Как мониторить скорость и здоровье приложений, и спать спокойно, Александр Попсуенко


Доклад о том, как в Яндексе строили инфраструктуру для отправки метрик скорости работы приложения. А также, как ускорялись и искали причины деградаций скорости.
Целевая аудитория: middle+ Android и iOS-разработчики.
Вы узнаете:


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

Чем хорош спикер: Имеет большой опыт работы в данном направлении и сам занимался построением мониторинга.


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




Итак, вы выбрали UDF-архитектуру. Как моделировать стейт?, Михаил Левченко


С каждым днём декларативный UI набирает обороты. Android, iOS, Flutter и React Native-разработчики активно переходят на MVI/Redux/TEA/BLoC и т.д. Но при всех своих плюсах UDF требует от нас решения новых проблем. Одна из них моделирование состояния вашего приложения. И у неё есть решения!


В докладе сперва разберём Algebraic Data Types и почему для моделирования стейта нам они пригодятся больше, чем ООП. Затем мы перейдём к более сложным вещам научимся работать с нашим стейтом как с миниатюрной базой данных. Все эти трюки будут снабжены практичными примерами и корявыми комиксами докладчика для лучшего усвоения материала.
Доклад будет интересен разработчикам среднего уровня и выше. Стоит посмотреть каждому, кто считает, что мода на архитектурные доклады должна остаться в прошлом.


Чем хорош спикер: Спикер известен не только как автор телеграм-канала с Android-мемами Сохранёнки Джейка Вортона, но и как специалист, прекрасно разбирающийся в проектировании архитектур мобильных решений.


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




Яндекс Go готовит Backend Driven UI, Еркебулан Абилдин


Еркебулан расскажет, как и где будет полезно использовать Backend Driven UI, и поделится решением частых кейсов с небходимостью подстраивать UI под разные группы пользователей. Также вы узнаете, как изменять интерфейс без ожидания нового релиза, когда это нужно продукту. Более того, с помощью Backend Driven UI у маркетинга будет мощный инструмент, помогающий сэкономить время разработчиков и самих маркетологов. Из доклада вы узнаете, как важно найти золотую середину между гибкостью и излишне объёмным ответом API.


Спикер надеется, что данная сессия будет интересна разработчикам, желающим сократить время работы над постоянными изменениями UI (Layout, шрифты, цвета) и уставшим от бесконечных A/B-тестов.


Чем хорош спикер: Реализовывал данную технологию у себя в приложении.


Чем хороша тема: Backend Driven UI давно знаком, но доклад позволяет посмотреть на него с другой стороны. Мы забываем, что это отличный инструмент для A/B тестирования и не только.




Разработчик-преподаватель. Стоит ли заниматься преподаванием?, Екатерина Батеева


Последние несколько лет Екатерина активно преподавала и в этом докладе она хочет рассказать о том, есть ли смысл разработчику идти в преподавание:


  • Какие бонусы это принесёт?
  • Какие навыки можно приобрести и прокачать?
  • А какие сложности возникнут, и как их избежать?

Чем хорош спикер: У Кати большой опыт преподавания и взаимодействия с различными образовательными площадками.


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




Making life better with custom DevTools: Story of Facebook and Flipper, Timur Valiev, Michel Weststrate


Разработчикам доступно много готовых инструментов. Но в крупных проектах этого порой оказывается недостаточно и тогда приходит время создания собственных инструментов
Тимур и Мишель работают в Facebook, где кастомных решений немало. Опираясь на примеры плагинов к Flipper, они расскажут:


  • Когда стоит задуматься о разработке собственных инструментов, а когда этого лучше избегать
  • Как измерить эффективность этого подхода в вашем случае и понять, что игра стоит свеч
  • С чего можно начать

Чем хороши спикеры: Непосредственно причастны к Flipper и кастомным инструментам.


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




Как не написать пиратский корабль вместо фрегата и наоборот, Игорь Кареньков


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


В своём докладе Игорь хотел бы сравнить и оценить эффективность применения самых известных принципов и практик в Android (SOLID, Clean, Modularization, Architecture и т.д.) в зависимости от того, какой проект мы разрабатываем, чтобы каждый мог лучше понимать зачем применяются те или иные инженерные практики, и когда игра стоит свеч.


Чем хорош спикер: Игорь является опытным ведущим Android-инженером продукта Okko, где лично применяет множество инженерных подходов на практике


Чем хороша тема: Выступлений в духе мы затащили себе такую-то штуку множество а вот докладов давайте разберёмся, нужна ли вам такая штука особо не видно.




Kotlin Adoption at Scale, Сергей Рыбалкин, Сергей Рябов


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


Спикеры расскажут, как устроен процесс внедрения Kotlin в Facebook. Вы узнаете, с какими проблемами ребята столкнулись в попытке затащить Kotlin в крупнейшую мобильную кодовую базу: от поддержки языка существующей инфраструктурой до хардкорных оптимизаций JVM-байткода. В докладе присутствует кровавый DEX-код.


Чем хорош спикер: Спикеры напрямую занимаются внедрением Kotlin в крупномасштабном проекте.


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




Напоследок


Напомним, что конференция это не только доклады:


  • Онлайновый Mobius пройдёт на виртуальной площадке: там можно подойти к другому участнику и пообщаться с помощью веб-камер. Так что онлайн не означает совсем без нетворкинга.
  • Общение происходит не только между участниками, но и со спикерами: у каждого доклада есть свой чат, а после завершения доклада можно задать вопросы спикеру в дискуссионной зоне в Zoom.
  • А у компаний-партнёров есть виртуальные стенды, где можно узнать больше о самих компаниях, послушать мини-доклады и поучаствовать в активностях.

Так что ждём вас и на докладах, и на всём остальном. Полная информация и билеты на сайте.

Подробнее..

Делимся докладами-2020 и анонсируем конференции-2021

21.12.2020 14:15:23 | Автор: admin


Недавно мы завершили сезон из восьми конференций для разработчиков от Joker до Mobius. И теперь хотим сделать три вещи:


  • Подвести итоги: рассказать и о победах, и о проколах. В том числе про нашу новую виртуальную площадку
  • Анонсировать конференции 2021-го: JPoint, HolyJS, Heisenbug и другие
  • Поделиться записями 14 отличных свежих докладов



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


Сначала расскажем о том, что затрагивало всех, а затем про игровое.


Классический вид


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



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


Победа: как показывают отзывы, зрители действительно рады воркшопам.


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


Форматы
Помимо воркшопов, были и другие эксперименты с форматами, не подходящими для офлайна. Например, на Mobius одновременно в трёх треках три разных спикера верстали один и тот же экран с помощью трёх разных технологий декларативного UI, а затем вместе сравнивали и обсуждали результаты. Это хорошо работает именно в онлайне, где можно легко переключаться между треками и сравнивать у кого как идут дела, и не требуется перебегать между залами.


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



Стабильность
Самое главное в онлайн-трансляции чтобы она не падала. Так что мы проводили работу над этим.


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


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


Качество
Если со стабильностью всё в порядке и картинка не пропадает, дальше можно думать о том, чтобы она была как можно лучше. Мы ставим себе планкой 4K, и тут кто-то может спросить: зачем онлайн-конференции вообще столько, когда у большинства зрителей даже нет 4K-монитора? Ответ можно найти в старом докладе Одноклассников об их live video: мы сделали поддержку 4K на вырост, потому что если отдебажить для неё плеер и разобраться с производительностью, то 1080p даже на слабых устройствах будет играть прекрасно.


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


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




Игровой вид


Мы уже рассказывали, как весной спешно разрабатывали видеоплатформу для онлайн-конференций за 90 дней. А вот после этого, когда базовая функциональность уже была реализована, задумались как сделать платформу лучше.


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


Идея в следующем: есть 2D-пространство, позволяющее ходить между разными докладами и партнёрскими стендами, как в играх. Там можно общаться: когда подходишь к другому зрителю, под игровым пространством вы видите друг друга с помощью веб-камер. То есть можно разговаривать с теми, кто рядом, как на офлайновых конференциях. И возможно взаимодействовать с различными объектами.



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


Для виртуальной платформы мы не использовали какое-то общедоступное решение, а запилили своё собственное. И Сева vbrekelov Брекелов, участвовавший в работе над ним, рассказал подробнее:


Мы хотели сделать нетворкинг интересным и рассматривали разные варианты и браузерные, и VR. Решили, что 2D-игрушки это интересно, изучили доступные решения, пообщались со Spatial Chat и Gather.town. Но обнаружили, что их не получится интегрировать как следует. Например, возникает сложность с точки зрения авторизации: доступ к самой конференции есть только у зрителей с билетами, и требуется, чтобы доступ на виртуальную площадку тоже был только у них. Со сторонними решениями это сложно или невозможно, и при этом они зачастую ещё и дорогие. И мы поняли, что надо делать что-то своё.



В итоге сделали свою виртуальную площадку с помощью PixiJS. Если коротко, то PixiJS это такой JS-движок для управления Canvas, позволяющий делать всякие штуки с передвижениями. Но надо понимать, что это далеко не Unreal Engine. Это удобная прослойка между Canvas и кодом, но многое надо реализовывать самостоятельно: отображение карты, нескольких людей на ней одновременно, демонстрацию всех перемещений. Поэтому у нас Коля Молчанов делал поверх PixiJS наш игровой движок. А мы с Кириллом Толкачёвым (tolkkv) в это время занимались нашим видеорешением на WebRTC (и поняли, что WebRTC это боль).


Затем я стал имплементировать это видеорешение в игру, и там тоже оказалось много сложностей. Выглядит это просто как несколько маленьких видеоокошек под игровой картой, и кажется, что реализовать это тривиально, но по факту написать там приходится очень много. Например, выбор устройства в Chrome, Firefox и Safari сделан по-разному. Поэтому мы сначала поддерживали только Chrome, но затем занялись и другими браузерами.


А помимо разработческих задач, были и продуктовые. Не было какого-то человека со стороны, который пришёл бы и сказал рисуем всё вот так. Нам самим надо было понять, как всё должно выглядеть, какие нам нужны локации. Обсуждали это с дизайнером, составили ТЗ. Решили в дизайне отталкиваться от атмосферы пиксельных игр что думаете о результате?


Затем был ещё один большой пласт работы. Виртуальная площадка конференции это целый ряд разных локаций. Каждая локация PNG-картинка, которую мы разбиваем на клетки 30x30. И дальше на клетках нужно было вручную указывать, что это за объект: это стена, сквозь неё нельзя пройти, это стенд партнёра, вот здесь будет открываться такая-то ссылка, а это переход на другую локацию с таким-то ID. В общем, перед Joker мы с Колей Молчановым не уходили из офиса: размечали карту, выкатывали последовательно на test/dev/prod, тестировали на каждом шаге.



Наш редактор, где мы размечаем NPC-объекты


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


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


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


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


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


Вот о следующем сезоне давайте и поговорим.




Анонс-2021: новые даты и новые цены


В апреле мы начнём новый конференционный сезон. Что можем о нём сказать?


  • Определились с датами пяти конференций (с другими продолжаем определяться, полный список будет на jugru.org):
    Heisenbug: 6-9 апреля, билеты уже в продаже
    JPoint: 13-16 апреля, билеты уже в продаже
    Mobius: 13-16 апреля
    HolyJS: 20-23 апреля, билеты уже в продаже
    DotNext: 20-23 апреля
  • Этот сезон, как и два предыдущих, пройдёт в онлайне (пандемия не спешит исчезать). Так что поучаствовать снова можно будет из любой точки планеты.
  • И поскольку он пройдёт в онлайне, мы бросим силы на то, чтобы онлайн-платформа с виртуальной площадкой стала богаче возможностями пока не назовём список новых фич, но наверняка станет интереснее.
  • Мы пересмотрели тарифную сетку. Раньше было два варианта билетов: Standard (на одну конференцию) и Full Pass (абонемент на весь сезон). Теперь появляются ещё два: бюджетный Basic (вдвое дешевле Standard, но не даёт доступ к видеозаписям дискуссионным зонам, смотреть доклады можно только в прямом эфире) и Extended (на одну конференцию, но даёт также доступ к видеозаписям остальных). Подробно все варианты можно сравнить на сайте конференции при выборе билета.
  • И, как обычно, цена билетов растёт по мере приближения конференции. Так что самый выгодный момент для приобретения сейчас.
  • Если вы участвовали в наших последних конференциях, то больше информации скоро получите (или уже получили) по почте.



Видеозаписи докладов



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


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


Heisenbug (тестирование)
Тест-кейсы как код (Артем Ерошенко)
Воркшоп: Как начать свой проект автоматизации с нуля с божьей помощью и Selenide (Андрей Солнцев): часть 1 часть 2


Mobius (мобильная разработка)
Jetpack Compose live coding declarative UI Антон Шилов)
gRPC в iOS приложениях. REST in peace? (Светослав Карасев)


DotNext (.NET)
Nullability in C# (Jared Parsons)
Как устроен JIT-компилятор в CoreCLR (Егор Богатов)


Joker (Java)
Заменят ли роботы программистов? (Тагир Валеев)
Spring Patterns для взрослых (Евгений Борисов)


HolyJS (JavaScript)
Воркшоп. Новые приключения во фронтенде, версия 2021 (Виталий Фридман): часть 1, часть 2
Революция в микрофронтендах, module federation, Webpack 5 Павел Черторогов


DevOops (DevOps)
Путь (Microsoft) DevOps (Саша Розенбаум)
Платформенная разработка и топологии команд (Михаил Бижан)


C++ Russia (C++)
Ищем баги в продакшене всем миром: GWP-ASan и что дальше (Константин Серебряный)
Дискуссия: Собеседование С++ (Павел Филонов, Илья Шишков, Роман Русяев)


Увидимся в следующем году на новых конференциях!

Подробнее..

Litho лучшие практики для создания эффективного UI в Android

18.06.2020 22:05:19 | Автор: admin
Litho UI-фреймворк от Facebook, который отвечает за быстрый рендеринг тяжелого UI в топовых приложения с миллиардами загрузок.

Как его использовать, что происходит под капотом, и действительно ли с UI можно работать только из одного потока?


Cookbook по Litho в расшифровке моего доклада с конференции Mobius 2019 Moscow под катом.

С вами Сергей Рябов разработчик из Лондона, который поставил на паузу свой кочевой образ жизни, чтобы проверить, такой ли Альбион туманный, как о нём любят говорить. И я работаю в команде Native UI Frameworks над декларативным фреймворком Litho.

Структура поста:




Что такое Litho?




Litho это UI фреймворк, которому уже четыре года. Два года он разрабатывался внутри компании, затем его вывели в опенсорс, и вот уже два с половиной года он растет и развивается как опенсорсный проект. Изначально Litho разрабатывался для основного приложения Facebook, хотя если взять три самых популярных приложения, которые используют Litho в настоящий момент, то только одно из них будет иметь отношение к Facebook. Остальные же продукты Google.

Когда мы работаем с интерфейсом, у нас есть следующие этапы работы: Inflate, Measure, Layout, Draw. Все эти этапы построения UI должны поместиться в 16 миллисекунд, чтобы приложение не тормозило. Предположим, что у нас тяжелый UI, который не укладывается в 16 миллисекунд: все оптимизации проведены, мы попытались выжать максимум производительности из наших вьюшек, но программа все равно лагает. Можно постараться что-нибудь вынести в фоновый поток, например, Inflate, поскольку это достаточно тяжелая операция. Для этого у нас есть AsyncLayoutInflater, из набора библиотек Android Jetpack.

Заметим, что AsyncLayoutInflater имеет некоторые нюансы: мы не можем создавать вьюшки, которые работают внутри с Handler, нам нужно, чтобы LayoutParams были thread-safe и некоторые другие. Но в целом использовать его можно.

Допустим, в процессе развития приложения на главном экране появляются еще более сложные элементы, и даже оставшиеся три стадии уже не влезают в 16 миллисекунд. В целях оптимизации хочется максимальное количество работы отправить в фоновый поток сразу и Measure, и Layout, поскольку теоретически это в основном математические расчеты, и они сильно отвязаны от Android. Практически же сделать так нельзя, потому что в Android UI-фреймворке Measure и Layout непосредственно реализованы в классе View, поэтому с ними можно работать только в UI-потоке.

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



Litho дает возможность абстрагироваться от View в фазах Measure и Layout благодаря тому, что под капотом для измерений используется движок Yoga, который тоже разрабатывается в команде Native UI Frameworks. И как следствие, это позволяет всю математику вынести в бэкграунд-поток.

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

Декларативный API в Litho


Декларативный подход предполагает, что UI можно представить в виде некоторой функции, которая зависит от набора входных параметров (props) и возвращает некое описание этого UI. При этом функция может быть чистой, не иметь внешних зависимостей, кроме явно указанных параметров, и не создавать сайд-эффектов, что позволит создавать UI даже в фоновом потоке, не боясь за потокобезопасность (thread-safety).



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

fun f(    title: String,    subtitle: String): UI {  return Column.create()    .child(        Text.create()            .text(title))    .child(        Text.create()            .text(subtitle))    .build()}

По входным параметрам мы создаем элементы для title, subtitle и помещаем их в Column, то есть вертикально друг относительно друга.
В Litho эта же функция будет выглядеть следующим образом:

@LayoutSpecobject ListItemSpec {  @OnCreateLayout  fun onCreateLayout(      c: ComponentContext,      @Prop title: String,      @Prop subtitle: String  ): Component {    return Column.create(c)        .child(            Text.create(c)                .text(title))        .child(            Text.create(c)                .text(subtitle))        .build()   }}

Разница в том, что над функцией появляется аннотация @OnCreateLayout, которая сообщает, за что отвечает эта функция. Входящие свойства тоже помечаются специальной аннотацией @Prop, чтобы по ним сгенерировать правильный Builder, для конструирования UI, а также везде прокидывается специальный контекст ComponentContext. И всё это помещается в класс с аннотацией @LayoutSpec, который может содержать и некоторые другие методы.

Этот класс написан на Kotlin, поэтому используется object, но если бы он был на Java, то метод был бы статическим. Это обусловлено вышеупомянутым упором на потокобезопасность. Мы описываем только то, как должен выглядеть UI, а то, что для этого будет происходить под капотом, генерируется фреймворком, на это нельзя повлиять прямым образом, а потому шансы случайно ошибиться, например, плохо обработав локальное состояние (state) UI-компонента, сокращаются.


Комбинирование UI-элементов


У нас уже есть одна функция описывающая простой UI, а как теперь создать на ее основе что-то более сложное? Например, добавить картинку слева от текста, чтобы в итоге получился такой header с данными человека, который написал комментарий: его аватар, имя и дата комментария.



Решение похоже на использование горизонтального LinearLayout, но в данном случае мы горизонтально располагаем картинку и предыдущий UI-компонент ListItem, заворачивая их в Row. Также добавился еще один входной параметр @Prop image, который отвечает за саму картинку, а те параметры, которые отвечают за текстовые данные, просто прокидываются в компонент ListItem.

Стоит отметить, что описываются UI-компоненты в классах с суффиксом Spec, а для создания инстансов этих компонентов используются классы без этого суффикса. Всё потому, что Litho по декларативным Spec-файлам генерирует настоящие реализации компонентов с правильной обработкой многопоточности и удобным API в виде Builder-ов, которые и используются для задания входных параметров, объявленных в UI-спеке.

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



В публичном API Litho есть только одна View LithoView. Это контейнер, в котором идет отрисовка всех Litho-компонентов. Чтобы отобразить на экране заданный компонент, нужно создать ComponentContext, передав ему Android Context, и создать LithoView, передав в метод create контекст и сам отображаемый компонент. С LithoView можно делать всё, что вы привыкли делать с другими вьюшками, например, передать в метод setContentView у Activity.

С API на основе Builder-ов работать легко, механика создания UI-компонента похожа на описание вью в XML. Разница лишь в том, что вместо проставления XML-атрибутов вы вызываете методы Builder-а. Но раз уж это все так сильно отвязано от Android-системы, то что же происходит под капотом?


Litho: под капотом


Возьмем ListItemWithImageSpec, с которым мы уже встречались ранее. В нём три компонента: Row, Image и кастомный ListItem:

@LayoutSpecobject ListItemWithImageSpec {     // ...    Row.create(c)        .child(            Image.create(c)                  .drawable(image))        .child(            ListItem.create(c)                  .title(title)                  .subtitle(subtitle))        .build()  }}

И чтобы отобразить его на экране, добавим его в LithoView таким образом:

setContentView(LithoView.create(c,    ListItemWithImage.create(c)        .image(user.avatar)        .title(user.name)        .subtitle(comment.formatDate())        .build()))

Рендеринг UI-компонента проходит в три основных шага:

  1. Построение Internal Tree внутреннего представления UI.
  2. Получение LayoutState набора Drawable и View, которые будут отрисованы на экране
  3. Отрисовка LayoutState на Canvas-е

Построение Internal Tree


Начинаем с корневого компонента ListItemWithImage:

  • Создаем корневой элемент дерева, InternalNode, ассоциируем с ним компонент ListItemWithImage. Так как ListItemWithImage это фактически просто обертка, то смотрим на его содержимое.
  • Внутри метода onCreateLayout в ListItemWithImageSpec мы первым делом создаем Row. Ассоциируем его с той же самой нодой.
  • У Row 2 потомка: Image и ListItem для обоих создаются отдельные InternalNode-ы. Image это листовой элемент дерева компонентов, на этом обработка его поддерева окончена.
  • ListItem в свою очередь тоже компонент-обертка, чтобы добраться до сути смотрим в метод onCreateLayout его спеки. Там мы видим Column, ассоциируем её с той же нодой.
  • У Column есть 2 потомка: Text и Text создаём для них две новые ноды. Оба элемента листовые построение Internal Tree окончено.

Получилось следующее дерево:



Тут наглядно видно, что в результате ноды создаются только для листовых компонентов, таких как Image и Text, или для компонентов-контейнеров, таких как Row и Column. Так мы упростили иерархию: было три уровня относительно корня, осталось два.

Получение LayoutState


Следующим шагом нам нужно создать LayoutState. Для этого сначала измерим Internal Tree с помощью Yoga. Yoga присвоит координаты х, y, а также ширину и высоту каждому узлу дерева. Затем, с учетом этой полной информации, мы создадим список того, что будет непосредственно отрисовано на экране (уже зная, где оно будет отрисовано и какого размера).

Происходит это следующим образом: мы снова обходим Internal Tree, и смотрим, нужно ли отрисовывать каждую следующую ноду. Row не отрисовывается, он фактически нужен был только для измерения и размещения дочерних элементов. Image отрисовывается, поэтому добавляем его LayoutOutput в список. Column тоже нужен был только для того, чтобы померять и расположить элементы и отрисовывать там нечего, а вот Text-ы, как и Image, тоже важны для отрисовки.

Получившийся в итоге список LayoutOutput-ов это наш LayoutState.

Отрисовка LayoutState


Теперь полученный LayoutState осталось нарисовать на экране. И тут важно подчеркнуть, что в данном примере элементы Image и два Text-a будут отрисованы не с помощью View, а с помощью Drawable. Если мы можем не использовать сложные элементы Android UI Toolkit, если можно обойтись простыми и легковесными примитивами типа Drawable, то эффективнее использовать именно их. Если же какие-то элементы должны уметь реагировать, например, на клики, то они будут отрисованы с помощью View, чтобы переиспользовать всю непростую логику обработки UI-событий.



Шаг отрисовки это единственный этап, который должен выполняться на UI-потоке, все остальные шаги могут быть выполнены в фоне.

На рассмотренном примере мы познакомились с несколькими ключевыми элементами:

  • @LayoutSpec компоненты, комбинирующие другие компоненты. В итоге они превращаются в поддеревья в Internal Tree. Аналог кастомных ViewGroup.
  • Row и Column компоненты-контейнеры, служащие для задания расположения UI-элементов на экране. Это примитивы Flexbox основного Layout Engine в Litho. А Yoga это его кроссплатформенная реализация, которая используется не только в Litho, но также и в других библиотеках под Android, под iOS и в Web.
  • @MountSpec это те самые листовые ноды в Internal Tree Image, Text и другие. Это второй тип Spec, который описывает примитивные элементы, которые будут отрисованы на экране с помощью Drawable или View.

Как будет выглядеть код кастомной @MountSpec-и? Примерно так:

@MountSpecobject GradientSpec {  @OnCreateMountContent  fun onCreateMountContent(context: Context): GradientDrawable {      return GradientDrawable()  }  @OnMount  fun onMount(      c: ComponentContext,      drawable: GradientDrawable,      @Prop @ColorInt colors: IntArray) {      drawable.colors = colors  } }

В данном примере мы берем некоторый массив цветов и отрисовываем созданный на его основе градиент на экране. В андройде для работы с градиентами есть специальный GradientDrawable. Именно его мы и используем для рендеринга этого компонента. Инстанс данного типа нужно вернуть из специального lifecycle-метода, который помечается аннотацией @OnCreateMountContent и отвечает за создание контента для рендеринга.

Напомню, что компонент, описанный как MountSpec, может отрисовывать всего два типа контента: View или Drawable. В данном простом случае нам достаточно легковесного Drawable. Кроме операции создания контента мы также должны определить метод с аннотацией @OnMount для биндинга с данными перед тем, как компонент станет видимым. В нашем случае данными является тот массив цветов, который мы получаем на вход. Всё остальное Litho берет на себя и отрисовывает GradientDrawable c заданными цветами на экран. Для облегчения понимания можно сравнить методы, помеченные @OnCreateMountContent и @OnMount, с методами RecyclerView.Adapter onCreateViewHolder и onBindViewHolder соответственно.


Аннотация @MountSpec


В аннотации @MountSpec есть два параметра:

  1. poolSize параметр, который отвечает за то, сколько инстансов данного компонента будет создано заранее и помещено в пул, чтобы потом быстро использовать их при рендеринге интерфейса. По умолчанию этот параметр равен 3.
  2. isPureRender это булевый флаг, показывающий, что при пересоздании компонента с неизменными значениями Prop-параметров, результат его отрисовки всегда будет оставаться прежним. При обновлении UI-дерева компонентов это позволяет не пересоздавать и не перерисовывать такие чистые компоненты.

Конкретные значения будут зависеть от того, что за компонент вы описываете. Рассмотрим в качестве примера ImageSpec компонент для показа картинки:

@MountSpec (poolSize = 30, isPureRender = true)class ImageSpec {  @ShouldUpdate  static boolean shouldUpdate(...) {}}public @interface MountSpec {  int poolSize() default 3;  boolean isPureRender() default false;}

У него очень большой poolSize (30). Cегодня типичная ситуация, когда приложение нагружено картинками, поэтому UI-компоненты для них лучше подготовить заранее в достаточном количестве. В то же время, если входной параметр Drawable, не меняется, то и вывод на экран такого компоненты тоже не поменяется, и, чтобы не делать лишних действий, можно установить флаг isPureRender В этом случае решение об обновлении компонента принимается на основании сравнения Prop-параметров с помощью equals(), если же вы хотите использовать кастомную логику сравнения, то её нужно поместить в функцию с аннотацией @ShouldUpdate.


Оптимизации в Litho


В Litho есть две ключевые оптимизации при построении Layout:

  1. Layout/Mount Diffing позволяет переиспользовать размеры (measurements) элементов с предыдущего рендеринга и переиспользовать LayoutOutput-ы (то, что выводится на экран) с предыдущего рендеринга.
  2. IncrementalMount позволяет превратить ваш UI в RecyclerView на стероидах без каких-либо дополнительных усилий.

Layout/Mount Diffing


Как это работает? При построении Internal Tree для нового компонента, также учитывается оставшееся с предыдущего рендеринга Diff Tree с готовыми размерами и LayoutOutput-ами всех узлов дерева.



Если входящие параметры для некоторого поддерева не изменились, то размеры и LayoutOutput для него просто копируются из Diff Tree в новый Internal Tree, минуя шаг измерения с помощью Yoga. Таким образом, LayoutState готов уже к концу построения Internal Tree.

IncrementalMount


Допустим, у вас есть своя социальная сеть с новостной лентой со сложными UI-элементами, например, постами с большим количеством, деталей. Не хотелось бы, чтобы при прокрутке экрана mount и отрисовка выполнялись для всего тяжелого UI поста, сразу как только первый пиксель покажется из-за края экрана. Если mount такого сложного элемента не уложится в 16мс, то мы будем видеть дерганый UI, особенно при быстрой прокрутке.
mount
Mount процесс получения контента для рендеринга (View или Drawable) и его добавление в текущую иерархию View

IncrementalMount в этом случае позволяет рендерить новостной пост не целиком, а постепенно, выполняя mount только для тех дочерних примитивных элементов, которые действительно попадают в видимую область экрана. А для тех же элементов, которые покидают её, выполнять unmount и возвращать их в пул, не дожидаясь, пока весь пост скроется за краем экрана, таким образом экономя память. Скролл существенно ускоряется за счёт того, что отрисовка тяжёлого поста разбивается на несколько фреймов. Всё это напоминает работу RecyclerView, но в Litho вам не надо как-то по-особому менять UI или использовать другие компоненты это работает из коробки.

Выводы на заметку:


Если вы определяете кастомную MountSpec-у, то:

  • можно использовать параметр isPureRender и метод @ShouldUpdate, чтобы не делать лишнюю работу при обновлении UI компонента.
  • зная, в каком объёме компонент будет использован в приложении, вы можете подготовить нужное количество инстансов заранее, настроив размер пула с помощью poolSize.


Управление Состоянием


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

Рассмотрим простой пример компонент со счётчиком и кнопкой для его увеличения:



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

Затем нам нужен метод для изменения стейта. Он помечается аннотацией @OnUpdateState и на вход принимает все тот же самый стейт, но не в виде неизменяемого значения, а завернутый в холдер StateValue, в котором стейт реально можно поменять.

Наконец, нам надо связать все это с нажатием на кнопку. Для этого есть event-хендлеры: метод с аннотацией @OnEvent определяет обработчик событий определённого типа (в данном случае, кликов), и в нём вызывается сгенерированный метод для изменения стейта увеличения счётчика.



В данном примере видно, что наборы параметров в описании метода и в месте его вызова не совпадают. Это происходит, потому что вы вызываете метод, определенный в Spec-классе не руками, а неявно, через сгенерированный метод в сгенерированном Component-классе, и все значения, необходимые для Spec-метода (в данном случае, StateValue), Litho подставит сам.

Каждое обновление стейта вызывает тот же эффект, что и передача новых значений Prop-параметров: снова нужно построить Internal Tree, получить LayoutState и отрисовать его на экран.

А что если у нас есть пара переменных для состояния и разные для них методы обновления? Допустим, у нас есть профиль супергероя, в котором нам надо поменять цвет и имя. Мы хотим сменить зеленого Халка на красного Железного Человека. У нас есть две переменные состояния color и name, и мы делаем два обновления путем присвоения переменных.

@OnUpdateStatefun changeColor(color: StateValue<Color>, @Param newColor: Color) {  color.set(newColor)}@OnUpdateStatefun changeName(name: StateValue<String>, @Param newName: String) {  name.set(newName)}...RootComponent.changeColor(c, Color.RED)RootComponent.changeName(c, "IronMan")

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

красного Халка не существует!
Поймали пасхалку? С меня стикер ;)



Отсюда Best Practice: важно помнить про группировку State-апдейтов. Если у вас есть несколько State-переменных, которые вы обычно меняете отдельно в разных методах, но есть ситуации, когда необходимо поменять их вместе, то стоить завести отдельный метод для их модификации целой группой (или несколько методов для разных комбинаций переменных).

@OnUpdateStatefun changeHero(    color: StateValue<Color>, name: StateValue<String>,    @Param newColor: Color, @Param newName: String) {  color.set(newColor)  name.set(newName)}...RootComponent.changeHero(c, Color.RED, "IronMan")

При профилировании такого метода мы увидим, что остался лишь один блок, который обновляет UI-дерево. Можно провести аналогию с транзакциями: один метод с @UpdateState одна транзакция по изменению UI.

Отложенное обновление состояния


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



Для шага заведем отдельный State-параметр step, в котором будем хранить текущее значение, и сделаем возможность вводить его с клавиатуры в поле TextInput. Так как при изменении этого значения в поле ввода новое число мы увидим сразу, то обновлять UI с новым значением step не надо, но запомнить его необходимо. Для этого надо выставить флаг canUpdateLazily, давая Litho понять, что этот State можно изменять без перестроения UI, лениво. В этом случае, помимо всех явно определенных @UpdateState методов, которые отвечают за обычные обновления состояния, сгенерируется ещё один метод lazyUpdateStep, выполняющий как раз такое ленивое обновление step. Префикс lazyUpdate общий для всех таких методов, а суффикс (Step) однозначно соответствует имени State-переменной.

@State(canUpdateLazily = true) step: IntRootComponent.lazyUpdateStep(c, value)

Выводы на заметку



  • не забывайте группировать стейт апдейты, когда вы знаете, какие наборы State-переменных будут меняться вместе.
  • используйте Lazy State-апдейты для State-переменных, которые не влияют на отображение UI.


Анимация в Litho


Давайте теперь перейдем от статического отображения UI к динамическому как в декларативном API Litho будет выглядеть описание анимации?



Рассмотрим простой пример (видео доклада 28:33-28:44) с кнопкой, которая меняет своё расположение при клике. Она прижимается то к правому, то к левому краю, но происходит это моментально, скачкообразно в этом случае пользователю не очевидно, что произошло.

Однако мы можем это исправить, добавить контекста и анимировать кнопку. Для этого надо сделать две вещи: надо пометить то, ЧТО мы анимируем, и описать, КАК надо анимировать. Мы двигаем кнопку, поэтому задаем ей свойство transitionKey.

Button.create(c)    .text(Catch me!)    .transitionKey(button)    .alignSelf(align)    .clickHandler(RootComponent.onClick(c))

Затем реализуем метод с аннотацией @OnCreateTransition, который создаёт описание анимации изменений между двумя отрисовками этого компонента, Transition между предыдущим и следующим состоянием UI. В данном случае Transition простой: мы создаём его с тем же transitionKey, которым пометили цель анимации (в данном случае, кнопку), и просим проанимировать только изменения горизонтальной координаты цели координаты X кнопки. В результате оно действительно анимируется (видео доклада 29:25-29.33).

@OnCreateTransitionfun onCreateTransition(c: ComponentContext): Transition {  return Transition.create("button")      .animate(AnimatedProperties.X)}

Такое описание анимации отлично, если вы четко знаете, что нужно анимировать и хотите полного контроля над тем, как это анимировать, но может стать многословным в сложных компонентах. Если же вы хотите проанимировать любые изменения в layout-е и сделать это автоматически, то в Litho есть специальный Transition.allLayout() для этих целей. Это нечто похожее на установку animateLayoutChanges = true для анимации всех изменений в нативной ViewGroup.

@OnCreateTransitionfun onCreateTransition(c: ComponentContext): Transition {  return Transition.allLayout()}

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

Чтобы самим определять, надо или нет анимировать конкретное изменение компонента, можно использовать Diff для Prop и State-параметров.

Diff это такой холдер, который содержит одновременно и текущее, и предыдущее значение для конкретного Prop/State, давая возможность их сравнить произвольным методом и сделать вывод, стоит анимировать или нет.



И если вернуть null из @OnCreateTransition, то анимироваться ничего не будет. Более того, будет пропущен весть этап подготовки анимации, что положительно скажется на производительности.

Обратите внимание, что и аннотации, и имена соответствующих Prop/State остаются такими же, как в @OnCreateLayout, меняется лишь тип с T на Diff<T>.

Выводы на заметку


Используйте Diff параметры для более тонкой настройки анимации изменения значений Prop и State.


Пошаговое внедрение


Вряд ли в существующем проекте кто-то решится в одночасье переписать весь UI на Litho. Поэтому возникаю логичные вопросы: можно ли осуществлять внедрение по частям? Могут ли Litho-компоненты жить бок о бок с нативным Android UI? И тут у меня для вас хорошие новости!

Да, ваш сложный UI можно портировать на Litho по частям:

  • С одной стороны можно использовать Litho-компоненты внутри существующего UI на View. Можно последовательно заменять сложные UI-поддеревья в вашей разметке на LithoView с аналогичной иерархией компонентов. Таким образом вы упростите изначальный UI и уменьшите глубину дерева элементов.
  • С другой стороны можно использовать кастомные View сложные графики, анимированные круговые диаграммы, видео-плееры, которые нелегко переписать на компоненты, в Litho-интерфейсах. Для этого View нужно обернуть в MountSpec-у (помните, что метод с @OnCreateMountContent может возвращать не только Drawable, но и View?), которую потом легко можно будет включать в иерархию компонентов.


Дебаггинг и тулы в Litho


А что же нам делать, если вдруг что-то не будет работать? Если будут вопросы, то где смотреть примеры? Как отладить интерфейс на Litho? Как быстро верстать и тюнить UI? Обо всём этом ниже.

Yoga playground


Litho использует концепцию и терминологию Flexbox для задания расположения элементов. Если вы с ней не знакомы, то для вас есть Yoga Playground. Это интерактивная песочница, где на схематичном представлении UI с виде прямоугольников можно поиграться с параметрами, подготовить макет вашего UI и даже экспортировать его в виде Litho-кода на Java.

Flipper + Litho plugins


Для Litho, к сожалению, нет поддержки в UI Preview. Стандартный Layout Inspector тоже не сможет показать иерархию компонентов Litho. Всё потому, что эти инструменты работают только с Android View. Но к счастью коллеги из команды UI Tools разрабатывают замечательный инструмент для разносторонней отладки мобильных приложений Flipper. Layout-плагин для Flipper умеет отображать иерархию UI-элементов интерфейса, который отображается на экране телефона, и распознаёт не только обычные View, но и компоненты Litho. Кроме того, при выделении какого-либо компонента, в боковой панели можно увидеть список свойств Props компонента, большую часть из которых можно менять в реальном времени и проверять изменения на устройстве. Это сильно упрощает финальную подстройку UI, во многом заменяя UI Preview.



Для демонстрации работы плагина взгляните на демку из доклада. Справа сэмпл приложение с простым списком, а слева Flipper.

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



На данном скриншоте видны изменения UI-элементов и данные, которые этим элементам отвечают. Таким образом легко отладить различные проблемы со списками: поймать излишние обновления UI, проверить, какие элементы были удалены, переиспользованы или добавлены, понять, в чём причина неверного UI в некорректных данных или в ошибках в самих UI-компонентах.

Litho IntelliJ plugin


В Litho сильно отличающийся от стандартного подход к написанию UI, свои аннотации и lifecycle-методы много нового. Есть, конечно, документация, но чтобы при написании каждой новой Spec-и не обращаться к ней для уточнения любых вопросов, а стартовать быстро, наша команда также предоставляет IntelliJ / Android Studio плагин. Он добавляет шаблоны для создания LayoutSpec и MountSpec, шаблоны для генерации отдельных lifecycle-методов, а также возможность навигации между Spec-классом и сгенерированным по нему классом компонента.



Плагин можно установить через IntelliJ Plugin Marketplace.

Lithography Sample app


Ну а кроме всего вышеназванного, конечно же в репозитории есть sample-приложение Lithography. В нём можно посмотреть рецепты по реализации каких-то реальных примеров: создать UI карточки, загрузить картинку из интернета, реализовать Fast Scroll. Есть целые секции по работе со списками, различным способам анимации и так далее.

Один из интересных примеров Error Boundaries. Это техника, с помощью которой можно на ходу подменять компоненты, которые крэшатся при рендеринге на произвольный компонент. Например, вместо того, чтобы крэшить всё приложение как происходит обычно, вы можете показать ошибку прямо в UI на месте неисправного компонента. Подробнее о возможностях в документации.


Резюме


Ключевые достоинства Litho в том, что обработку UI можно частично проводить на фоновом-потоке, его декларативный API позволяет проще описывать все возможные состояния UI, а при рендеринге получаются более плоские иерархии View. Несмотря на то, что мы все оборачиваем в Row, Column и прочие компоненты, на самом деле рисоваться будут только листовые элементы дерева и каждый пиксель как правило будет рисоваться по одному разу. Incremental Mount предоставляет возможность более гранулярного переиспользования отдельных атомарных MountSpec, а не только целых LayoutSpec компонентов элементов списка.


Бонус: Litho и Kotlin


С учётом завязки Litho на процессинг аннотаций и кодогенерацию, использование его с Kotlin может дать некоторое замедление сборки, так как KAPT печально известен своей неторопливостью. Ну и чего скрывать, для такого модного молодежного языка, как Kotlin, обилие аннотаций в API не выглядит очень удобно, когда везде правят разнообразные DSL-и. А хотелось бы вот как-то так просто создать UI в одной функции, да может даже прямо в Activity, и там же его в Activity и отрендерить, без плясок с LithoView:

class PlaygroundActivity : Activity() {  override fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    setContent {      val counter by useState { 1 }      Clickable(onClick = { updateState { counter.value = counter.value + 1 } }) {        Padding(all = 16.dp) {          Column {            +Text(text = "Hello, Kotlin World!", textSize = 20.sp)            +Text(                text = "with ${"".repeat(counter.value)} from London",                textStyle = Typeface.ITALIC)          }           }      }    }  }}

Так вот всё это реальный код! Пока что Kotlin API находится в активной разработке, но экспериментировать с ним можно уже сейчас Kotlin-артефакты выкладываются с каждым релизом Litho, а кроме того доступны их Snapshot-версии. Также, вы можете следить за развитием проекта на Github-е.

Настоятельно рекомендую ознакомиться с материалами по ссылкам:


Уже на следующей неделе состоится Mobius 2020 Piter. Там для Android-разработчиков тоже будет много интересного: например, выступит хорошо знакомый им Chet Haase из Google. Многие помнят его по выступлениям на Google I/O, а в этом году I/O отменили, но благодаря Mobius есть шанс всё равно увидеть Чета и даже лично задать ему вопрос.
Подробнее..

Программа Mobius от кроссплатформы до супераппов

20.10.2020 12:19:01 | Автор: admin


О чём расскажут мобильным разработчикам на ближайшей конференции? Общая идея Mobius неизменна: будут доклады и для Android-разработчиков, и для iOS, и общие для обеих сторон сразу.


Но есть по сравнению с прошлыми Mobius и небольшие изменения: например, помимо докладов, будут два воркшопа. А кроссплатформенные Flutter и Kotlin Multiplatform перешли из стадии любопытно в стадию используется в продакшне так что будет несколько выступлений для тех, кто готов применять их в бою.


А какими будут конкретные темы докладов и воркшопов? Об этом под катом.


Оглавление



Android + iOS


Какие доклады будет полезно послушать, для какой бы платформы вы ни разрабатывали?


Влияем на тестовое окружение "без рук"


Екатерина Батеева (Тинькофф) и Алексей Рассказов (HUMANS)


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


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




Как создавали суперапп Яндекса


Артур Василов и Илья Богин (Яндекс)


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




Flutter


Поскольку это кроссплатформенная технология, доклады о ней подходят категории Android + iOS. Но эта птичка так расправила крылья, что в этот раз о ней будут целых три выступления в разных форматах, и можно выделить их в отдельный блок.


Воркшоп: Flutter Zero LiveShow


Александр Денисов (EPAM)


Онлайн-конференциям хорошо подходит формат покодить в прямом эфире: когда смотришь стрим за компьютером, удобно видеть там происходящее на чьём-то чужом компьютере. И здесь писать приложение на Flutter будет Flutter-энтузиаст Александр Денисов. А помогать ему будут Евгений Ртищев и Михаил Емельянов: известные профессионалы в области мобильной разработки, но новички во Flutter.


Всё будет в прямом эфире, включая советы аудитории, споры, тупики, ошибки в рантайме, гугление (если вдруг понадобится) и конечно, ответы на ваши вопросы. Посмотрим вместе, что получится.




Прожаренная птичка: Готовим Flutter к промышленному использованию


Владимир Иванов (EPAM)


Как и у любой молодой технологии, у Flutter хватает проблемных мест. Этим летом Владимир Иванов написал статью 10 вещей, которые не так с Flutter. Статья интересная, но встаёт вопрос: окей, проблемы поняли, а что с ними теперь делать-то?


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




Flutter под капотом


Михаил Зотьев (Surf)


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


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




Android


Абсолютная модуляризация


Степан Гончаров (Lyft)


Степан Гончаров ранее уже рассказывал на Mobius о Gradle, но в этот раз заходит дальше. Организация многомодульного проекта с Gradle вечно связана со сложностями и теперь Степан представит свой собственный вариант борьбы с этими сложностями, призванный упростить жизнь и сэкономить время разработчикам.


Многие уже знают Степана по его докладам, но для тех, кто слышит имя впервые: он разрабатывает под Android c 2008 года, успел побывать в самых разных ролях. Сейчас время работает в Grab, является лидером Kotlin Singapore User Group, активно использует Rx и все больше времени посвящает OSS.




Увлекательная жизнь в панели уведомлений


Кирилл Розов (Replika.ai)


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


Как использовать все возможности системы уведомлений по максимуму? Как сделать уведомления на каждой версии ОС? NotificationCompat не решит все за вас. Давайте разбираться вместе с Кириллом Розовым, на чей телеграм-канал [Android Broadcast|https://t.me/android_broadcast] подписаны тысячи Android-разработчиков.




Воркшоп: Поплагиним ещё


Павел Стрельченко (HeadHunter)


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


Плагины для IntelliJ IDEA как лох-несское чудовище: все слышали про него, но никто не видел. Так же и разработка плагинов многие слышали, что это возможно, но мало кто видел процесс создания от и до.


Павел хочет показать вам как можно, потратив пару часов, написать полезный для команды плагин для создания Page Object-ов из XML-файла. Это достаточно объёмная задача, которая позволит показать все этапы разработки плагина: от настройки плагина до реализации логики, UI, использования других плагинов и генерации кода.




Выходим на рынок Huawei, Или как мы адаптировали приложение для работы с HMS


Павел Борзиков и Георгий Гигаури (Mail.ru Group)


Huawei запустил собственный магазин приложений и убрал с новых устройств поддержку Google-сервисов. Есть причины адаптировать своё приложение под их платформу, и Павел и Георгий расскажут, с какими проблемами столкнулись на этом пути и как формировали фронт работ.


В первую очередь, рассмотрим работу с картами (какую альтернативу выбрать Google Maps и как работать сразу с двумя картами в приложении). Затронем работу с push-уведомлениями. Посмотрим, какие еще сервисы Huawei решили использовать и как их тестировать. В конце опыт публикации приложения в Huawei AppGallery, из чего состояла подготовка и каковы первые впечатления от проделанной работы.




Jetpack Compose для консистентности UI ваших приложений


Антон Шилов


Jetpack Compose (декларативный UI-фреймворк, призванный ускорить разработку приложений) для многих перешёл из стадии когда-то станет актуальным, но до этого ещё дожить надо в стадию пора разбираться. В докладе Антон расскажет, как шаг за шагом интегрировать фреймворк в текущий код, сохранив консистентность UI, и добиться максимального переиспользования компонентов.


Также вы услышите:


  • какие стратегии миграции сработали;
  • как создать кастомную дизайн-систему, а не только настраивать MaterialTheme;
  • с какими проблемами столкнулись при миграции и как их решили.

Badass data source: Offline-mode в несколько строк кода


Алексей Быков (Revolut)


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


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




Круглый стол. Модуляризация 2021


Михаил Емельянов (ЦФТ) и все-все-все


О мультимодульных Android-приложениях на Mobius говорилось не раз, но тема не теряет актуальности: проекты растут, практики меняются, опыт накапливается. И чтобы разобраться, как сейчас правильнее делать мультимодульные проекты, мы собрали мультиэкспертную дискуссию! На круглом столе к Михаилу Емельянову присоединится целый ряд экспертов, ранее уже освещавших эту тему:
Евгений Мацюк
Сергей Боиштян
Степан Гончаров
Олег Годовых




Переезд платежного терминала с Linux на Android


Платон Малюгин (Dejavoo Systems)


Сейчас ещё нет полного описания доклада, оно позже появится на сайте. А пока сообщим, что Платон работает Android-лидом в Dejavoo Systems Russia. Основные направления: платежные решения для платежных касс и платежные терминалы. В свободное время любит порыться в исходном коде AOSP. Миграция с Linux на Android для Платона стала главным вызовом, пришлось доказать, что это работающая идея. Пришлось достать книгу по С и C++, но одного кода недостаточно, так как нужно понимать платежную индустрию и ее функционирование.




iOS


iOS background modes. Применяем и укрощаем на практике


Анна Жаркова (Usetech)


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


В своем докладе Анна хочет осветить основные сложные кейсы работы с Background Modes. Показать, как без запрещенных приемов обойти ограничения iOS. Рассмотрим такие ситуации:
поддержка периодической работы приложения;
опрос сенсоров и датчиков устройства в фоновом режиме (в т.ч BLE и GPS);
продление работы в фоне и синхронизация по своим правилам.


Также посмотрим, помогут ли новые решения из iOS 13 и iOS 14.




Kotlin Multiplatform в мобильных Яндекс.Картах с позиции iOS-разработчика


Михаил Куренков (Яндекс.Карты)


Про Kotlin Multiplaform по понятным причинам чаще говорят Android-разработчики. Но вот здесь можно будет услышать выступление с iOS-стороны, основанное на реальном опыте популярного приложения.


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


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




WebSocket: Как, когда и сколько стоит


Александр Лавриненко (ManyChat)


Мы все хорошо владеем HTTP и часто шлем REST-посылки на сервер. Но приложения становятся все динамичнее и вот уже сервер хочет отправлять нам информацию о новых событиях. И тут, кажется, пора переключатся на WebSocket.


Мы рассмотрим, что такое WebSocket и как он работает. Чем лучше или хуже HTTP и когда можно обойтись без long polling. Какие библиотеки есть. Обсудим, что нужно будет дописать ручками, а о чем стоит не забыть договориться с бэкендом. Рассмотрим классическую реализацию и реализацию через Centrifuge. И под конец попробуем померить насколько дорого для приложения будет работа с активным сокетом.




Трудности разработки клиента для облачного хранилища под iOS


Игорь Веденеев (AGIMA)


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


Среди задач:


ускорение формирования ленты фотографий при большом объёме данных
обработка изменений ленты из нескольких источников данных
извлечение метаданных из фото на разных версиях ОС
организация очередей загрузки фото/файлов




Внедрение SPM тернистый путь


Вадим Белотицкий (Яндекс)


Доклад будет интересен iOS-разработчикам, которые хотят внедрить технологию SPM (Swift Package Manager) в существующий проект. В докладе будут рассмотрены причины, по которым команда решила внедрять SPM, прикладные вопросы и проблемы, которые приходилось решать в процессе внедрения.


В докладе будут представлены варианты решения различных проблем, которые могут возникнуть при внедрении SPM в существующий проект: проблемы с компиляцией; сочетание Swift и Objective-C кода; падения, связанные с некорректной линковкой проекта; сочетание двух менеджеров зависимостей Cocoapods и SPM; проблемы сборки на CI (Teamcity). Сам процесс внедрения будет рассмотрен поэтапно, от примеров Apple и тестовых, к первым шагам по внедрению (созданию первого модуля с генерацией проекта) до текущего состояния проекта.




Легаси: Переписать нельзя поддерживать


Сергей Митрофанов (SweatCo Ltd), Владимир Шутов (65apps)


Легаси не имеет единого академического определения, но неизменным остаётся одно оно есть, и оно отнимает ресурсы разработки. Тут нет серебряной пули, панацеи которая решает проблему легаси. Обычно эту проблему решают опыт и везение. Опыт неудач, который подсказывает, как делать нельзя. И везение в виде случайных удачных решений.


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




gRPC в iOS приложениях. REST in peace?


Светослав Карасев (Метр квадратный)


Почему REST это не всегда хорошо? Зачем нашим предкам был нужен SOAP? Правда ли, что GraphQL только для JS-разработчиков? Что лучше: JSON-RPC, Thrift или gRPC? Правда ли, что protobuf продлевает жизнь IT-проекту? Об этом всем и многом другом поговорим в этом докладе.




А что ещё?


Помимо Mobius-докладов, есть ещё вот какая история. Мы проводим в этом сезоне целых 8 онлайн-конференций по разным темам, от тестирования до DevOps. И заметили, что многим зрителям интересны доклады с соседних конференций: Я Android-разработчик, а не тестировщик, но доклад об автоматизации мобильных приложений с Heisenbug послушал бы.


Поэтому мы придумали Full Pass: билет-абонемент, дающий доступ ко всем 8 конференциям сразу. Конечно, вы не станете смотреть все восемь от и до, но посмотреть Mobius активно, а у других подключаться на отдельные доклады вполне рабочий вариант.


Если для вас это звучит интересно, то актуальна ссылка на весь сезон. А если интересен только Mobius, тогда подойдёт ссылка на его сайт: там и расписание, и вся остальная информация, и билеты.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru