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

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

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

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

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

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

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

Ладно, человеческий фактор. Но были и чисто технические штуки, которые окончательно убедили меня, что кроссплатформа тут бессмысленна.

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

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

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

Для российских разработчиков это особенно близкая история: Kotlin создавался в JetBrains, компании, основанной выпускниками Санкт-Петербургского политехнического университета. Язык, названный в честь острова в Балтийском море, стал одним из самых заметных российских технологических экспортов последнего десятилетия.

15 лет Kotlin. Первый анонс состоялся в июле 2011 года, стабильная 1.0 — в феврале 2016-го.

Kotlin 2.4.0. Стабильные context parameters, explicit backing fields, поддержка Java 26, Swift packages в Kotlin/Native и совместимость с Gradle 9.5.0.

Kotlin Toolchain 0.11. Amper эволюционировал в единый инструментарий: одна команда kotlin для создания, сборки, тестирования и публикации проектов.

Koog 1.0. JetBrains выпустила стабильный фреймворк для AI-агентов на Kotlin и Java с годовой гарантией совместимости ядра.

Compose Multiplatform 1.12.0-beta01 и Compose Hot Reload 1.2.0-beta01 развивают shared UI и экспериментальный MCP-сервер для AI-агентов.

Гранты Kotlin Foundation 2026. Приём заявок на финансирование open-source библиотек и инструментов открыт до 14 июля 2026 года.

Пятнадцать лет: от внутреннего проекта до мейнстрима

История Kotlin началась в 2010 году как попытка JetBrains решить собственные проблемы с Java. В 2011-м язык впервые показали публике, а в феврале 2016 года вышла стабильная версия 1.0. Переломным моментом стал Google I/O 2017: Kotlin получил статус первоклассного языка для Android, после чего интерес к нему резко вырос.

Сегодня Kotlin используется не только в мобильной разработке. На нём пишут backend на Spring и Ktor, делают кроссплатформенные приложения через Kotlin Multiplatform, экспериментируют с Kotlin/Wasm и даже строят AI-агентов. По данным ежегодных опросов JetBrains, доля Kotlin в коммерческих проектах стабильно растёт как в Европе, так и в России, несмотря на санкционные ограничения в части корпоративных лицензий.

If I were to choose one word to describe Kotlin's design, it would be pragmatism. For us it means caring about the usefulness.

Kotlin 2.4.0: что вошло в релиз

3 июня 2026 года JetBrains выпустила стабильный Kotlin 2.4.0. Это не инкрементальный патч, а полноценная мажорная версия с изменениями в языке, стандартной библиотеке, компиляторе и всех целевых платформах.

• Язык. Стабилизированы context parameters и explicit backing fields, добавлены новые target'ы для аннотаций.
• Стандартная библиотека. UUID API вышел из экспериментального статуса, появились функции для проверки отсортированности коллекций.
• Kotlin/JVM. Поддержка Java 26 и аннотации в метаданных включены по умолчанию.
• Kotlin/Native. Swift packages можно использовать как зависимости, обновлён Swift export, по умолчанию включён CMS GC.
• Kotlin/Wasm. Инкрементальная компиляция по умолчанию и поддержка WebAssembly Component Model.
• Kotlin/JS. Экспорт value-класс и возможности ES2015 при инлайнинге JS-кода.
• Gradle. Совместимость с Gradle 9.5.0.
• Maven. Автоматическое выравнивание версий Java и JVM target.
• Компилятор. Более предсказуемое поведение inline-функций при компиляции .klib.

Для практики это означает: если ваш проект живёт на JVM, можно обновляться ради Java 26 и улучшений stdlib; если вы работаете с iOS через Kotlin/Native — стоит посмотреть на Swift packages; для WebAssembly-экспериментов 2.4.0 делает сборку заметно быстрее.

Как обновиться

Обновление до 2.4.0 проходит через указание версии в Gradle или Maven. В Android Studio и IntelliJ IDEA новая версия уже включена в последние сборки.

Kotlin Toolchain 0.11: Amper уходит в прошлое

В июне 2026 года JetBrains окончательно переименовала Amper в Kotlin Toolchain и выпустила версию 0.11. Это не просто ребрендинг: инструмент позиционируется как единая точка входа для работы с Kotlin-проектами. Одной командой kotlin можно создать, собрать, протестировать и опубликовать проект.

В 0.11 появилась возможность публиковать JVM-библиотеки, улучшена разработка плагинов и упрощена начальная настройка. Для российских команд, часть которых уходит от корпоративных Gradle-лицензий к open-source инструментам, Kotlin Toolchain может стать интересной альтернативой для новых проектов и прототипов.

Важно: Kotlin Toolchain пока в статусе Alpha. Для существующих Gradle-проектов массово мигрировать смысла нет — инструмент ещё не покрывает все сценарии зрелых сборок. Но пробовать на небольших сервисах и pet-проектах уже можно.

Koog 1.0: AI-агенты на Kotlin

Фреймворк Koog от JetBrains вышел в версии 1.0. Он предоставляет примитивы для построения агентных приложений: инструменты, workflow, персистентность, память, observability и интеграции с JVM/KMP-проектами. Главное для Java-команд: Koog теперь предлагает идиоматичный Java API, то есть переходить на Kotlin ради агентов не обязательно.

Koog интегрируется со Spring AI, что делает его естественным выбором для backend-разработчиков, которые уже используют Spring Boot. Появилась мультиплатформенная observability и годовая гарантия совместимости ядра — это важно для команд, которые рассматривают агентов не как прототип, а как часть продакшена.

Compose и инструменты UI

Для UI-разработчиков в выпуске два значимых обновления. Compose Multiplatform 1.12.0-beta01 продолжает развивать shared UI: новые графические возможности, улучшения accessibility на iOS, обновления поведения UI-тестов и исправления для десктопа, веба и Gradle-плагина.

Отдельно стоит Compose Hot Reload 1.2.0-beta01. В нём развивается экспериментальный MCP-сервер: AI-агенты получают доступ к логам, ошибкам UI, могут перезапускать приложение и управлять его жизненным циклом. Это ещё не production-ready, но демонстрирует направление: разработка интерфейсов становится более визуальной и интерактивной.

Экосистема: библиотеки, гранты и корпоративный опыт

В обзоре JetBrains упомянуты три KMP-библиотеки, которые стоит изучить: ComposeMediaPlayer для кроссплатформенного видео, NSExceptionKt для улучшенной обработки крэшей на Apple-платформах и multiplatform-settings для хранения key-value данных в shared-коде.

Кроме того, Kotlin Foundation открыл грантовую программу 2026. Финансирование могут получить open-source проекты вокруг Kotlin Multiplatform, AI и больших языковых моделей. Заявки принимаются до 14 июля 2026 года. Для российских авторов библиотек это реальный способ поддержать проект, особенно если он пользуется спросом у зарубежного комьюнити.

Ещё один сигнал зрелости экосистемы — история Booking.com. Компания внедрила Kotlin Multiplatform для экспериментальной библиотеки и получила результаты выше ожиданий: улучшилась консистентность между Android и iOS, при этом команды не отказывались от платформенно-специфичной разработки.

Обучение: бесплатные курсы на Hyperskill

К юбилею JetBrains сделала часть Kotlin-курсов на Hyperskill бесплатными. Это проектно-ориентированная платформа: можно укрепить основы или пойти в сторону мобильной и backend-разработки. Для тех, кто только начинает или переходит с Java, это удобный способ получить практику, а не только теорию.

Выводы

15 лет Kotlin — это не только юбилей, но и точка, где язык перешёл из фазы «быстрого роста» в фазу «экосистемного инструмента». Kotlin 2.4.0 делает язык зрелее на всех платформах, Kotlin Toolchain упрощает вход в экосистему, а Koog и Compose Hot Reload показывают, что Kotlin активно используется в новой волне AI-разработки.

Для работающих проектов самый безопасный шаг — обновиться до Kotlin 2.4.0 в тестовом окружении и проверить совместимость. Новые инструменты вроде Toolchain и Koog стоит пробовать на pet-проектах, прежде чем тащить в продакшен. А если у вас есть open-source библиотека вокруг Kotlin — грантовая программа Kotlin Foundation может стать хорошим подспорьем.

Источник: Kodee's Kotlin Roundup: Kotlin Turns 15, Kotlin 2.4.0, and the Kotlin Toolchain — блог JetBrains.

Инструмент как часть личности

Возьмем типичную ситуацию: переход на новый стек или поддержка старой базы. Допустим, команда третью неделю (а иногда и третий месяц!) обсуждает, оставить Scala или перейти на Kotlin. Аргументы обеих сторон озвучиваются на первой же встрече, а затем просто повторяются от созвона к созвону. Кто-то говорит об экосистеме, кто-то — о кривой обучения. Внешне это выглядит как техническая дискуссия, но решение не принимается.

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

Программист, который пять лет пишет на Scala, не просто использует инструмент. Язык стал частью его мышления: как он декомпозирует задачи и выстраивает архитектуру. И когда кто-то предлагает перейти на Kotlin, человек слышит: «То, что ты умеешь, больше не нужно». Отсюда и высокий градус эмоций. Годы практики делают стек частью профессиональной идентичности. Оспорить выбор инструмента — значит задеть человека лично.

Ловушка единомышленников

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

Однако со временем команда перестает замечать собственные слепые пятна. Любой «человек со стороны» с его новым взглядом воспринимается как дилетант, пытающийся найти изъяны в идеальной системе. Холивары в таких коллективах особенно вязкие: все одинаково уверены, что «очевидное очевидно», а любое альтернативное мнение априори ошибочно или упоминается лишь в контексте «идея хорошая, но делать ее мы не будем».

Скульптура против Lego: конфликт ценностей

В инженерной культуре сложность часто путают с качеством. Из-за этого возникают одни из самых затяжных конфликтов: когда один разработчик ратует за лаконичность и скорость, а другой — за «высокую архитектуру». Scala появилась именно из этой логики: язык создавался людьми, которые хотели объединить объектно-ориентированное и функциональное программирование в одном инструменте. Получилось мощно и академически красиво, но взаправду сложно. И вопрос, а всегда ли нужно вот настолько сложно, тоже порождает споры.

Хорошая аналогия — скульптура из мрамора против фигурки из Lego. Когда мы видим работы Страцца и Бернини, которые смогли передать в камне эффект тончайшей вуали, мы застываем в восхищении посреди музея. Но создание таких статуй требовало времени, а внести “правки от заказчика” означало бы подвергнуть риску всю работу: попробуйте исправить скол на мраморной статуе, которую ваяли сильно дольше, чем планировалось. В случае с конструкцией из Lego все намного проще: вынул блок, вставил другой, и вот из фигурки кошки уже получился «Тысячелетний сокол».

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

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

Конфликт как трудности перевода

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

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

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

Молчание как последствие конфликтофобии

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

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

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

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

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

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

Kotlin 2.4.0-Beta2. Ранний обзор будущей мажорной версии: изменения в языке, stdlib, JVM-бэкенде, Kotlin/Native и компиляторе.

Kotlin 2.3.21. Параллельный патч в стабильную ветку 2.3 — оптимизация производительности и баг-фиксы.

KotlinConf 2026. 20–22 мая в Мюнхене, ожидается 2000+ разработчиков. Онлайн-трансляция — на YouTube-канале Kotlin для тех, кто не сможет приехать.

Golden Kodee. Финалисты главной комьюнити-награды объявлены — top 3 в каждой категории получат приглашения в Мюнхен, победителей выберут на конференции.

Tooling. IntelliJ IDEA 2026.1, Amper 0.10.0 (автопровижн JDK, Maven-to-Amper конвертер), Ktor 3.4.3, Dokka 2.2.0, Exposed 1.0+ с поддержкой PostgreSQL array.

Kotlin 2.4.0-Beta2 и 2.3.21

JetBrains выложила первую Beta2 следующей мажорной версии — 2.4.0-Beta2. Это «предварительный взгляд» на то, что попадёт в стабильный релиз 2.4: изменения распределены сразу по нескольким слоям — самому языку, стандартной библиотеке, JVM-бэкенду, Kotlin/Native и компилятору. Если поддерживаете крупный проект — самое время прогнать его на бете и зарепортить регрессии до до заморозки кода.

Параллельно вышел 2.3.21 в стабильной ветке: фокус на производительности и багфиксах. Если вы пока не готовы переезжать на 2.4 — это безопасный апдейт минор-версии, без сюрпризов.

KotlinConf 2026 и Golden Kodee

Главное событие года для Kotlin-сообщества — KotlinConf 2026. Пройдёт 20–22 мая в Мюнхене, ожидается более 2000 разработчиков из разных стран. Если поехать не получается, JetBrains обещает livestream на YouTube-канале Kotlin — основные кейноты и анонсы можно будет посмотреть в прямом эфире.

К конференции приурочена ежегодная награда Golden Kodee для самых заметных людей сообщества — тех, кто организует мероприятия, делится знаниями, помогает новичкам. Финалисты в каждой категории объявлены: топ-3 в каждой категории приглашают в Мюнхен, победителей объявляют на конференции.

Из спикеров — стоит обратить внимание на keynote второго дня от Лены Райнхард: она будет говорить про карьеру в IT, лидерство, неопределённость на рынке и что значит «продуктивность» в эпоху ИИ.

Инструменты: IntelliJ, Amper, Koog, Ktor

Главные инструментальные апдейты апреля:

• IntelliJ IDEA 2026.1. Общая оптимизация производительности + улучшенная поддержка языков и фреймворков. Это значимый апдейт IDE, на который стоит переехать всем Kotlin-разработчикам.
• Amper 0.10.0. Инструмент сборки от JetBrains получил автоматический provisioning JDK (больше не нужно вручную ставить нужную версию), Maven-to-Amper конвертер (полезно для миграции проектов с легаси-кодом), поддержку кастомных Kotlin плагины компилятора и общее улучшение IDE-опыта.
• Koog для JVM-экосистемы. Koog — фреймворк JetBrains для построения AI-агентов на JVM. Появился идиоматичный Java API — теперь Java-команды могут строить пайплайны агентов без переписывания на Kotlin. Кроме того, Koog интегрировался со Spring AI — для Kotlin/Spring проектов это знакомый стек для работы с агентами.
• Ktor 3.4.3. Очередной патч асинхронного фреймворка для серверов и клиентов на Kotlin.
• Dokka 2.2.0. Стандартный документ-генератор для Kotlin-проектов.
• Exposed 1.0+. SQL-фреймворк теперь поддерживает array-типы PostgreSQL «из коробки» — раньше для этого нужны были custom-расширения.

Бэкенд, мультиплатформа и WebAssembly

Несколько практических материалов для тех, кто работает с Kotlin на бэкенде или в мультиплатформенных проектах:

• Spring Data JPA с Kotlin. Гайд про entities, repositories, custom queries и DTO — полезно для команд, уже сидящих на Spring и думающих про переход с Java на Kotlin.
• Spring guide: Uploading Files на Kotlin и Java. Параллельное сравнение помогает увидеть, как Kotlin вписывается в существующие бэкенд-процессы.
• Kotlin + WebAssembly с примером wasi:http (стандарт WebAssembly System Interface для HTTP-серверов) — минимальный HTTP-сервер на Kotlin/Wasm. Не production-ready, но ясно показывает, в каком направлении движется WebAssembly у Kotlin.
• KMP-аргументы для бизнеса. Гостевой пост от Touchlab про то, как объяснять руководству ценность Kotlin Multiplatform: ускорение поставки, снижение рисков, долгосрочная продуктовая стратегия. На tproger у нас был базовый туториал по созданию первого KMP-приложения для тех, кто хочет потрогать руками.

Обучение и развлечение

Если хочется прокачать или закрепить Kotlin — два полезных ресурса:

• Kotlin Professional Certificate by JetBrains на LinkedIn Learning. Четыре курса, финальный экзамен, сертификат на профиль. Заявленная длительность — менее 12 часов общего материала.
• Coroutines Races Guesser Game от kt.academy. Интерактивная игра: предсказываете, как поведут себя корутины в разных ситуациях. Хороший способ проверить интуицию по асинхронной логике, особенно если давно не работали со Structured Concurrency.

Выводы

Апрель в Kotlin-экосистеме оказался плотным: одновременно вышли беты будущей мажорной версии, патчи стабильной ветки, обновления IDE, инструментов сборки и фреймворков. Параллельно сообщество готовится к KotlinConf и финалу Golden Kodee. Если вы поддерживаете Kotlin-проект — стоит как минимум обновить IntelliJ до 2026.1 и поставить 2.3.21 в стабильный пайплайн.

Компания представила официальный Swift SDK для Android, позволяющий писать нативные Android-приложения на фирменном языке, изначально созданном для iOS и macOS.

От iPhone до Android

Swift появился в 2014 году как альтернатива Objective-C — более безопасный, современный и лаконичный язык для экосистемы Apple.

За 11 лет он вырос из «внутреннего» инструмента в многофункциональную платформу, на которой создают облачные сервисы, десктопные приложения для Windows и даже прошивки для микроконтроллеров.

Теперь Swift впервые официально выходит за пределы «яблочной экосистемы. Превью-версия SDK для Android доступна уже сегодня — в составе Swift-инсталлятора для Windows или отдельно для macOS и Linux.

Как это работает

Новый SDK — результат многомесячной работы Swift Android Workgroup, открытого сообщества, куда может присоединиться любой разработчик. С его помощью можно:

• собирать нативные Android-приложения на Swift;
• переносить существующие Swift-пакеты — более 25% уже совместимы с Android;
• интегрировать Swift-код с Java через проект swift-java, автоматически генерирующий безопасные биндинги между языками.

Apple опубликовала подробное руководство «Getting Started» и примеры кода, демонстрирующие полный цикл разработки Android-приложений на Swift.

Что это значит для экосистемы

Релиз открывает дорогу к кроссплатформенным приложениям без использования Flutter, Kotlin Multiplatform или React Native.

Теперь компании смогут писать бизнес-логику один раз на Swift и использовать ее и в iOS-, и в Android-версиях.

Эксперты отмечают, что шаг Apple может снизить барьеры между мобильными экосистемами и ускорить развитие open-source сообщества Swift.

Что дальше

По словам участников проекта, впереди — создание полноценного Android-Toolchain, улучшение совместимости со средами разработки и официальное внедрение CI-сборок.

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

«Swift вырос из языка для iOS в универсальный инструмент для всего программного мира. Теперь он будет жить и в Android-экосистеме», — говорится в сообщении разработчиков.

Современные приложения для камеры должны сочетать мощные функции: пользователи хотят снимать видео в HDR, с частотой 60 кадров в секунду и стабилизацией изображения — и всё это одновременно. Но как разработчику гарантировать, что устройство поддерживает такую комбинацию?

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

CameraX 1.5 решает эту проблему с помощью нового API Feature Group. Теперь вы можете заранее проверить поддержку комбинации функций или задать приоритеты, а библиотека сама подберёт оптимальную конфигурацию для устройства.

Что такое CameraX?

CameraX — это библиотека Jetpack, которая упрощает разработку приложений для камеры на Android. Она предлагает удобный и единообразный API, совместимый с большинством устройств, начиная с Android 6.0 (API level 23). Для новичков рекомендуем изучить официальную документацию и пройти практический codelab.

Возможности API Feature Group

Новый API позволяет создавать продвинутые приложения для камеры, избегая проблем с совместимостью. Вы сможете:

• Создавать адаптивные интерфейсы: Динамически включать или отключать настройки в зависимости от возможностей устройства. Например, если пользователь включает HDR, опция 60 FPS автоматически станет недоступной, если комбинация не поддерживается.
• Реализовать режим “Максимальное качество”: Укажите желаемые функции с приоритетами, и CameraX выберет лучшую комбинацию, поддерживаемую устройством, без сложной логики.
• Избежать сбоев: Проверка поддержки комбинаций заранее предотвращает ошибки при настройке камеры, обеспечивая стабильную работу.

Как это работает: основные компоненты

API построен на обновленных классах SessionConfig и CameraInfo.

• GroupableFeature: Включает набор функций, таких как HDR_HLG10, FPS_60, PREVIEW_STABILIZATION и IMAGE_ULTRA_HDR. Список пока ограничен из-за вычислительных требований, но будет расширен в следующих версиях.
• Новые параметры SessionConfig:requiredFeatureGroup: Для обязательных функций. Если комбинация не поддерживается, вызов bindToLifecycle завершится ошибкой IllegalArgumentException.preferredFeatureGroup :Для необязательных функций. Укажите список с приоритетами, и CameraX выберет лучшую комбинацию.
• requiredFeatureGroup: Для обязательных функций. Если комбинация не поддерживается, вызов bindToLifecycle завершится ошибкой IllegalArgumentException.
• preferredFeatureGroup: Для необязательных функций. Укажите список с приоритетами, и CameraX выберет лучшую комбинацию.
• CameraInfo#isFeatureGroupSupported(): Метод для проверки поддержки комбинации функций. Передайте SessionConfig, чтобы узнать, поддерживается ли набор функций, и настройте интерфейс соответственно.

Практическое применение

Рассмотрим два сценария использования API.

Сценарий 1: Режим "Максимальное качество"

Чтобы автоматически включить лучшие функции, задайте список приоритетов в preferredFeatureGroup. Например, приоритет: HDR, затем 60 FPS, затем стабилизация. CameraX сам выберет оптимальную комбинацию.

CameraX проверит комбинации в порядке приоритета, выбрав первую поддерживаемую:

1. HDR + 60 FPS + Стабилизация
2. HDR + 60 FPS
3. HDR + Стабилизация
4. HDR
5. 60 FPS + Стабилизация
6. 60 FPS
7. Стабилизация
8. Ничего

Сценарий 2: Адаптивный интерфейс

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

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

Ознакомьтесь с тестовым приложением CameraX для примера реализации (не для продакшена).

API Feature Group устраняет неопределенность при работе с продвинутыми функциями камеры, позволяя создавать надежные приложения. Он доступен как экспериментальный в CameraX 1.5 и станет стабильным в версии 1.6 с дополнительными улучшениями.

Смотреть подкаст на YouTube, в VK.

Анна Жаркова пишет нативные приложения под iOS и Android и кросс-платформенные приложения на Xamarin, Xamarin.Forms и Kotlin Multiplatform. Написала книгу о Kotlin Multiplatform, которая выходит в сентябре. Пишет статьи, выступает на конференциях и митапах. Член программного комитета Mobius, CodeFest, «Стачка». Увлекается живописью и участвует в выставках.

Поговорили о безумных проджект-менеджерах, войне Android и iOS, о том, почему ИИ не заменит программистов, и что делать, если вам позарез нужно установить ВСЕ приложения из магазина. Добро пожаловать в абсурдный и увлекательный мир мобильных разработчиков!

О смысле мобильных приложений

Какие нам вопросы задали наши прекрасные подписчики. Первый вопрос: «А зачем вообще нужны мобильные приложения? У меня вот компьютер, а у друга ноутбук».

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

Если попробовать ответить на этот вопрос серьёзно: мобильное устройство — это не просто «звонилка», это ещё и полезные клиентские приложения, которые позволяют получить быстрый доступ к информации или услугам. Конечно, это всё можно сделать и с компьютера, но главное назначение мобильного устройства — дать вам максимум возможностей при минимуме затрат: ресурсов, времени и с минимальным размером самого устройства.

Ну да, взять то же банковское приложение, оплату с телефона… Ребята, с компьютером не походишь, чтобы это всё делать. Давай поедем к следующему. Можно делать так, чтобы приложение ставилось не из App Store?

Конечно. Если это приложение под Android, оно будет ставиться через Google Play, а также есть специальные магазины, например, AppGallery для Huawei или RuStore. Также у некоторых вендоров есть свои маркеты, например, у Samsung.

Если же говорить про iOS, то тут всё строго с App Store. Но кто знает, возможно, в будущем появятся и кастомные магазины для iOS. Хотелось бы, чтобы поскорее.

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

Я думаю, если говорить про приложения, которые имеют ограничения в загрузке в App Store, они, в принципе, есть и в Google Play, но свободно грузятся в остальные магазины. Особых ограничений нет. Конечно, бывают ситуации, когда приложение пропадает из магазина по чьей-то жалобе. Но выбор приложений довольно большой. Например, в компании, где я работаю, мы свободно загружаем наши приложения в разные магазины, и всё в порядке.

Супер. А насколько вообще отличается разработка для, скажем, Huawei от классической Android? Там есть какая-то своя специфика, или всё тоже самое? Может, свой стэк?

Плюс-минус как Android, но есть определённые различия. У них своя среда разработки, свои сервисы, дополнительные технологии. Тема довольно обширная, но в принципе, всё это плюс-минус то же самое, и Android-разработчику освоить это несложно. Главное — поставить нужную IDE (Интегрированную среду разработки) и взять устройство для отладки.

А какие там специфические IDE?

Да, там есть, по-моему, собственная IDE, но я скажу честно, я с ней особо не работала. Я сейчас копаю немножко в другом направлении.

О фантастическом девайсе

«Пользователю позарез нужно установить вообще все мобильные приложения, которые существуют на маркете. Всё использует, всё жизненно важно. Вопрос: что представлял бы из себя девайс, который смог бы это выдержать?» Я с трудом представляю, интересно твоё мнение.

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

Но если говорить про аппарат, то это должен быть какой-то супермощный с параметрами из серии «Чёрная дыра». Современное приложение, тот же самый «суперап», который объединяет кучу сервисов, может занимать сотни мегабайт. Обычное банковское приложение — тоже несколько сотен мегабайт.

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

В реальности, конечно, это похоже на шутку «я сейчас все игры установлю». Но ни одного нормального девайса даже с супервозможностями не хватит. Сейчас максимум — это 512 ГБ внутреннего хранилища, часто без возможности расширения. Но даже с картой памяти вам точно не хватит.

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

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

О разработке на мобильном телефоне

«Раз для компов проги пишут на компах, разве не уместнее для мобилок писать на мобилках?»

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

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

Конечно, на мобильном устройстве можно скомпилировать какие-то простые, легковесные приложения, например, на скриптовых языках. Есть такие технологии. И в том числе можно использовать мобильные устройства как инструмент для разработки. У того же GitHub такое было.

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

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

Более того, даже для сборки мощных мобильных приложений на Mac сейчас часто требуется 32, а то и 64 ГБ памяти. Были бы, конечно, такие крутые мобильные устройства, полноценные мини-компьютеры… Но это уже из области фантазии наших зрителей.

О Keycloak и мобильной безопасности

Так, следующий вопрос. «Подскажите, кто-нибудь пользуется Keycloak для SSO (стандарт единого входа)?»

Интересный, конечно, вопрос про Keycloak. Я слышала такое слово от бэкендеров — это механизм, который используют для безопасности на бэкенд-части. Но что примечательно, с вопросом про Keycloak часто приходят именно к нам, мобильным разработчикам.

Тебе говорят слово «Keycloak», и ты думаешь: «Хорошо, а я тут причём?» Так что да, это довольно часто задаваемый не по адресу вопрос. Ответ — спросите у аналитика или у бэкенд-разработчика.

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

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

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

О выборе технологии: натив vs Flutter

Так, переходим к следующему вопросу. «Стоит ли погружаться в нативную разработку или сразу учить Flutter?»

Очень хороший вопрос. Flutter — это отдельная технология со своим языком Dart. Но тут есть маленький нюанс. Да, Flutter — технология отличная, но вы разрабатываете под Android и iOS, и поэтому вам необходимы знания нативной разработки, хотя бы в минимальном объёме. Есть проекты, где пишут код Flutter-разработчики, но от них требуют хороших, крепких знаний по нативу хотя бы одной платформы.

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

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

Безусловно. Вы исходите из того, что пишете под Android (или iOS). И уже смотрите: как я могу это делать? Я могу писать на нативе, а могу на Flutter’е. Но Flutter всё равно будет опираться на натив, поэтому получается такая ступень по изучению технологий.

О роли ИИ в мобильной разработке

Что сейчас можно сделать с помощью ИИ в мобильной разработке?

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

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

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

Вопрос от этого же задавателя вопросов. «Используют ли Kotlin Multiplatform React Native (технологии для кроссплатформенной разработки) и так далее? Если да, бывают ли задачи с адаптацией под мобильный веб?»

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

Но если говорить о продакшене, то тут имеет смысл использовать только то, что безопасно. Есть компании, которые разрабатывают свои инструменты на основе LLM-моделей, как, например, Яндекс. Есть те, кто берут открытые модели, разворачивают их и используют.

А вот публичные сервисы вроде ChatGPT я не рекомендую использовать для продакшена. Они могут залогировать ваш код и потом выдать его кому-то. Это крайне небезопасно. В прошлом или позапрошлом году был скандал, когда ChatGPT выдавал куски кода одной компании, вплоть до креденшиалов. Так что в продакшене — только собственные решения.

О сегментации рынков Android и iOS

Насколько реально сегментированы рынки Android и iOS?

Если говорить про iOS, то тут всё просто: один вендор — Apple. Вся экосистема: iOS, iPadOS, watchOS, специальная OS для авто. Минимальная сегментация. А вот с Android вендоров много. Это и гиганты типа Samsung, большой кусок рынка у Xiaomi и её суббрендов вроде Poco или Redmi.

Но стоит не забывать, что есть страны Латинской Америки, Африки, Юго-Восточной Азии, где ситуация с разработкой и устройствами совершенно другая, чем в Штатах, Европе или СНГ. Там до сих пор используют такие технологии, как Cordova, PhoneGap, потому что это дёшево, а iPhone там очень непопулярны — банально не по карману.

О самых сложных задачах

Какие задачи в мобильной разработке самые сложные?

Всё зависит от того, что считать задачами. Есть интересные фичевые задачи, которые дают возможность разрабатывать что-то новое. Есть рутинные, неинтересные, но простые задачи, которые просто отнимают много времени.

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

Но многие скажут, что самая сложная задача — это работа с заказчиком, с ТЗ, работа между командами. То есть, есть элемент технического челленджа, а есть — психологического. Разработчику надо уметь преодолевать и те, и другие, потому что это позволяет потом работать проще и интереснее.

Об ассемблере в 2025 году

«Какое место в Android и, видимо, iOS-разработке занимает ассемблер в 2025 году?» Вообще ассемблер и мобильная разработка, мне кажется, две немножко разные сущности.

Честно говоря, я не пользовалась ассемблером для мобильной разработки. Если у того, кто это задал, есть наработки, пусть пришлёт, посмотрим. Или придёт на Mobius и расскажет про это — у нас ещё открыт CFP. Если это будет супер-хардовый доклад, это будет здорово!

Например, пару лет назад у нас был человек, который встроил Doom (а он написан на ассемблере) в SwiftUI. То есть низкоуровневое что-то встраивается через C, C++ (например, через NDK для Android). Всё это можно сделать.

Но возникает вопрос: зачем? Потому что есть решение «потому что могу» — и это круто. А есть принцип разумной достаточности: не надо усложнять решение там, где это не нужно. Мы экономим и делаем оптимальной не только архитектуру приложения, но и время разработчика. Так что, отвечая на вопрос: есть Doom UI. Можете посмотреть: где только Doom не запускали.

О дизайне под Android и iOS

«Почему менеджеры и дизайнеры всегда хотят, чтобы на Android всё выглядело точно так же, как на iOS?»

Я думаю, потому что это красиво. У iOS долгое время очень много вкладывалось в визуал, в неповторимые жесты и систему. Это было просто супер. Затем Google решил догнать. Сначала появился Material Design, потом более продвинутый. И теперь, если посмотреть на доклады Google и Apple, можно заметить, что в какой-то момент предложения инженеров Google превращают Android в iOS, а у iOS есть тенденция становиться визуально похожим на Android.

Основная причина, почему хочется использовать iOS-подобный дизайн на Android, — «потому что красиво». Но Android не повезло: красивые вещи довольно затратны. Изначально Android затачивался под аппараты для всех, включая страны с дешёвыми устройствами малой мощности. Тащить туда всю красоту — вредить пользователям. Там действует принцип «максимум возможностей при минимальных затратах».

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

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

Были у них такие периоды, но это было связано скорее с языками (Swift у Apple, Jetpack Compose у Google), которые сильно менялись. Но кардинальной смены инструментов или парадигмы в ближайшее время не планируется.

Крик души мобильного разработчика

Так, ещё у нас остался один большой вопрос, прямо крик души. Цитирую: «Почему на симуляторе всё работает, а на телефоне нет? Телефон тупее? Если отключу фоновые процессы, батарейка начнёт заряжаться в обратную сторону? А можно сделать так, чтобы приложение работало одинаково на всех 19 тысячах моделей телефонов? Почему я должна платить 99 долларов в год, чтобы тестировать на своем же телефоне? Почему пуши приходят только тогда, когда я уже сама все проверила вручную? Почему SwiftUI делает все проще, но я все равно страдаю?»

Я так понимаю, это крик души. Мы пойдём по частям. Судя по желанию, «чтобы оно работало везде одинаково», — это PM или Product Owner detected. «Нехорошо, неправильно не делайте, делайте правильно». Вот такой тезис.

Давай пройдёмся по частям.

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

Про 99 долларов. Вы платите не мне, а компании Apple. А компания Apple считает, что вы должны платить, «потому что они красивые». Вот. Такова жизнь.

Про пуши и SwiftUI. Можно сказать, что страданиями душа совершенствуется, а также навыки разработчика. У каждой технологии есть подводные камни, главное — правильно её использовать. Но даже если вы знаете, как правильно, вы не застрахованы от багов и питфолов.

С пушами отдельная история. Доставка пуш-уведомлений — вещь негарантированная. Многое зависит от сервиса, который вы используете (Firebase часто капризничает, try RuStore, они стабильнее), от территориальных особенностей, от того, как настроена рассылка. На Android и iOS разные политики работы с пушами. Иногда, если понизить приоритет пушам, они дойдут гарантированнее, чем с высоким приоритетом. Всё индивидуально.

А по SwiftUI... Я очень сочувствую вашему опыту. Если вы посмотрите WWDC последних двух лет, особенно этот год, они даже не прикладывают исходники тех примеров, которые показывают. То есть покажут сниппет, а целиком приложение не дают. Так что, возможно, это всё на их совести. Пусть они спят плохо.

О собеседованиях и офферах

«Почему для получения оффера недостаточно, что в своём телефоне я разработчик?»

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

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

Чтобы вы получили оффер, мы должны понимать, что вы придёте и сможете делать задачи. 90% вопросов на собеседовании — это либо общая теория, либо обсуждение кейсов. Тестовые задания сейчас практически не дают, особенно на миддлов и сеньоров. Мы надеемся, что человек с опытом может мысленно разложить задачу и рассказать, как бы он это сделал. Чтобы показать, что он сможет с этим работать.

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

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

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

Если человек говорит: «Это всё гуглится», — возникает вопрос: «Зачем ты тогда тут?» Кейсы экономят время, не у всех может открыться среда для лайвкодинга, и они помогают понять, как человек мыслит и насколько он адекватен.

Об автомобильной разработке

Так, и вот последний странненький, на мой взгляд, вопрос. «Зачем нужны специалисты по мобильной разработке, если есть уже автомобильная?»

Хороший вопрос. Можно обыграть, что автомобильная — это разработка на vibe-кодинге, just for fun. Если говорить серьёзно, то автомобильную разработку тоже делают мобильные разработчики! Так что можно быть автомобильным разработчиком, но не сужайте себе поле, попробуйте другие девайсы, вам тоже понравится.

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

Новый стандарт 3.0 уже поддерживается большинством современных браузеров и приносит сразу несколько ключевых нововведений.

Главное из нововведений

• 64-битная адресация: теперь Wasm может использовать i64 вместо i32, что расширяет лимит адресуемой памяти с 4 ГБ до 16 ЭБ (в реальности — до 16 ГБ в браузерах).
• Несколько областей памяти: модули теперь могут напрямую использовать и копировать данные между разной памятью, без обходных трюков с импортом других модулей.
• Сборка мусора (GC): добавлена поддержка управляемой памяти для языков с автоматическим управлением памятью (например, Java, Scala, Kotlin, Dart).
• Типизированные ссылки: улучшенная типизация ссылок и функций позволяет избежать лишних проверок в рантайме.
• Исключения: наконец-то появилась полноценная система обработки исключений — с try, throw и catch, как в других языках.
• Хвостовые вызовы: позволяют не занимать стек при возврате через вызов, что критично для функциональных языков и оптимизаций.
• Расслабленные SIMD-инструкции: добавлены быстрые, но менее детерминированные версии векторных инструкций для повышения производительности.
• Детерминированный профиль: теперь для задач с требованием полной воспроизводимости (например, блокчейны) можно включить строго определенное поведение операций.
• Аннотации в тексте: появилась возможность вставлять пользовательские аннотации прямо в текстовый формат .wat.

Что это значит

WebAssembly становится всё ближе к полноценной виртуальной машине для высокоуровневых языков. В новой версии уже появляются компиляторы для Java, OCaml, Scala и прочих ЯП — благодаря поддержке GC и исключений.

Новый стандарт уже поддерживается в основных браузерах, включая Chrome и Firefox. Независимые движки, такие как Wasmtime, тоже догоняют.

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов – начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов.

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

Объяснять (и хвастаться) проще всего на примере – покажем, как развернуть распознавание паспорта РФ прямо на устройстве на Android.

Зачем это всё?

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

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

Немного вводных

SDK Smart ID Engine – это библиотека, собранная под нативную платформу, конфигурационный бандл и обёртка для вызова функций библиотеки с помощью других языков программирования (в этой статье нам понадобится java).

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

• Движок распознавания. Он создаётся с указанием конфигурационного бандла и представляет собой что-то вроде “склада инструментов” для распознавания различных документов. Движок создаётся в самом начале, существует на всём протяжении жизни (приложения или хотя бы сценария, в котором используется распознавание). От него создаются следующие элементы интерфейса:

• Сессия распознавания. Это сам процесс распознавания конкретного физического объекта – паспорта, ВУ, СТС, загранпаспорта и других. Всего по состоянию на сегодняшний день мы поддерживаем более 3 тысяч типов документов. В сессию можно передать всего одно изображение, а можно - серию изображений последовательно (видеопоток), при этом после каждого нового распознавания результат будет уточняться, а так же на основе уверенности в результате будет приниматься решение, нужно ли распознавать дальше или лучше уже не будет.

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

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

• Результат распознавания. Это объект, в котором хранится множество различной информации: координаты шаблонов документов (допустим, вторая и третья страницы паспорта ищутся отдельно) и всех полей на этих шаблонах, текстовые поля (вплоть до разбиения на варианты каждого символа с их весами), поля с изображениями, поля с проверками признаков подлинности документа. Как этим всем богатством пользоваться, расскажем чуть ниже.

Беглого взгляда на этот интерфейс достаточно, чтобы понять, как его правильно встроить в приложение. При старте приложения (или сценария) создаем экземпляр движка, перед непосредственно распознаванием создаем настройки сессии и заполняем их, после чего при переходе на экран с превью камеры создаем саму сессию распознавания и “кормим” её кадрами до тех пор, пока сессия не затерминалится (= не решит, что “ей хватит”). После чего можно переходить к разбору результата распознавания.

Как это встраивается и работает

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

Начнём с создания движка:

Объявим класс:

И приведём его имплементацию:

Теперь нам нужно создать и подготовить настройки сессии, чтобы библиотека знала, какие именно инструменты использовать при распознавании:

С имплементацией:

Дальше, наконец, само распознавание. Поскольку для распознавания нужно откуда-то брать кадры (мы всё же не волшебники), логично завести контроллер, который будет хранить сессию, иметь доступ к камере и кормить сессию кадрами, пока та не попросит остановиться. Реализуем свой ImageProcessor, который будет кормить кадры из превью сессии распознавания:

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

Теперь вы знаете, что встроить распознавание паспорта РФ в приложение для Android — намного проще, чем может показаться на первый взгляд.

Это далеко не единственный вариант использования нашего софта. Как минимум, помимо распознавания документов также можно сверять лица, проверять лицо на “живость”, организовывать распознавание двусторонних документов и еще много чего.

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

Если заинтересовались – добро пожаловать на наш сайт. И не расходимся, скоро расскажем еще много чего интересного!

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

Немного базы

Статьи, которые помогут разобраться, с чего начать и куда двигаться:

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

Создаём мобильное приложение с нуля: от идеи до публикации в App Store и Google Play — Делимся полным циклом создания: дизайн, разработка, тестирование, релиз.

Введение в мобильную разработку для Android: с каких языков начать изучение? — Рассматриваем, с каких языков программирования начать путь в Android-разработке и почему.

8 языков программирования для Android-разработчика — Перечисляем восемь языков программирования, которые стоит рассмотреть Android-разработчику. Изучаем плюсы, минусы, области применения, особенности.

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

Основы SwiftUI для iOS-разработчиков — Изучаем базовые возможности SwiftUI: декларативная верстка интерфейсов, примеры кода и сокращение сроков разработки.

Начало работы в Android Studio и первый простой проект — Пошаговое руководство по началу работы в Android Studio и созданию первого простого проекта. Учимся пользоваться инструментом с нуля.

Практика, инструменты и тонкости

Когда разобрались с базой — идём дальше и погружаемся в инструменты и реальные задачи:

Работа с анимацией в Android: разбираем MotionLayout — Рассказываем, как использовать MotionLayout для создания сложных анимаций в Android-приложениях. С примерами!

Jetpack Compose и Kotlin: как разрабатывать современные UI — Показываем, как разрабатывать современные пользовательские интерфейсы с помощью Jetpack Compose и языка Kotlin. Делимся, как использовать в проектах.

Java vs Kotlin для Android-разработки: ответы «за» и «против» — Сравниваем Java и Kotlin для Android-разработки: плюсы, минусы и рекомендации по выбору.

Бойлерплейт Fastlane для быстрого обновления Android-приложений — Показываем, как использовать Fastlane для автоматизации обновлений Android-приложений, даем рекомендации по применению.

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

Про рост, релиз и продвижение

Когда всё работает — пора думать про рост, релиз и продвижение:

Как добавить приложение в Google Play — Объясняем, как подготовить и опубликовать приложение в Google Play: от регистрации до релиза.

5 главных ошибок в ASO — App Store Optimization — Разбираем пять распространенных ошибок в App Store Optimization и как их избежать. Что нужно делать, чтобы не слить продвижение.

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

Не забудьте сохранить, чтобы не искать потом по всему интернету!

Большая подборка по React — уже на сайте.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Определяем цель

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

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

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

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

Выбираем платформу и инструменты

Сегодня на российском рынке доминируют две мобильные операционные системы: Android (около 70% пользователей) и iOS (около 30%). Оптимальным решением будет разработка приложения для обеих платформ, особенно если вы ориентируетесь на крупные города, где доля пользователей iOS существенно выше.

Приложения под Android большинство разработчиков пишет на Kotlin, хотя Java до сих пор остается одним из вариантов из-за обширной базы готовых решений и библиотек. Основной средой выступает Android Studio — в ней есть весь необходимый инструментарий для создания, отладки и тестирования приложений. Современные разработчики активно используют Jetpack Compose для построения пользовательского интерфейса, Room для работы с базами данных, Retrofit для сетевых запросов и Dagger или Hilt для внедрения зависимостей.

В мире iOS основным языком программирования стал Swift — современный и безопасный инструмент для нативных приложений. Разработка ведется в среде Xcode, официальной IDE от Apple. Для построения интерфейсов все чаще используется SwiftUI, для управления данными — Core Data, а для сетевого взаимодействия — фреймворк Alamofire. Работа с асинхронными событиями упрощается с помощью фреймворка Combine.

При ограниченных ресурсах можно рассмотреть кросс-платформенную разработку. Так, Flutter использует язык программирования Dart и позволяет создавать производительные приложения с нативным внешним видом. React Native дает возможность применять веб-технологии для мобильной разработки, а Xamarin ориентирован на разработчиков, привыкших к экосистеме Microsoft и языку C#.

Выбор платформы и инструментов должен основываться на характеристиках вашей ЦА, требованиях к функционалу и имеющихся ресурсах. Учитывайте также, что для разных магазинов приложений (RuStore, App Store, Google Play) могут потребоваться специфические оптимизации и настройки.

Продумываем функционал

При разработке функционала важно следовать концепции MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это позволит быстрее выйти на рынок, получить обратную связь и итеративно улучшить приложение.

Возьмем для примера приложение доставки еды. В этом случае MVP должен включать:

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

Важно уделить внимание и техническим аспектам функционала:

• Локальное кэширование данных. Поддерживает работу приложения при слабом интернет-соединении или его отсутствии. Сохраняет каталоги, популярные позиции и историю действий пользователя.
• Офлайн-режим. Определяет набор функций, доступных без подключения к сети. Критически важен для удержания пользователей в зонах с плохим интернетом.
• Система пуш-уведомлений. Информирует пользователей о важных событиях, статусах заказов и специальных предложениях. Повышает вовлеченность и возвращаемость в приложение.
• Многопоточная обработка. Выполняет ресурсоемкие операции в фоновом режиме. Гарантирует отзывчивость интерфейса даже при выполнении сложных задач.
• Оптимизация изображений. Внедряет алгоритмы сжатия для быстрой загрузки визуального контента. Обеспечивает комфортное использование даже при ограниченной скорости соединения.

При этом разработчики часто допускают ошибки, и одна из самых распространенных — функциональная перегруженность. Не стоит добавлять AR-анимации, игровые механики и другие «модные» функции, если они не решают реальных проблем клиентов.

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

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

• MVVM — рекомендуемый Google подход с разделением UI и бизнес-логики
• MVI — однонаправленный поток данных, хорошо сочетается с реактивным программированием
• MVP — классическая архитектура. Популярна благодаря простоте реализации
• Clean Architecture — многослойный подход с упором на тестируемость и гибкость
• VIPER (iOS) — расширенный MVC со строгим разделением ответственности

Важное значение имеет также выбор технологий для хранения и передачи данных. Для локальной работы подойдут SQLite + Room, Realm или DataStore; для сетевого взаимодействия на Android чаще всего используют Retrofit + OkHttp, а в реактивных сценариях — Ktor Client.

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

Создаем удобный интерфейс

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

Эффективный UI/UX строится на пяти ключевых принципах:

1. Очевидность (интуитивное понимание интерфейса);
2. Экономия внимания (минимум шагов для достижения цели);
3. Консистентность (единообразие элементов с одинаковой функциональностью);
4. Обратная связь (видимый результат каждого действия);
5. Прощение ошибок (возможность отмены операций).

Современные инструменты значительно ускоряют создание качественных интерфейсов. Дизайнеры используют Figma, Adobe XD и Sketch для прототипирования. Android-разработчики предпочитают Jetpack Compose и Material Design Components. Для iOS актуальны SwiftUI, UIKit и Human Interface Guidelines от Apple.

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

Проводим тестирование

Юзабилити-тесты с фокус-группами, A/B-тестирование элементов и аналитика пользовательского поведения дают объективную картину взаимодействия клиентов с приложением.

Комплексное тестирование включает два основных направления:

1. Автоматизированное тестирование: unit-тесты (JUnit, XCTest) для проверки отдельных компонентов; интеграционные тесты для проверки взаимодействия между модулями; UI-тесты (Espresso, XCUITest) для проверки интерфейса; end-to-end тесты для имитации полного пользовательского сценария.
2. Ручное тестирование: функциональное (соответствие требованиям), тестирование производительности (работа под нагрузкой), юзабилити (оценка удобства), кросс-платформенное тестирование (проверка на разных устройствах) и тестирование подключений (поведение при различном качестве интернет-соединения).

Для этого используют специализированные инструменты: Firebase Test Lab для запуска тестов на множестве устройств, Crashlytics для мониторинга сбоев, Android Profiler и Xcode Instruments для анализа производительности. А Accessibility Scanner помогает адаптировать интерфейс для людей с ограниченными возможностями, расширяя потенциальную аудиторию.

Публикуем приложение

После тестирования и исправления проблем наступает ответственный момент публикации. Каждый магазин приложений имеет свои особенности процесса:

• Google Play: создание аккаунта разработчика ($25 единоразово); подготовка материалов (иконка, скриншоты, видео, описание); загрузка APK/App Bundle; заполнение формы оценки контента; настройка дистрибуции и ценообразования; ожидание проверки (до 2 дней).
• App Store: регистрация в Apple Developer Program ($99/год); создание записи в App Store Connect; подготовка маркетинговых материалов; загрузка сборки из Xcode; заполнение информации о возрастных ограничениях; ожидание рассмотрения (1-7 дней).
• RuStore: бесплатное создание аккаунта; подготовка материалов; загрузка APK; заполнение метаданных; быстрая модерация (до часа).

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

Поддерживаем и обновляем

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

Для эффективного мониторинга используют комплексные аналитические инструменты: Firebase Crashlytics для отслеживания сбоев, Firebase Analytics/Google Analytics для анализа пользовательского поведения, RuStore Remote Config — бесплатный аналог Firebase, Mixpanel для углубленного анализа пользовательских путей, AppMetrica от Яндекса как комплексное решение для российского рынка.

Автоматизация процессов разработки критически важна для регулярных релизов. CI/CD-системы (GitHub Actions, GitLab CI, Bitrise, Fastlane) позволяют автоматизировать сборку, тестирование и публикацию обновлений, значительно сокращая время выхода новых версий.

Оптимальная стратегия обновлений включает регулярный график релизов (каждые 2-4 недели) с четким приоритетом задач: критические исправления, новые функции, оптимизация производительности. В тренде современной разработки: персонализация на основе ИИ, многофункциональные суперапп-решения, адаптация под новые форм-факторы устройств и повышенное внимание к приватности данных.

Продвигаем приложение

На рынке огромная конкуренция, и без активного продвижения ваш продукт просто затеряется среди тысяч других программ. Важную роль здесь играет ASO (App Store Optimization) — оптимизация для магазина приложений. В некоторых случаях был зафиксирован рост установок до 70% благодаря сильным ASO-стратегиям.

Для Android-приложений это означает настройку страницы так, чтобы пользователи легко находили ваш продукт. Здесь важно правильно подобрать ключевые слова для описания, создать привлекательную иконку и подготовить качественные скриншоты. Чтобы понять, какое оформление работает лучше, разработчики всё чаще используют A/B-тесты — такая возможность есть, например, в RuStore. Она позволяет сравнить разные версии карточки приложения и выбрать ту, которая эффективнее привлекает пользователей.

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

Еще один инструмент для продвижения приложений — социальные сети. Здесь можно показывать функционал программы, общаться с пользователями, отвечать на их вопросы и рассказывать о новых опциях. Это помогает создать активное сообщество вокруг продукта. Так, к примеру, В 2023 году компания Geozilla, разработчик приложения для отслеживания местоположения близких, провела кампанию по продвижению с инфлюенсерами в социальных сетях. В рамках сотрудничества удалось собрать более 1 миллиона просмотров, а коэффициент конверсии из кликов в установки приложения составил 24%.

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

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

Подводим итоги

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

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

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

Меня зовут Вадим Ваганов, я руководитель разработки и Head of Profession Backend в Газпромбанке. Я люблю делиться опытом, а также обучать и приносить пользу другим. Все свои статьи я строю на личных историях, так что эта будет такой же. Она для тех, кто только начинает свой путь в бэкенд-разработке и еще не вник в вопросы визуализации своей работы. Расскажу, почему стоит инвестировать время в эти направления и как благодаря им вы станете более крутым инженером с первых шагов в профессии.

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

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

Фронтендерам и мобильщикам чуть проще в начале пути разработчика: они могут нарисовать красивую кнопочку, сделать что-то визуальное, и даже если логика проста, то визуал можно «продать» — банально показать друзьям. А бэкендерам что показать? Как в консольку выводим циферки?

Это, конечно, шутка (хоть и с долей правды), но проблема демонстрации результатов своей работы для бэкендеров действительно существует — будь то коллеге, боссу, бизнесу или самому себе, в конце концов. Решение есть — метрики, визуализация, мониторинг. Эта тема сильно недооценена. Часто люди ничем, кроме логов, не пользуются. Не допускайте этой ошибки!

Начинаем с простого: получаем данные о состоянии приложения

Я не хочу делать это просто вводной, теоретической статьей по мониторингу. Нам нужна база, и мы рассмотрим ее на практике. Все примеры доступны в репозитории на GitHub, где вы найдете полный код и конфигурацию. Вы можете либо клонировать репозиторий, либо настроить все с нуля, следуя инструкциям ниже. Нам понадобится всего 5–10 минут, чтобы получить первые результаты.

Подготовка окружения

Для примера нам понадобятся:

• Docker
• JDK 17

Все придумано до нас, поэтому воспользуемся готовыми инструментами — например, micrometer (документация тут) или аналог, если у вас не Java/Kotlin. Интегрируем его с /actuator.

В build.gradle нужно добавить следующее:

Проверяем запрос в тестовом контроллере:

и смотрим на метрики:

Пока что мы можем получать такую информацию в моменте, но мы хотим историчности, следовательно, это дело надо как-то получать и где-то хранить.

У нас есть заготовленный конфиг, чтобы поднять Grafana и Prometheus:

Открываем UI Prometheus, пробуем найти demo_requests_total, нажимаем Execute, проверяем историчность — она есть!

Теперь можно визуализировать данные. Открываем Grafana, вводим admin/admin и создаем дашборд:

1. Dashboards -> Create Dashboard -> Add visualization
2. Конфигурируем Data Source: Configure a new data source -> Prometheus -> Connection = http://prometheus:9090 -> Save & test
3. Возвращаемся к меню Create Dashboard -> Add visualization, выбираем Data Source prometheus
4. Настраиваем дашборд: выбираем Code вместо Builder, пишем sum (rate(demo_requests_total[1m]))

Отлично! Давайте накидаем еще запросов, чтобы посмотреть, как это будет выглядеть:

Теперь у нас на графике видна динамика запросов. Инструментарий готов! Теперь мы можем:

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

Что отслеживать в бэкенд-приложениях

У вас когда-нибудь было состояние, когда вам плохо, болит голова, першит горло, и вы думаете, что все — у вас 38 °C, и вы жутко простудились. Берете градусник, измеряете температуру... А у вас 36.6 °C. Не полагайтесь на ощущения — смотрите в мониторинг!

Состояние серверов и инфраструктуры

• Загруженность CPU и памяти серверов.
• Загруженность дисков.
• Мониторинг сети.
• И другие инфраструктурные метрики.

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

Метрики производительности приложения

В SRE Google выделяют 4 золотых сигнала:

1. Latency (задержка) — время, необходимое для обработки запроса;
2. Traffic (трафик) — количество запросов к системе;
3. Errors (ошибки) — процент запросов, которые заканчиваются ошибкой;
4. Saturation (насыщение) — насколько система загружена.

ВАЖНО: иногда ваше приложение начинает работать медленно из-за интеграций, поэтому их тоже просто необходимо отслеживать. Если провайдер данных отвечает за 1 с, а у вас в SLA — 250 мс, то как бы производительно и надежно ни было ваше приложение — у вас уже проблемы.

Бизнес-метрики

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

Если вы проверяете гипотезы или проводите a/b-тестирование — собирать и визуализировать метрики просто обязательно.

Красиво — это не только про визуал. Получать обратную связь и взаимодействовать с системой/продуктом — тоже красиво!

Почему мониторинг — это навык, который стоит прокачать любому инженеру

Мониторинг как важная составляющая DevOps- и SRE-практик

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

Взаимодействие мониторинга с процессами CI/CD

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

Мониторинг помогает убедиться, что новые изменения работают как задумано, а также не приводят к ухудшению производительности или стабильности системы. Интеграция мониторинга в CI/CD позволяет быстро выявлять проблемы и откатывать изменения, если что-то пошло не так.

Универсальный и вечнозеленый навык

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

Важность анализа данных о вашем продукте

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

Возможность предвидеть и предотвращать проблемы

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

Подведение итогов

Метрики — это то, что ты хочешь смотреть не только когда плохо, но и когда хорошо.

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

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

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

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

И да, мониторинг — это просто красиво. Когда наглядно видишь тонкости работы приложения — это совершенно новый уровень погружения в работу.

Так что если вы еще не начали заниматься мониторингом, самое время начать. У вас есть все инструменты и все возможности — вы можете скачать наш репозиторий и начать вникать прямо сейчас.

Полезные источники

• Официальная документация Micrometer
• Официальная документация Prometheus
• Официальная документация Grafana
• 4 золотых сигнала
• Книга об SRE

Если вам понравится материал и вы захотите ознакомиться с другим моим контентом — приглашаю в мой телеграм-канал.

Как ИИ меняет процесс разработки

По данным Ведомостей, рост использования нейросетей ускоряет цифровую трансформацию компаний.

По прогнозам МТС, к 2030 году более 90% программистов будут применять ИИ-инструменты для написания и проверки кода.

На данный момент:

• В среднем на рынке ИИ выполняет 5–10% рутинных задач.
• Нейросети заменяют функционал джуниор-разработчиков.
• Роль программистов постепенно трансформируется в архитектора решений.
• В 25% стартапов Y Combinator ИИ уже написал 95% кода.

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

Какие решения внедряют компании

• МТС развивает DevX-платформу и Kodify, которые помогают ускорить разработку на 55%.
• Яндекс представил SourceCraft Code Assistant, который генерирует более 250 тыс строк кода в неделю для своих разработчиков. Поддерживаются 30+ языков, включая C++, Go, Kotlin, Python и другие.

Это инструмент для командной работы над кодом, в котором есть автоматизация CI/CD, умная навигация и встроенный ИИ-ассистент.

Пока что сервис работает в тестовом режиме — доступ можно получить по заявке.

Что умеет SourceCraft

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

Одним из главных элементов платформы стал ИИ-ассистент SourceCraft Code Assistant. Он поддерживает более 30 языков программирования (C++, Go, Java, Kotlin, Python и др), предлагает автодополнение кода и вскоре получит режим чата.

Инструмент уже протестировали тысячи пользователей, а также он доступен как плагин для VSCode и JetBrains.

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

Будущее платформы

Сейчас SourceCraft доступен через веб-интерфейс, но в будущем появится глубокая интеграция с Yandex Cloud — развернуть проект в облаке можно будет «по нажатию кнопки».

Отдельный фокус сделан на безопасность. В ближайших обновлениях появятся:

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

Jetpack Compose: что это за зверь

Jetpack Compose — современный инструмент для создания пользовательских интерфейсов на Android, который использует декларативный подход. Разработчик описывает, как должен выглядеть UI в зависимости от данных, а система автоматически обновляет его при изменении этих данных. Так, вместо императивного управления элементами интерфейса, как в традиционной Android-разработке, Compose позволяет сосредоточиться на конечном результате.

Чем Compose отличается от традиционного XML

Традиционно интерфейсы в Android создаются с помощью XML-разметки, но этот метод имеет ряд недостатков:

• Разделяет логику интерфейса (XML) и управления им (Kotlin/Java), что усложняет поддержку;
• Усложняет код по мере роста приложения;
• Необходимо вручную обновлять UI при изменении данных.

Compose заменяет XML-разметку Kotlin-кодом, в котором UI описывается с помощью функций. Фреймворк сам отслеживает изменения данных и обновляет только нужные элементы.

Основные концепции: Composable-функции, Recomposition, State

Composable-функции

Основной строительный блок интерфейсов в Jetpack Compose — Composable-функции. Они представляют собой модули, из которых можно собирать весь UI. Каждая функция отвечает за определённую часть интерфейса, а сложные экраны формируются путем комбинирования элементов.

Recomposition

Одна из ключевых особенностей Jetpack Compose — механизм Recomposition. Если изменяются данные, система пересчитывает и обновляет только те элементы интерфейса, которые зависят от этих данных. Это повышает производительность и избавляет разработчика от необходимости вручную следить за обновлениями UI.

State

Для управления изменяемыми данными в Compose используется механизм State. Он позволяет отслеживать изменения данных и автоматически обновлять связанные элементы интерфейса. Работа с состоянием в Compose построена на реактивных принципах, что делает его управление более удобным и предсказуемым.

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

Как установить и настроить проект

Добавьте зависимости

Это первый шаг в освоении Jetpack Compose. Чтобы начать работу, нужно открыть build.gradle файл и добавить туда следующие строки:

Так подключаются основные библиотеки для работы с Compose UI и Material Design.

Проверьте минимальные требования

В первую очередь, нужно обновить Android Studio хотя бы до версии Arctic Fox или выше. Также необходимо апдейтнуть Gradle до 7.x и Kotlin до версии 1.5.x.

Минимальная версия API проекта должна быть не ниже 21 (да простят нас пользователи старых телефонов). Если хотите использовать все фишки Compose по максимуму — не ниже 23.

Легко запустите пустой проект

Запустив Android Studio и создав новый проект, выберите шаблон Empty Compose Activity. В итоге увидите проект со всеми добавленными настройками и фрагментами.

Если же вы начинаете проект с нуля, то просто вставьте зависимости из первого пункта и проверьте настройки compileSdkVersion и minSdkVersion.

Как создать базовые компоненты UI

Если раньше разработка интерфейсов была долгим и сложным логическим процессом, то с Kotlin и Jetpack Compose работа с UI превратилась в старый добрый тетрис, где задача — просто контролировать расположение блоков.

Работа с текстами

Создать текстовый элемент здесь очень просто:

Если нужно работать с оформлением и стилем текста, то:

Кнопки и их стилизация

В Compose кнопки создаются так же легко, как и текст:

Ещё кнопки можно стилизовать:

Организация макетов: Column, Row, Box

В компоновке элементов UI всё должно быть на своих местах. В Jetpack Compose есть 3 главных инструмента для организации макета: Column, Row и Box.

Column используется для вертикального расположения элементов:

И наоборот, когда элементы должны располагаться горизонтально, используется Row:

Box — инструмент для наложения элементов друг на друга:

Как управлять состоянием в Jetpack Compose

В Jetpack Compose концепция State играет очень важную роль. State — часть данных приложения, которая может меняться со временем. Здесь «лежать» способно что угодно: от простого текста до информации о данных пользователя.

Использование remember и mutableStateOf

Как управлять состоянием в Kotlin и Jetpack Compose? Здесь на помощь приходят функции remember и mutableStateOf.

Когда вы пересоздаете UI (например, из-за изменения данных), remember поможет сохранить значения.

Пример с кнопкой-счётчиком:

Здесь mutableStateOf(0) создаёт изменяемое состояние с начальным значением 0, а remember удерживает это состояние во время пересозданий компонента Counter. Так, при клике значение увеличивается на единицу.

Поддержание реактивности интерфейса

Один из главных плюсов Jetpack Compose — его реактивность. Изменения состояния автоматически обновляют пользовательский интерфейс без ручного ввода.

Когда Counter вызывается заново из-за высокого значения count после клика, система Jetpack Compose автоматически обновляет только те части интерфейса, которые зависят от этих данных.

Управление состоянием — база в создании UI на основе Kotlin и Jetpack Compose.

Темизация и стилизация

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

Работа с темами: Light и Dark mode

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

Определение кастомной темы приложения

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

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

Использование Material Design 3

С выходом Material Design 3, на Android можно создавать ещё более интуитивные и адаптивные дизайны — всё зависит от ваших предпочтений и нужд.

Например, с помощью поддержки динамической цветовой схемы (Dynamic Color), можно адаптировать цвета интерфейса к обоям устройства и другим условиям.

Кроме того, в Material Design 3 есть обновлённый набор компонентов UI с адаптацией под разрешение экрана и ориентацию устройства.

Сложные интерфейсы

Эффективность, удобство и привлекательность — 3 кита, на которых строится успешное приложение. Разбираемся, как с помощью Kotlin и Jetpack Compose создавать сложные интерфейсы.

Работа со списками: LazyColumn и LazyRow

Можно работать с LazyColumn и LazyRow — они используются для отображения больших наборов данных без «утяжеления» производительности приложения.

LazyColumn — вертикальный список элементов, который подгружает данные по мере необходимости. Для создания списка используется @Composable, а сами элементы списка создаются внутри блока items:

А LazyRow позволяет создавать горизонтальные списки — подойдёт для каруселей или галерей:

Также с помощью этих компонентов вы можете добавлять разделители и/или анимации:

Создание пользовательских Composable-компонентов

Собственные composable-компоненты — возможность создавать уникальные элементы интерфейса. Для этого достаточно поместить логику отображения элементов с помощью @Composable:

@Composable можно использовать, например, с настройкой параметров onClick и label — так улучшается модульность кода.

Анимации в Jetpack Compose: плавные переходы и визуальные эффекты

В Jetpack Compose есть API для создания плавных переходов между блоками через функции по типу animateDpAsState и animateColorAsState. Например, для изменения размера можно использовать анимацию:

Также необходима библиотека Accompanist или функции вроде AnimatedVisibility, для динамического отображения контента с эффектом появления/исчезновения:

Интеграция с существующими Android-компонентами

Jetpack Compose можно использовать в существующих Android-приложениях, не переписывая их с нуля. Для этого предусмотрена интеграция с компонентами View через ComposeView.

Встраивание Compose в существующие приложения

В приложениях, где уже используется XML-разметка, элементы Compose можно добавлять через ComposeView, вставляя их прямо в макет или Activity:

Например: добавим Text в XML-разметку через ComposeView:

Далее, в Activity:

Использование View и Compose вместе (interop)

При постепенном переходе на Compose можно внедрять его в отдельные UI-элементы. Например, статическую часть формы оставить в XML, а интерактивную — реализовать на Compose:

Такой подход позволяет постепенно внедрять Compose в проект, сохраняя совместимость с существующим кодом.

Тестирование интерфейсов

Инструменты для тестирования Jetpack Compose

В Jetpack Compose есть набор инструментов для тестирования UI. Один из главных — библиотека Compose Test, в которой вы можете найти функции для проверки UI. Она работает с Android Testing Framework, а значит, можно не забывать привычный для разработчиков синтаксис.

С помощью Compose Test можно:

• Проверять отображение и свойства элементов UI;
• Симулировать пользовательские действия (нажатия, прокрутку, ввод текста);
• Изменять состояние приложения в тестовой среде.

UI-тесты и проверка состояния

В автоматизированных тестах есть 2 основных типа: юнит-тесты (фокус на коде) и UI-тесты (фокус на интерфейсе и взаимодействии пользователя с ним).

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

• Отображается ли нужная кнопка на экране;
• Изменяется ли текст после нажатия;
• Работает ли прокрутка списков.

Jetpack Compose делает UI-тестирование удобнее, позволяя работать с декларативным подходом и минимизировать сложность тестов.

Примеры написания тестов

Несколько примеров UI-тестов с использованием библиотеки Compose Test.

Пример 1: проверка наличия элемента

Пример 2: работа с элементами

Пример 3: проверка изменения состояния

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

Советы по оптимизации производительности

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

Избегайте избыточной рекомпозиции

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

Как свести рекомпозицию к минимуму:

1. Используйте remember, чтобы не было пересоздания одного и того же состояния. Так снижается нагрузка на систему, а работа приложения ускоряется.
2. Разделяйте состояния композиций так, чтобы изменения одного элемента не приводили к рекомпозиции других элементов. Здесь поможет принцип SRP.
3. Чем более простой элемент, тем быстрее наступят изменения.

Используйте инструментов Android Studio для анализа производительности

Основные инструменты:

1. Layout Inspector. Позволяет создать дерево компоновки приложения в реальном времени, показывая затраты на выполнение функций и методов.
2. Profiler. Даёт полную информацию об использовании ресурсов приложения и определяет потенциальные проблемы с производительностью.
3. Сравнительный анализ. Помогает выявить слабые места при взаимодействии пользователя с приложением.

Вы можете создавать более интерактивные и интересные (с точки зрения визуала) приложения с меньшими затратами времени и усилий. Вообще Jetpack Compose не только ускоряет процесс создания UI, но и поднимает качество приложения. Пользуйтесь!

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

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

1 этап — идея

На этапе работы над идеей важно решить, какие запросы пользователей будет решать приложение, почему нужно устанавливать его, а не приложение конкурента. А ещё важно определиться с УТП и понимать аудиторию.

Выбор ниши — крайне важный шаг. Sensor Tower: за 2024 год выручка мобильных приложений достигла $81 млрд, что выше изначального прогноза на год.

Важно понять: мобильное приложение — это бизнес. А значит, важно определиться с нишей и предложением для пользователей.

Чтобы выбрать правильную нишу, нужно:

• Понять, что вам действительно интересно, в чём вы экспертны. Ваша задача — заниматься тем, что вам действительно по душе, и «заражать» этой идеей пользователей.
• Оценить спрос на выбранную нишу. Для первичного анализа интереса можно использовать простые инструменты по типу Google Trends.
• Создать портреты ваших потенциальных пользователей. Это и демографические данные (пол, возраст, география), и психографические (интересы, потребности, поведение пользователей). Важно создать несколько портретов пользователей и как можно более подробно — вам это пригодится в продвижении приложения.

Следующий шаг — подробный анализ конкурентов. А для этого как минимум нужно:

• Составить список прямых и косвенных конкурентов. Найдите приложения с функционалом, похожим на ваш продукт.
• Проанализировать отзывы пользователей в сторах — что нравится и не нравится пользователям, о чём они пишут?
• Провести SWOT-анализ (сильные и слабые стороны конкурентов и ниши, возможности и угрозы конкурентов и ниши).
• Найти недостатки у конкурентов и решить, как вы можете улучшить пользовательский опыт, как именно вы можете усилить ваше предложение.
• Глубже погрузиться в статистику, используя для этого ресурсы по типу Statista, App Annie и другие платформы.

2 этап — планирование и дизайн

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

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

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

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

С помощью Figma или Sketch можно создать интерактивные прототипы без необходимости писать код. При этом, если дизайном приложения занимается другой человек, вы всегда сможете перейти, например, в Фигму, и оставить комментарии прямо там, чтобы дизайнер понимал, как улучшить интерфейс. А значит, вы и сами сможете протестировать пользовательский интерфейс ещё до начала фактической разработки приложения. Да ещё и сэкономите время, деньги… И нервы 🙂

3 этап — технологии и инструменты разработки

Есть два вида разработки приложений: нативная и кроссплатформенная. Нативная разработка предполагает создание приложения для каждой платформы отдельно на базе Swift для iOS и Kotlin для Android.

Swift — специально разработанный Apple язык программирования для создания приложений под iOS, macOS, watchOS и tvOS. На базе Свифта можно создавать быстрые приложения, которые по максимуму используют возможности экосистемы Apple.

Кotlin от Google — стандарт нативной разработки для устройств на базе Android. Приложения на Kotlin легко интегрируются с существующим Java-кодом благодаря совместимости JVM.

Кроссплатформенная разработка подойдёт для тех, кто хочет создать приложение сразу для нескольких платформ.

Flutter от Google помогает в разработке приложения для iOS и Android из одного исходного кода на базе языка Dart. У Flutter есть большие библиотеки виджетов с возможностью создания сложных пользовательских интерфейсов.

React Native от Facebook хорош как кроссплатформенное решение тем, что использует JavaScript для создания мобильных приложений. Принцип работы тот же, что и у Flutter — создаётся «обёртка» над нативными компонентами.

При выборе инструментов нужно отталкиваться не столько от платформы разработки, сколько от удобства работы в IDE. Например, Xcode — это официальная среда разработки от Apple для создания приложений под iOS. В Xcode есть редактор кода, симулятор устройств и инструменты для отладки. А Android Studio — официальная IDE от Google, которая работает с Kotlin и Java.

А ещё для кроссплатформенной разработки часто работают с VS Code — его выбирают за поддержку разных языков программирования, включая Dart и JavaScript.

4 этап — разработка

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

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

Что ещё важно:

• Придерживаться принципа SOLID. Один класс = одна задача; классы должны быть открыты для расширения, но закрыты для изменения; объекты должны быть заменяемыми, но без изменения корректности работы; большой интерфейс = много небольших, но конкретных интерфейсов; высокоуровневые модули должны быть отделены от низкоуровневых.
• Чистый, читаемый код. Это важно для дальнейшего развития вашего приложения. Везде, где возможно, оставляйте комментарии, чтобы позже вы могли к ним вернуться.
• Контроль версий. Здесь помогут системы по типу Git для отслеживания изменений в коде.

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

Следующий шаг — выбор базы данных. Для хранения данных на iOS часто используют Core Data или SQLite, а для Android — Room. А если вы работаете с облачными базами, используйте решения по типу Firebase.

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

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

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

5 этап — подготовка к публикации

У App Store строгие правила по контенту и функциональности приложений. Здесь абсолютно все модули — от интерфейса до API — тщательно проверяются. По этой ссылке вы найдёте информацию о стандартах проверки приложений Apple.

А вот с Google Play ситуация обстоит гораздо лучше. Но, разумеется, вы в любом случае должны соблюдать стандарты Google Play Developer Policy Center.

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

• Для регистрации в программе Apple Developer нужно внести оплату годового взноса в размере $99;
• Регистрация разработчика через Google Play Console обойдётся в $25 единоразово.

Следующий шаг подготовки к публикации приложения — заполнение страницы:

• Иконка вашего приложения должна быть запоминающейся. Не забывайте про рекомендации по размерам и форматам изображений для iOS и Android.
• Скриншоты должны наглядно демонстрировать основные функции приложения. Это влияет на первое впечатление пользователей.
• Хорошее описание — не просто рассказ о функциях приложения, но и маркетинговый инструмент. Определите ключевые слова, по которым пользователи найдут вас в поиске.

6 этап — публикация и продвижение

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

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

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

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

Продвижение приложения — всегда несколько стратегий одновременно:

• ASO или App Store Optimization — процесс оптимизации вашего приложения для повышения его видимости в сторе. Сюда входит работа над ключевыми словами, заголовками, описаниями и визуалом карточки приложения.
• Целевые рекламные кампании помогут вам «достучаться» до нужной аудитории. Здесь не пытайтесь провести кампанию самостоятельно, лучше наймите специалиста.
• Важно продвижение в социальных сетях и на отраслевых сайтах, чтобы больше пользователей узнало о вас. Анонсируйте в мероприятия, которые недоступны в приложении: например, конкурс на лучшую историю использования вашего приложения, которую далее вы сможете использовать в маркетинговой стратегии.

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

Если вы мечтаете создать свое мобильное приложение — делимся опытом, инструментами и полезными ресурсами здесь.

1. Kotlin и функциональное программирование: сделайте код лучше
2. Переход с Java на Kotlin при создании мобильного приложения
3. 10 лайфхаков для Android-разработчика: полезные extensions на Kotlin

1. Норман Бейтс («Психо»)

Почему Python?

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

Его путь в IT

Норман начинал как сисадмин в семейном мотеле "Бейтс". Ручное управление серверами быстро ему надоело — ну сколько можно делать одно и то же? Он начал писать скрипты на Python, автоматизируя бэкапы, мониторинг и деплой. Затем подсел на Docker и Kubernetes, завернул всю инфраструктуру в контейнеры и настроил CI/CD пайплайны.

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

Но позже выяснилось, что он сделал это под влиянием своего "второго я", не осознавая последствий.

2. Майкл Майерс («Хэллоуин»)

Почему C?

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

Его путь в IT

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

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

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

3. Пеннивайз («Оно»)

Почему JavaScript?

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

Его путь в IT

Начал с создания веб-сайтов, которые завораживали и одновременно пугали пользователей своей необычностью. Быстро освоил все популярные фреймворки, переключаясь между React и Vue. Решил, что одной клиентской магии мало, и ушел в бэкенд.

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

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

4. Гостфейс («Крик»)

Почему Ruby?

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

Его путь в IT

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

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

5. Кожаное лицо («Техасская резня бензопилой»)

Почему C++?

Кожаное лицо любит работать с железом напрямую. C++ дает ему мощь и гибкость, позволяя писать эффективный код для микроконтроллеров. Он ценит контроль над памятью и возможность выжать максимум из ресурсов. Для него код — это инструмент, как и бензопила, которым он мастерски владеет.

Его путь в IT

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

Коллеги знают: если нужно что-то спаять, запрограммировать и заставить работать — это к нему. Хотя он не особо разговорчив и может показаться грубоватым.

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

6. Акула («Челюсти»)

Почему Go?

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

Ее путь в IT

Начинала с Java, но быстро поняла, что Go лучше подходит для ее целей. Стала экспертом в микросервисной архитектуре, разворачивая кластеры, способные обрабатывать миллионы запросов в секунду. Ее код оптимизирован на все 100%, как и она сама в погоне за добычей.

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

7. Существа из «Тихое место»

Почему Rust?

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

Их путь в IT

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

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

8. Сара Фир («Улица страха»)

Почему Kotlin?

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

Ее путь в IT

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

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

9. Джейсон Вурхиз («Пятница, 13-е»)

Почему Java?

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

Его путь в IT

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

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

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

На конференции МТС Платформа 2024 Инесса Галактионова, первый вице-президент МТС по телекоммуникационному бизнесу, рассказала о подготовке компанией виртуального ассистента, который станет полноценным участником телефонных звонков. Чем он будет отличаться от существующих голосовых ассистентов и почему его невозможно было сделать по принципу «как все», расскажу вам я, CTO стрима «Виртуальный ассистент» компании МТС, Иван Мясников.

Новые подходы нужны для уникальных продуктов

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

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

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

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

Во-первых, отошли от обычной для нас работы через веб-сокет и выбрали gRPC-протокол. Исследование, проведенное нашей командой, показало, что gRPC позволяет выиграть в скорости получения голосового запроса и скорости доставки ответа абоненту. При нагрузочном тестировании мы обнаружили, что такой подход дает нам выигрыш по скорости в два-три раза. Пользователь получает ответ быстрее, а оборудование загружается меньше. Преимущество появилось за счет того, что веб-сокет передает данные в текстовом формате, а gPRC — в бинарном. Вместе с HTTP/2 протокол gPRC позволяет включать мультиплексирование, сжимать передаваемые данные и при необходимости приоритизировать запросы.

Во-вторых, для бэкенда мы выбрали язык Kotlin вместо применяемого обычно Java. У этого решения нашлось несколько важных преимуществ. Из главных — меньший объем кода и лучшая читаемость за счет корутин и более лаконичного синтаксиса. Концепция Null Safety в Kotlin помогает избежать ошибок неопределенности — одних из самых частых и очень трудно выявляемых в Java. В результате оказалось, что применение Kotlin повышает надежность и масштабируемость системы по сравнению с Java при сравнимых трудозатратах.

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

Дело не только в стеке

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

После «ковидной» удаленки мы не стали возвращать всех сотрудников в офис, а перестроили процессы и перешли на асинхронный подход: когда мы пишем запрос в чат или комментарий в задаче, то не ждем мгновенного ответа. Для этой модели важна правильная декомпозиция — в компании должно быть достаточно независимых процессов и задач. Тогда даже если вы получите ответ не сразу, а через день-два, ничего страшного не произойдет: специалист просто переключается на другую часть задачи или меняет «таску». Главное, что в результате ему не приходится ждать или торопить коллег.

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

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

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

Свой подход к работе мы перенесли в наём: сразу рассказывали о процессах, о специфике нашей работы, искали подходящих ребят через вопросы и разбор кейсов на собеседовании. Например: «К вам в 9 утра прибежал коллега с задачей, которую обязательно надо сдать сегодня. Что вы будете делать?»

Наконец, в роли СТО я старался работать с коллегами, которые приходят с горящими задачами, например: «Через неделю демо продуктов, нам надо обязательно участвовать, и мы хотим показать фичи 1, 2 и 3, хотя мы понимаем, что фича 2 не будет готова вовремя, надо повышать приоритет, чтобы успеть». В таких случаях мы выясняем, откуда срочность — действительно ли надо реализовать функцию к ближайшей встрече или имеет смысл сделать ее несколько позже, зато более качественно.

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

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

Что дают инновации разработчику?

Я и вне работы стараюсь следить за развитием технологий, чтобы не терять интерес к программированию. Иногда делаю пет-проекты.

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

Из недавнего и интересного: делаю сервис Personaj, в котором можно общаться с виртуальными личностями — от Эйнштейна до Пикачу. Сейчас аватаров уже больше 100, и база растет (к тому же можно добавить своего). Суть такая: каждый человек после регистрации может предоставить фото, текстовое описание и имя персонажа — допустим, Пушкин. Моделька на основе этих UGC-данных создаст аватара, который будет отвечать, как этот самый Пушкин (с учетом предоставленных данных, конечно). Другой вариант — поговорить с уже готовым Пушкиным, данные о котором мы подгрузили из открытых источников.

Бэкенд у нас на Python, фронт пока на low-code, но скоро переедем на React, который мне всегда нравился. Смотрел и другие варианты, например, порог входа в Angular по необходимым знаниям мне показался выше, и он скорее подходит для больших команд. Так что важно учитывать разные аспекты при выборе стека и подбирать его не только под задачу, но и под имеющуюся команду. Вот примеры работы проекта:

Всегда ли нужны новые технологии?

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

В случае с ассистентом новый стек был необходим, но для системы авторизации МТС ID, которую мы делали для экосистемы, подобного не требовалось. Так что мы взяли многим известный Keycloack, интегрировали и получили качественный продукт (который к тому же оставляет возможности для кастомизации и написания собственных, нестандартных интеграций).

Чтобы понять, что нужно внедрять инновации, пробовать новые технологии в проекте, я советую отталкиваться от следующих критериев:

1. Есть ли у кого-то в команде опыт работы в этом направлении или все будут учиться вместе «с нуля».
2. Есть ли время и ресурсы на исследования и готовы ли вы к тому, что часть идей и гипотез не выстрелит.

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

Сервис получил название Yandex Code Assistant. Его тестирование уже началось на облачной платформе Yandex Cloud.

Хотя доступ к новинке ограничен и требует подачи заявки, Яндекс обещает, что в будущем она станет доступной более широкому кругу разработчиков.

Yandex Code Assistant: российский ответ Microsoft Copilot

Yandex Code Assistant позволяет разработчикам по фрагменту кода автоматически генерировать его продолжение.

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

Яндекс сообщил, что сервис был протестирован тысячами внутренних разработчиков, из которых 60% стали постоянными пользователями.

На данный момент новинка поддерживает генерацию кода на популярных языках, таких как C++, Go, Java, Kotlin и Python. При этом планируется расширение списка поддерживаемых языков до более чем 30.

Удобство использования и эффективность

По словам разработчиков ассистента, одним из ключевых преимуществ Yandex Code Assistant является его скорость.

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

Сервис поддерживает работу с популярными редакторами кода, хотя конкретные названия пока не были раскрыты:

Российские конкуренты

Yandex Code Assistant — это не первая попытка создания российского аналога Copilot.

В 2023 году Сбер также запустил своего ИИ-ассистента GigaCode, а MTS AI представила сервис Kodify для генерации кода.

После закрытия Zenly мы вместе с коллегами Димой Трачуком и Марией Мышь (ранее работала в Zenly), собрались и начали обдумывать создание своего приложения. К нам постепенно присоединились и другие специалисты, и мы продолжили формировать команду.

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

Стоит отметить, что импортозамещение обычно подразумевает создание аналога продукта, который больше не доступен в России. В случае Zenly, это приложение не просто ушло из России — оно полностью прекратило свою деятельность. Поэтому мы не выступаем импортозаместителями в прямом смысле этого слова. Наше приложение — самостоятельное решение, разработанное с нуля.

Какие основные функции и возможности предлагает Blink пользователям? Можем ли мы «бампнуться» по-старинке или отправить смайлик другу на весь экран?

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

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

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

Еще одна интересная особенность Blink — функция «трях», аналогичная «бампу» из Zenly. Теперь, чтобы сообщить друзьям о встрече, достаточно просто потрясти телефонами. Вообще, термин «бамп» в английском языке имеет сексуальный подтекст, поэтому для англоговорящей аудитории звучит так же странно, как «трях» для русскоязычной.

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

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

Помимо Golang, в стек входит ряд других ключевых инструментов. Для обработки потоков данных в режиме реального времени используется Apache Kafka, надежный и производительный брокер, с которым уже была знакома команда разработчиков и DevOps/SRE. Выбор Kafka обусловлен необходимостью надежной маршрутизации гигабайтов геопакетов в секунду.

В качестве основной базы данных выбран PostgreSQL, известный своей надежностью, производительностью и возможностью масштабироваться. Для кэширования данных используется Redis, а ClickHouse – для аналитики и обработки больших объемов данных, в том числе для пост-процессинга геокоординат. На данный момент объем данных в кластере приближается к 30 ТБ, и ClickHouse справляется с этой нагрузкой.

Для мобильных платформ мы используем Swift для iOS и Kotlin для Android.

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

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

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

Все начинается с получения координат от пользователя. Эти данные проходят несколько этапов проверки. Мы анализируем, не произошел ли резкий скачок местоположения, например, перемещение из России в Австралию за короткий промежуток времени. Фильтр Калмана помогает сглаживать координаты, удаляя аномальные значения и улучшая точность.

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

Мы также проверяем, находится ли пользователь в знакомом окружении, например, в домашней сети Wi-Fi. Если данные указывают на аномальное перемещение, корректируем местоположение.

Стоит отметить, что в последнее время мы все чаще сталкиваемся с проблемами навигационных систем и GPS-глушилок. Поэтому разработали целый ряд фильтров и механизмов для обеспечения высокой точности геолокации. Кроме того, работаем над улучшением клиентской части, оптимизируя работу приложения для минимального потребления заряда аккумулятора. Blink в среднем потребляет всего 1% заряда в сутки, что является отличным показателем. Мы потратили много времени на это улучшение, и теперь приложение практически не тратит заряд, хотя работает в фоновом режиме.

Как реализована система хранения и обработки больших объемов геоданных в приложении? Какие технологии и подходы задействованы?

Мы внедрили два ключевых решения: Apache Kafka и ClickHouse.

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

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

Стоит отметить, что объем накопленных нами данных уже превышает 30 терабайт. Это огромный массив информации, который требует применения современных Big Data решений, таких как Kafka и ClickHouse. Благодаря этому мы можем эффективно управлять и анализировать все эти данные, извлекая ценные инсайты и предоставляя полезный сервис нашим пользователям.

А что насчет самих пользователей? Как вы подходите к вопросам безопасности и конфиденциальности данных в Blink? Какие меры предприняты для защиты личной информации?

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

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

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

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

У нас есть два основных направления аналитики: клиентская и серверная.

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

В части серверной аналитики:

• Все события, связанные с действиями пользователей, собираются и отправляются на наш сервер, где хранятся в базе данных ClickHouse. Это касается как клиентских, так и серверных событий.

• Собранные данные затем передаются в BI-системы, такие как Redash и Superset, для визуализации и построения дашбордов.

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

Один из последних кейсов:

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

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

С какими основными трудностями и вызовами вы сталкивались в процессе разработки и масштабирования Blink? Как вы их преодолевали?

Несмотря на стремительный рост, мы столкнулись с несколькими серьезными техническими вызовами:

1. Изначально, с нагрузкой в 10 тысяч онлайн-пользователей, наши го и легковесные горутины, а также оптимизированные веб-фреймворки справлялись с нагрузкой. Однако с ростом аудитории до 100 тысяч возникли проблемы на сетевом уровне, которые нашим инженерам удалось решить за счет переконфигурирования балансеров (nginx + sysctl).
2. Для хранения географических данных мы выбрали PostgreSQL, но со временем объем этих данных превысил 1 ТБ, что привело к существенному падению производительности. Попытки горизонтально масштабировать PostgreSQL оказались малоэффективными, и в итоге мы перешли на Clickhouse, который гораздо лучше справился с этой задачей. Перевод на Clickhouse занял около недели, но куда больше времени потребовалось на миграцию данных из PostgreSQL.
3. Недостаток мониторинга приводил к тому, что о проблемах мы узнавали уже тогда, когда они становились критическими и вызывали простои сервиса. Несколько бессонных ночей наглядно продемонстрировали важность использования инструментов вроде Grafana.

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

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

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

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

Кроме того, мы разрабатываем собственную карту Blink Maps, которая будет интегрирована в приложение уже через несколько месяцев для некоторых устройств на Android. Это наша собственная 3D-карта, позволяющая решить технические ограничения, с которыми мы сталкиваемся при использовании платформенных карт, по типу Google Maps. Например, сможем более эффективно отображать больше пинов без задержек и сбоев. Карта будет регулярно обновляться, что позволит избегать проблем с устаревшей информацией. У нас свой движок, построенный на видеопроцессоре GPU, который на основе данных OpenStreetMap делает магию. Основу мы берем из OSM и поверх накручиваем все свои изменения.

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

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

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

Однако, в свете этих тенденций, стоит учитывать, что Apple и Google, например, продолжают усложнять работу с геолокацией для сторонних разработчиков. Несмотря на наличие встроенных решений, таких как Find My Friends у Apple, ограничения и новые требования для работы с геоданными становятся все более жесткими. Это создает дополнительные вызовы для разработчиков, которые должны адаптироваться к меняющимся условиям и искать альтернативные пути стабильной работы своих приложений.

Анализ API

В Kotlin 2.0 была улучшена поддержка чтения содержимого библиотек (klib) в анализе API. Это обновление значительно упрощает работу с различными библиотеками и их интеграцию в проекты.

Упрощенные инициализаторы

Теперь компилятор может лучше оптимизировать код, использующий std::initializer_list, что сокращает количество вызовов memcpy и улучшает производительность.

Оптимизация контекстного коллектора, хранения и разрешения

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

Были оптимизированы методы getFirForNonKtFileElement и getOnAirGetTowerContextProvider, тем самым время выполнения операций уменьшилось, общая производительность компилятора повысилась.

Разрешение проблем с файловыми структурами

Исправлены проблемы, связанные с кэшированием и обработкой файловых структур, что повысило стабильность работы инструмента анализа API.

Поддержка наследников запечатанных классов

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

Улучшение диагностики

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

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

В видео он рассказал:

1. В чём заключается основные принципы императивного и ориентированного на выражения программирования.
2. Что такое монады и как их использовать.
3. О пользе скоуп функций, функций высшего порядка и композитных функций.
4. Представил Arrow - библиотеку для Kotlin, которая реализует концепции категорной теории и предлагает расширенные возможности для функционального программирования.
5. Продемонстрировал, что важно выборочно использовать монады, так как они могут как улучшить, так и усложнить код.

Ниже — транскрибация ролика на русском языке.

Что ж, моя презентация будет посвящена функциональному программированию и Kotlin. Краткое введение о себе.

Я Урс Питер, сеньор software developer. «Днём» я работаю по специальности. Также являюсь тренером в Академии Xebia, где помогаю разработчикам на всех этапах в Kotlin от новичка до среднего и продвинутого уровня, что довольно интересно, потому что я сталкиваюсь со многими средами и вижу, как Kotlin используется разными способами. Я также сертифицированный тренер Chatbrain. Карьеру я начинал около 20 лет назад с Java, затем около 10 лет назад перешел на Scala, вложил значительные средства в экосистему Scala, также был одним из первых сертифицированных тренеров, написал множество приложений на Scala, создал учебные материалы.

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

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

<...>

Стили программирования

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

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

Как вы видите в этом конкретном примере. Языковая функция, которую мы используем в Kotlin для реализации этого стиля, — это var`s, циклы, множество изменяемых вещей, такие как изменяемые коллекции, изменяемые объекты, операторы return.

Итак, как только мы достигли определенного этапа, мы думаем: хорошо, теперь все достаточно хорошо. Это императивное программирование.

Напротив, у вас есть вторая категория, которая является программированием, ориентированным на выражения (Expression-Oriented Programming). Это еще не функциональное программирование, но оно лежит в его основе. И программирование, ориентированное на выражения, больше опирается на мышление функциями с точки зрения ввода и вывода. Функции, которые мы используем, — это более неизменяемые функции Kotlin, такие как классы данных, неизменяемые коллекции.

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

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

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

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

Поскольку у нас есть ввод-вывод, мы также более детерминированы, верно? Потому что мы получаем выходные данные, а когда у вас есть выходные данные, нам легче их протестировать. И что также интересно отметить, так это то, что при программировании, ориентированном на выражения, наши блоки области видимости (scope blocks) меньше, чем при императивном стиле.

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

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

Функции области видимости (scope functions)

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

В конечном итоге мы извлекаем данные с помощью этих REST-клиентов, которые затем выводим в какой-нибудь CSV-файл, и в конце концов закрываем наш ресурс. И поскольку эти API изменяемы, вы можете подумать «хорошо, единственный способ, которым я могу решить эту проблему, — это объявления переменных, а затем попутно менять их». Ну, это не совсем так.

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

Прежде всего, теперь с помощью apply мы группируем все операции, которые ...вызывают изменения в нашем объекте. Таким образом, он, по крайней мере, изолирован. Мы изолируем нашу изменчивую часть. С помощью let мы можем опустить оператор getAll и return. Кроме того, это приятно, потому что теперь мы четко отмечаем побочный эффект.

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

Функции высшего порядка (higher-order functions)

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

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

Вот как мы могли бы решить эту проблему, верно?

Что, конечно, довольно глупо. Мы просто продублировали все это, изменили наши выходные данные на TSV и создали проблему с ремонтопригодностью. Итак, как вы можете лучше решить ее?

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

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

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

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

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

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

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

Композитные функции (composable functions)

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

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

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

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

Теория категорий

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

И третья категория — это нечто похожее, но с логическими строительными блоками, которые вы можете комбинировать, пока не получите определенные характеристики. И, как вы можете видеть, это не высота, не холм, это гора. А в горах можно подняться очень высоко, но можно и упасть очень глубоко. Итак, это опасная зона, где внезапно появляются все эти модные слова. Ну, а почему это опасная зона?

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

<...>

Контейнеры

Хорошо, итак, когда я спросил в начале, кто слышал слово «монада», поднялось довольно много рук, но определенно не все, верно? Приятно то, что мы все используем монады, и даже на ежедневной основе.

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

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

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

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

Но ладно, пока давайте просто придерживаться термина “монада” (я бы предпочел термин "комбинируемый"; тогда я бы вроде как понял, о да, вы комбинируете разные вещи).

Итак, это первая характеристика. Вторая заключается в том, что вы можете преобразовывать элементы коллекции. У нас снова есть контейнер, содержащий элементы. Мы берем каждый элемент, применяем к нему определенную функцию, результатом чего затем будет новый контейнер с преобразованными элементами. И если у вас есть такая возможность, то объектам удается вызвать это функтором. Итак, когда у чего-то есть метод map, это функтор. «Сопоставимый» (mappable) для меня звучало бы более логичным.

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

Итак, что я должен применить? Вот тут-то и появляется flatMap, так что же делает flatMap? Каждый элемент, который вы извлекаете из контейнера, снова преобразуется в контейнер, но результирующий контейнер как бы выравнивает (убирает) дополнительный контейнер, который мы добавили.

Все в порядке, вы получаете только один список с элементами. И если вы затем объедините характеристики, которые мы видели раньше, то есть моноид и функтор, в сочетании с flatMap, то та-да, вот и наша монада. Итак, я сказал, что монада — это комбинация моноида, который я сейчас называю комбинируемым, функтора, отображаемого аспекта и монады, я бы предпочел термин «компонуемый», потому что это то, что вы можете делать с этими вещами. Хорошая ли идея дать этому новую терминологию?

Честно говоря, я думаю, что это плохая идея. Поэтому я думаю, забудьте об этом, придерживайтесь моноидной строки и так далее. Но, ну, определенно, не помогло то, что они использовали такого рода терминологию. И также здесь, на самом деле, больше уровней абстракции. Моноид идёт от «применимый» (applicative) и так далее. Есть также небольшие нюансы, но пока давайте просто придерживаться этих трех. Итак, мы все знаем монады, верно?

Монады (Monads)

Потому что вы используете коллекции. И я уверен, что вы знаете больше монад. Например, optional. Что такое optional?

Если вы попытаетесь определить, что делает монада, есть какое-то особое житейское определение, которое вы можете применить к ней. Которое выглядит следующим образом: «Опциональность моделирует эффект опциональности» («an optional models the effect of optionality»). Итак, эффект опциональности.

Это очень важная часть, и мы также увидим позже, что это слово будет повторяться. Итак, давайте посмотрим, является ли опциональный параметр монадой? Давайте проверим. Есть ли у нас пустой метод? Мы можем создать пустой опциональный параметр, который является числом, верно? Можем ли мы сопоставить наши значения?

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

Отличается от коллекции, но это все равно map с другим эффектом, то же самое верно и для flatMap, поэтому, если на flatMap я создам наши опции, я не получу опциональный набор опций (option of optionals), потому что один слой будет выровнен… Кто занимался Reactive программированием с фьючерсами, всеми этими абстракциями? Да, хорошо, круто, довольно много. Там тоже есть монады.

Что они делают? Ну, моноблок или реактивный блок моделирует эффект синхронности. Можем ли мы создать пустой?

Можем. Итак, как здесь появляется map? Что делает map? Здесь у нас есть некоторый API, который возвращает моноид (mono), и map в основном будет вызван, как только асинхронная обработка будет завершена, и мы получим значение «окей». Здесь вызывается map.

То же самое верно и для flatMap, поэтому, если я хочу последовательно вызывать реактивный блок, то есть сначала API 1, затем API 2, я должен использовать flatMap, потому что в противном случае я получил бы моноид из моноида. Итак, вы также видите здесь, что эффект map и flatMap полностью отличается от других монад, которые мы видели до сих пор, но это все равно map и flatMap.

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

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

Ну, если мы хотим что-то скомпоновать, тогда нам нужна монада, и хорошей новостью является то, что в стандартной библиотеке Kotlin уже есть такая монада, которая называется result и выглядит результат. Result моделирует эффект наличия значения «окей» или исключения, и мы можем применить результат выглядит следующим образом: у него есть map и flatMap, так что, по-видимому, это монада. Это был код раньше, теперь мы используем runСatching в клиентском коде, который затем не вернет нашему разработчику результат либо хорошего значения, либо исключения, и с этого момента мы можем начать компоновать. Это довольно хороший вопрос, не так ли? Итак, у нас есть этот клиент GetDevByName. Откуда мы знаем, что можем ожидать исключения? Этого нет в подписи. Контракт не говорит мне, что есть исключение. И это очень интересная дискуссия, которая, в некотором смысле, то, что мы здесь видим, не является прозрачным.

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

Напротив, довольно интересно, что в Kotlin есть только непроверямые (unchecked, те, которые не отлавливаются компилятором — прим.переводчика) исключения. Так что, по-видимому, есть некоторые, да, и это немного не согласовано. Не будет рассуждать, хорошо это или плохо. Так что давайте просто продолжим исследование, и я думаю, тогда мы сами придем к выводу. Предположим, что мы хотим быть прозрачными. А если мы хотим быть прозрачными, тогда мы должны быть откровенны. Итак, мы должны четко отметить, что этот метод также может выдать вам исключение посредством результата. И что ж, это то, что мы должны сделать. Таким образом, все наши методы теперь относятся не к языку как к возвращаемому термину, а к результату языка. Тогда мы можем творить нашу композиционную магию. Хорошо, давайте расширим наш пример и используем третий вызов API.

И если мы попытаемся вызвать эти три API последовательно, сначала один, используя выходные данные в качестве входных данных, то в итоге мы получим вот такой код. Таким образом, задействовано много flatMaping. В начале я сказал, что бываю во многих местах, где обучаю разработчиков Kotlin, но объяснять это, особенно тому, у кого очень сильный опыт работы с императивами, довольно сложно. Я имею в виду, что коллекции плоских отображений уже немного сложно. Но контекст flatMaping отличается от контекста других структур? Я имею в виду, это не так уж сложно, но все равно, ощущения не очень приятные.

Итак, вопрос, конечно, в том, есть ли способ лучше? Я думаю, сейчас тот момент, когда я представляю вам Arrow.

Что такое Arrow? Arrow — это действительно красиво созданный API, который фактически реализует всю эту теорию, категорию, парадигму, а также предлагает большое разнообразие монад. Я действительно считаю это жемчужиной, что не всегда было так, потому что вначале это был порт из Scala. В Scala есть этот материал в большем количестве, довольно много библиотек доходят до крайности с такого рода концепциями, и они были перенесены на Kotlin. Самая первая версия была как бы не связана с идиоматическим Kotlin. У вас был Kotlin, а затем у вас был этот функциональный мир, и вам действительно приходилось выбирать между одним и другим.

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

Эффект — это основная вещь, и затем у вас есть монады, которые реализуют определенный эффект, например опциональный. Результат также преобразуется в эффект. У вас также есть either, вы, возможно, слышали об этом типе, either немного мощнее, чем result. Result может содержать только хорошее значение и исключение. Either просто может содержать два значения, может содержать одно значение разной формы. Таким образом, он может иметь значение типа A или значение типа B, и только по одному за раз.

Обычно правое ассоциируется с хорошим результатом, а левое — с плохим, но это не обязательно так, но часто это применяется именно таким образом. Есть validated, где вы можете выполнить некоторую накопленную проверку <...>. Хорошо, что Arrow также предлагает очень классную функцию, которая называется monad comprehensions. С ней мы можем работать лучше, чем с помощью flatMap.

Monad comprehensions

Как это работает? Что важно упомянуть, так это то, что монопонимание — это нечто из функциональных языков, а у функциональных языков для этого есть языковые особенности. В Kotlin нет языковой функции для монокомпонентов, но в Kotlin есть эта функция, литерал которой связан с receiver, верно? Это то, что вы видите здесь, result, и тогда receiver в этом случае будет такой областью действия result, которая для вас как бы скрыта. Но у этого есть некоторые методы расширения, которые являются bind, и этот метод bind затем может вызывать монады внутри вашего блока кода. Итак, здесь вызов bind и то, что делает bind, — это либо дает вам значение, если вы вычисляете правильное значение, и если это было бы исключением, оно просто провалилось бы и просто вернуло результат, содержащий исключение.

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

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

Итак, давайте просто используем все, что можем. И поскольку мой вариант использования требует только более одной монады, почему бы просто не объединить эти вещи вместе? Потому что мне, во-первых, нужно какое-то реактивное поведение. Во-вторых, я хочу, чтобы код был прозрачным. И в-третьих, почему бы не использовать option?

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

Проблемы...

И вы можете себе представить, что теперь мы только что ввели небольшую головную боль при обслуживании. Итак, все map и flatMap, которые мы видим здесь, вызываются одинаково, но я сказал, что эффект на самом деле разный. FlatMap монад отличается от map из result, отличается от map из optional, но это все map и flatMap. Это то, что вы видите.

Так что все не так уж и здорово. Ну да, вы еще не занимались бизнес-логикой, и если вы обнаружите, что пишете такой код, тогда я могу поздравить вас, потому что вам удалось превратить свою кодовую базу в контейнерный терминал, и если вы внимательно посмотрите, где вы находитесь, то это здесь, у этого крана, и вы просто перемещаетесь вокруг этих контейнеров и пытаетесь найти [что-то], заворачивайте и разворачивайте их, чтобы добраться до того, что вам нужно. Потому что в основном мы программируем обеспечение, которое создаем, что действительно интересно — это то, что находится внутри контейнеров, а не сам контейнер. И это именно то, что у меня много раз было со Scala, и я действительно знаю, что у многих других было то же самое, что… Это очень неприятное чувство в том смысле, что я хочу создать бизнес-логику для выполнения моих вариантов использования, но я всегда борюсь только с упаковкой, распаковкой, заглядыванием в эти контейнеры. Итак, мы только что видели, что у вас есть эти представления о монадах, возможно, они и здесь могут помочь.

... и их решение

Извините, плохие новости. Понимание монад работает только для одного уровня монады. Так что, если у вас есть вложенные монады, это не сработает. Как насчет трансформаторов монад? Что такое трансформаторы монад? Это снова своего рода грязный трюк для преобразования значения внутренней монады во внешнюю. Итак, вместо того, чтобы вызывать map, flatMap, теперь вы можете вызвать mapT. И тогда вы преобразовали бы комбинацию mono result напрямую в convert result. Ну, это работает только для двух уровней.

У нас их три, верно? И вы все равно не можете использовать для этого что-то более всеобъемлющее. И поверьте мне, если вы пойдете по этому пути, то получите такого рода методы: mapТ, mapТ, mapТ, внешняя flatMap, внутренняя. Я написал такой код.

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

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

Так что настоятельно рекомендую обратить на них внимание. Итак, мы преобразуем их в spend и можем выбросить наш mono. Второй, ну, вариант. Я думаю, у нас уже есть эта конструкция в Kotlin, верно, которая является nullability. Зачем вводить другой тип конструкции для использования возможности обнуления? Вы же не собираетесь использовать необязательный параметр Java в своем коде, верно?

Во всяком случае я не советую вам так делать. Просто придерживайтесь одной концепции опциональности, которая в Kotlin ещё и nullability, и все. Хорошо, и как только мы это сделаем, я думаю, наш код снова станет в некотором роде управляемым. И если вы используете let или если вы затем используете другие гласные, которым вы присваиваете свои результаты, это зависит от вас. Но тогда с пониманием результата, комбинацией с методами привязки и приостановки, возможностью обнуления лучше подойдёт. Ладно, я думаю, теперь мы прошли через этот монадический туман, просто взглянули на вершину.

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

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

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

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

Нет. Что вы делаете, так это в контроллерегенерируем исключение, чтобы наш обработчик исключений мог обработать его и вернуть ответ REST. Возможно, это могло бы вернуть результат в нашем контроллере. Да, мы могли бы заставить это работать, но мы ничего с этим не делаем. Итак, что ж, если в 95% случаев вы все равно их не используете, я обнаружил, что, обратившись к Scala, где мы действительно довели это до крайности, это просто работает лучше.

И да, это не совсем чистый метод, но он работает лучше. И, конечно, у вас есть остальные 5%. Я думаю, это интересный случай. Итак, мы рассмотрим наши примеры, которые у нас есть.

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

И здесь действительно имеет смысл быть откровенным. Итак, в зависимости от того, что мы получаем , и мы могли бы использовать хороший floor или eternity flow, так что это означает , что для работы с базой данных я бы действительно не стал оборачивать это в монады, просто верните ему сущности, достаточно хороший API сказал, что в зависимости от того, что вы хотите сделать, я бы не стал использовать result кстати, я бы предпочел использовать либо потому что результат в случае, если у вас есть исключения, вам нужно было бы как бы извлечь исключения, чтобы внедрить их в свой бизнес-процесс для принятия других решений, которые в исключительных случаях не принимаются, верно? Поток управления, основанный на исключениях, немного противоречит шаблону. Но с помощью IDER мы можем просто определить тип ошибки, который может быть закрытым интерфейсом с некоторыми классами данных, и тогда мы сможем довольно легко обработать левую часть нашего IDER. Таким образом, поступая таким образом, мы получаем два преимущества.

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

Итак, два примера, прежде чем мы подведем итог. Вот, например, проблема, с которой я тоже сталкиваюсь довольно часто. Чтобы создать какие-то объекты, вы должны проверить их на возможность nullability.

Для различных переменных, прежде чем вы передадите их, в противном случае вы не сможете создать такую переменную Kotlin, потому что значения, которые она принимает, не являются null, это довольно утомительно, также здесь у Arrow есть отличная функция, которая заключается в понимании монады с нулевым значением, поэтому в Arrow типы с нулевым значением также считаются монадой, так что вы можете используйте это понимание, а затем вместо использования if-else просто использовать bind, и если одно из этих значений вернет null, то, что ж, весь результат будет null. Итак, я думаю, что это отличное дополнение к вашему коду, позволяющее предотвратить множество конструкций if-else. Еще одна прекрасная вещь — это решение этой конкретной проблемы.

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

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

[42:54] Вам также нужно аннотировать свои классы. Но это определенно стоит хлопот, если вы делаете это много раз в своем домене. Это действительно того стоит. Хорошо, итак, я сказал, что как только мы сможем не использовать монады в качестве золотого молотка, бросать его во все подряд, чтобы все наши цепочки вызовов были как бы загрязнены монадами, я думаю, что именно здесь мы достигли пользы функционального здравого смысла. Итак, где вы можете выбрать лучшее и просто пропустить остальное.

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

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Какие библиотеки, инструменты, фреймворки Android уже устарели?

Андроид развивается очень динамично, поэтому, многое из того, что было популярно 5 лет назад уже не используется. Конечно же сразу приходит на ум RxJava, про нее был каждый второй доклад на любой конференции 5-6 лет назад. А теперь ее изредка спрашивают на собеседованиях. На замену ей пришли Kotlin Coroutines.

Java как язык разработки под андроид остался, наверное, только в каких-то старых проектах динозаврах. Kotlin это новый стандарт уже лет 6.

С появлением Jetpack Compose UI код использующий стандартные Android Views стал легаси. Многие приложения сейчас Compose First, и все новые фичи тоже разрабатываются на Compose.

Архитектура презентационного слоя так же изменилась, всё меньше можно увидеть MVP, а MVVP и MVI стали де факто стандартами разработки.

Какие библиотеки Android нужно знать в 2024 году?

Если мы возьмем более менее стандартное приложение со стандартными подходами, то наверняка там будут эти библиотеки: Retrofit 2, Dagger2/Hilt, Kotlin Coroutines, Jetpack ViewModel, Room, Lifecycle. Но стоит помнить, что библиотеки приходят и уходят, а фундаментальные знания остаются. Человеку, освоившему фундамент будет гораздо легче освоить какую-либо библиотеку.

Какие фреймворки Android нужно знать в 2024 году?

В Андроид немного фреймворков, наверное главный и самый нашумевший в последнее время это Jetpack Compose. Так же стоит знать архитектурные подходы MVI/MVVM, MVP, плюсы и минусы их работы. Так же неплохо было бы понимать базовые вещи, которые могут не относится только к Android, например SOLID, Dependency Injection.

Какие инструменты Android нужно знать в 2024 году?

Швейцарский нож Android разработчика в 2024 это Kotlin, Kotlin Coroutines, Jetpack Compose, MVVM/MVI, Google Jetpack Libraries, REST, Single Activity, Dagger 2, Retrofit 2. Зная этот стек можно будет легко разобраться в 95% приложений.

Что уже устарело

Язык разработки Java для Android

Современный подход к разработке под Android является Kotlin-first. Это означает, что Kotlin является основным языком для разработки приложений. Также уже несколько лет все нативные библиотеки для самых различных целей и задач пишутся преимущественно на Kotlin. Поэтому будет полезнее направить усилия по изучению данного языка вместо Java. Java вы всегда успеете выучить при необходимости, чтобы лучше понимать подкапотный мир JVM, общий с Kotlin.

Расхожее мнение, что с появлением Jetpack Compose учить разработку View на Xml становится неактуально. Тут все неоднозначно. Несмотря на нарастающую популярность Compose, все еще много проектов, где UI реализуется преимущественно на классическом подходе (View + Xml), а переезд на новую технологию по каким-то причинам не так приоритетен.

RxJava

Использование реактивного подхода было весьма популярно еще буквально несколько лет назад. С помощью фреймворков типа RxJava решали вопрос и компактности кода, и реализации асинхронной разработки. Сейчас фокус сместился в сторону Kotlin Coroutines. Это является актуальным и рекомендованным решением для многопоточной разработки.

Также к устаревшим технологиям относятся DataBinding для связи верстки и бизнес-логики, KAPT для обработки аннотаций. Редко уже используется SqLite ORM.

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

Какие библиотеки нужно знать в 2024 году

Must-havе любого разработчика Android - это семейство библиотек Jetpack Components:

• ViewModels (это не только ViewModels для MVVM, но и в целом рекомендованный компонент для вызова бизнес-логики и хранения состояния),
• Lifecycle,
• Navigation
• Room ORM (для локального хранилища).

Для сети продолжает оставаться актуальным использование Retrofit. В качестве альтернативы можно порекомендовать Ktor.

Очень полезным будет знание Kotlin Coroutines, Kotlin Flows. Для организации фоновой работы будет полезно знание такого механизма как WorkManager.

Для построения корректной архитектуры приложения необходимо знание 1-2 библиотек для Dependency Injection. Актуальным будет знание Dagger/Hilt, дополнительно можно освоить Koin и Kodein.

Какие фреймворки нужно знать

Конечно, Android SDK и Jetpack Compose. С первым все понятно - это база по Android. Декларативные подходе к разработке приложений в принципе актуальны последние несколько лет, т.к упрощают и ускоряют процесс. После выхода первой стабильной версии Compose, несмотря на необходимость доработок, компания Google сделала ставку на данную технологию. Практически все туториалы и гайды по работе с UI ориентированы теперь и на Compose. Какие-то решения уже идут Compose-First. Например, Google добавили в фреймворку поддержку различных классных анимаций.

Философия Jetpack Compose - это не только UI, но и управление состоянием приложения, связь элементов с бизнес-логикой, поддержка навигации и т.п

Какие инструменты нужно знать

Основным инструментом разработки под Android является Android Studio. Это доступная и бесплатная среда разработки, которую можно установить на любую операционную систему. Помимо тулинга для разработки, дебага и сборки приложения, IDE содержит инструменты для профилировки приложения. Очень важно знать Gradle как систему управления зависимостями и сборкой приложения.

Эрудированному разработчику Android в 2024 году полезно знать набор Jetpack Components, Jetpack Compose, Kotlin Coroutines, Retrofit, Dagger/Hilt. Обязательно владение Android SDK и Kotlin, знание паттернов и архитектур, понимание принципов SOLID и ООП.

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

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

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

Использование платформы G2 позволяет:

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

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

Платформа G2 включена в реестр российского ПО, в этом году планируется выпустить продукт на рынок.

Сейчас перед всеми крупными компаниями стоит глобальная задача – перевести ключевые процессы на российское ПО. Мы решили пойти по пути создания собственной платформы, которая позволяет быстро собирать новые системы из готовых элементов. При разработке G2 мы учли недостатки других платформ и постарались их исправить в нашем продукте. У нас получился удобный и эффективный инструмент для разработчиков, который мы готовы предложить рынку. Решение могут использовать любые организации: корпорации и другие предприятия, финансовые организации, ИТ интеграторы и разработчики ПО, чтобы обеспечить безопасность и независимость своих ИТ-систем.

Подробнее, что же будет популярно в 2024 году, на какие технологии стоит делать ставку, расскажет Анна Жаркова, руководитель группы разработки компании Usetech, мобильный разработчик с опытом более 10 лет, эксперт Mobile Broadcast и Skillbox, а также член программных комитетов Mobius, Codefest и DevFest (Омск).

Искусственный интеллект

Начнем мы с самого популярного и многообещающего направления, а именно с использования систем Искусственного Интеллекта. McKinsey Global Institute пишут о возможном увеличении прибыли компаний на $4,4 триллиона в год благодаря ИИ. Кроме того, бизнес чаще начинает внедрять генеративный ИИ в повседневные приложения.

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

С конца 2022 года отмечается настоящий всплеск по разработке систем ИИ. На данный момент нейросеть ChatGPT занимает первую строчку в рейтинге технологий генеративного ИИ. В российском сегменте нельзя не отметить мощный аналог от компании Яндекс Yandex GPT. Компании планируют активно встраивать решения на основе нейросетей в свои приложения. Это может быть не только сбор и обработка информации для улучшения пользовательского опыта. Например, сбор и анализ информации позволит строить модели поведения пользователей, сценарии, на основе которых улучшать подбор рекомендуемого контента и т.п. Также это решение различных генеративных задач. Например, автоматический перевод текста, умное взаимодействие с пользователем.

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

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

Технологии кроссплатформенной мобильной разработки под несколько платформ одновременно популярны уже довольно давно. На текущий момент самыми используемыми являются SDK Kotlin Multiplatform (KMP) от JetBrains и Flutter от Google. Оба решения активно развиваются, и без сомнения, в 2024 году порадуют новыми решениями. Кстати, JetBrains проводит ежегодный опрос по использованию Kotlin, который доступен по ссылке.

Осенью 2023 года произошло то, чего ждали многие разработчики и почитатели технологии KMP. Технология перешла в статус Stable и стала полностью готова к полноценному использованию. Это означает, что многие, актуальные для Alfa и Beta версий SDK проблемы, были решены. Например, улучшили поддержку Kotlin/Native, работу с многопоточностью, памятью и т.п. Одной из целей роадмапа на 2024 год сформулировали реализацию прямого взаимодействия между языками Kotlin и Swift. Несмотря на то, что разработчики Google являются авторами конкурирующего продукта Flutter, компания официально делает большую ставку на KMP. Поддержка кросс-платформы включается во многие решения. Так что советуем присмотреться к данному продукту.

Еще одним трендом связанным с кроссплатформенной разработкой является использование Compose Multiplatform для реализации кросс-платформенного UI. Данный декларативный фреймворк объединяет такие технологии как Compose for Desktop, Compose iOS, Compose for Web, а также Jetpack Compose для Android, и позволяет быстро и относительно просто создавать общий UI для разных платформ. В 2023 году вышла альфа-версия Compose для iOS. В 2024 году ожидается выход Бета-версии, в которую войдут улучшения по работе с нативным UI iOS, а также поддержка кросс-платформенного решения для навигации.

В общемировых тенденциях мобильной разработки сохраняется популярность таких решений, как React Native, гибридной разработки на Cordova и ionic, а также Xamarin. Также сохраняется тренд на PWA разработку,

Российская разработка, импортозамещение

Еще в 2022 году возникла потребность в собственных решениях для импортозамещения, а также развития отечественных технологий. Одним из самых актуальных направлений мобильной разработки становится разработка под Aurora OS. Если сначала попробовать устройства под ее управлением могли в основном участники специальной бета-программы и энтузиасты, помогающие компании OMP в разработке и улучшении продукта, то уже осенью 2023 года смартфоны и планшеты на Aurora OS становятся доступны для приобретения для всех желающих. Готовится к выходу 5 версия OS с поддержкой встроенного магазин приложений на RuStore. Многие российские компании уже работают над своими собственными решениями с поддержкой Aurora OS.

Компания OMP также обновили и улучшили инструменты для разработчиков. Предлагается использовать не только QT/QML/C++, но и специальную версию Flutter для разработки под Aurora. Так что здесь стоит отметить сочетание двух трендов мобильной разработки.

Определенно, стоит уделить внимание платформе Rosa Mobile. Данная ОС была заявлена как замена Android, и освоить разработку приложений под нее, было бы весьма нелишним.

Также актуальным трендом остается переход на отечественные сервисы. Например, решения от Yandex для сбора метрик, карты, погода и другие SDK. Замена сервисов Firebase сервисами RuStore (те же пуш-уведомления).

Нативная разработка

Технологии и фреймворки меняются, нативная разработка остается. Это основа основ, база, которую должен знать каждый разработчик. Использование родных языков и инструментов, как и подхода Native First, будет актуально всегда. К тому же для реализации проектов со сложной логикой, сложным UI, стоит выбирать именно нативную разработку.

Ежегодно разработчики платформ iOS/Android, а также языков Swift и Kotlin, выпускают много новых и интересных решений, про которые рассказывают на тематических конференциях WWDC и Google I/O.

Особое внимание стоит уделить усиливающемуся тренду на декларативную разработку в мобильных приложениях. Фреймворки SwiftUI и Jetpack Compose активно развиваются, стабильно улучшаются, становятся более удобными и надежными в работе. Их все чаще используют в разработке приложений различной сложности. Много библиотек и готовых решений, заточенных под SwiftUI и Jetpack Compose. Можно сказать, что это новый стандарт мобильной разработки под Android и iOS.

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

Виртуальная реальность

В 2023 году на конференции WWDC компания Apple представила одну из самых громких новинок — очки виртуальной реальности Vision Pro, работающие на платформе VisionOS. Разумеется, это далеко не самый первый такой девайс в мире, и подобные аппараты уже давно используются в игровой индустрии. Ставка делается на уникальные технологии иммерсивности, улучшенное качество звука и изображения. В рамках создания девайса были проведены масштабные разработки в области пространственных вычислений. Поддержка VisionOS была включена в такие инструменты, как: ARKit, RealityKit, Unity, RealityComposer и т.п. И инструментарий, и документация на данный момент доступны для всех заинтересованных разработчиков. Старт продаж самого устройства намечен на 2024-2025 год.

Недавно создатели Vision Pro сообщили о скором запуске магазина приложений для очков виртуальной реальности. А это значит, что в 2024 году нас ждет бум различных приложений для AR/VR устройств: игры, виртуальные примерочные, приложения для подбора интерьера, иммерсивный просмотр фильмов, прослушивание музыки и т.п. Кроме того, согласно Statista, к 2028 году число пользователей рынка AR и VR в мире достигнет 3674,0 млн пользователей.

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

Не только смартфоны. IoT

Каждый год выпускаются новые различные устройства под управлением ОС Android, iOS. Это не только смартфоны и планшеты, но и часы, смарт-телевизоры, игровые приставки, фитнес-трекеры, компьютеры автомобилей, а также устройства системы “умный дом”. Компании-разработчики ОС заинтересованы не только в поддержке новых возможностей устройств и гаджетов, но и улучшении инструментария для сторонних разработчиков.

Использование NFC, Bluetooth в приложениях по-прежнему остается актуальным. Yahoo Finance прогнозирует рост в области NFC с 2023 по 2030 годы на 33,1 миллиарда долларов США.

Безопасность, улучшенная работа с сетью

Сохранение конфиденциальных сведений было и остается одной из главных задач разработчиков. Об этом свидетельствует прогноз Gartner. Внедрение усиленных мер безопасности (аутентификация по биометрии, использование блокчейн и т.п) весьма актуальны и в 2024 году. Также особое внимание следует уделять стабильной и безопасной работе с сетью, в том числе и работе с облачными сервисами, с NFC, при подключении к другим устройствам. Современные мобильные ОС предлагают широкий спектр нативных средств для реализации и поддержки безопасной работы приложений.

Подведем итог

В 2024 мобильные платформы, языки и инструменты разработки продолжат свое развитие. Основными направлениями, на которые мы рекомендуем обратить внимание, будут являться:

• нативная разработка;
• кроссплатформа;
• разработка под различные мобильные устройства, IoT;
• поддержка и использование российских технологий;
• безопасность, работы с сетью;
• AR/VR.

Результаты четвёртого раунда можно посмотреть здесь.

Сегодня за звание лучшего языка соревнуются:

• Swift и Python;
• Kotlin и Golang.

Голосование продлится до завтра, 24 декабря 2023 года, до 11 часов по МСК.

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

Со всеми условиями батла можно ознакомиться в анонсе.

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

Мы уже проводили батл в прошлых 2020, 2021 и 2022 годах: первые два раза в голосовании победил Python, а в прошлом году — C#.

Вот, кто поборется за звание лучшего языка в 2023 году:

Правила батла остаются прежними:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 19 декабря, финал — 26 декабря.

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

1. Первый раунд
2. Второй раунд
3. Третий раунд
4. Четвёртый раунд
5. Пятый раунд
6. Шестой раунд
7. Полуфинал
8. Финал
9. Результаты

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

Старт уже завтра — 19 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

Что за библиотека такая

Изначально задачей библиотеки была строгая типизация работы с Telegram Bots API. Так уж вышло, что со временем это переросло в нечто большее, теперь это — мультиплатформенная библиотека с поддержкой WebApp в JS таргете и кучей разных DSL.

О зарождении

По счастливому стечению обстоятельств, на момент начинания библиотеки я уже имел опыт публикации JVM-библиотек, работы с Kotlin и работы с Telegram Bots API. Понятное дело, что тогда (около пяти лет назад) уже были какие-то решения для этих задач, но:

• Как минимум, бОльшая часть была написана на Java для JVM — ни о какой null-safety и других фишках Kotlin не шло речи.
• Ни одна из изученных мной библиотек не обладала хотя бы намёком на какую-то безопасность при работе — поля запросто могли отсутствовать, а методы не применяться.
• Тогда еще не так популярны были всякие DSL + поскольку библиотеки были на JVM, очень много чего скрывалось в документации или в лучшем случае в JavaDoc’ах

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

Трудности по-пути

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

Также, каждая итерация поддержки Telegram Bots API вносила свои приколы: например, форумы — это просто группы с галочкой форумов, у которых для сообщений есть поле threadId. Само собой, каждое обновление заставляло перелопачивать иерархию типов, что иногда приводило к болючим изменениям. Цена прогресса, так сказать 🙂

Из забавностей, в одном из обновлений ребята из команды Telegram толи вывалили наружу, толи подглядели в либу и почти скопировали какую-то иерархию типов (кажется, для прав) — это было очень интересно видеть почти 1-в-1 названия для типов и их отношения друг к другу в официальном API и моей либе 😀

Сообщество

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

К чему я (мы) пришел

Я начинал работу над библиотекой один. Со временем приходили люди и привносили идеи. Так появилось много всего:

• удобный API, вроде как дублирующий методы в оригинальном API, но на самом деле также разделённый по типам и строго декларирующий, какие параметры с какими можно сочетать;
• различные DSL вроде Keyboards DSL и Text Entities DSL;
• некоторые библиотеки вокруг: PlaguBot для унификации частей ботов (плагинов), различные FSM и BehaviorBuilder.

Вместо выводов

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

Спасибо за внимание 🙂

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

Языки для программирования браузерных игр

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

Примеры браузерных игр

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

Языки для программирования мобильных игр

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

Но в этом есть и плюс — простота разработки. Можно использовать один из движков (например, Unity) и за несколько недель собрать свою игру, добавив только спрайты и модели и прописав логику на одном из поддерживаемых языков программирования (для Unity это C#).

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

Тогда для геймдева понадобятся следующие языки:

● Java

Язык для разработки нативных мобильных игр под платформу Android. Программы обычно преобразуются в байт-код, который выполняется на любой виртуальной машине Java (JVM), независимо от характеристик процессора. Для Java также разработаны библиотеки и фреймворки, которые помогают в создании игр, например LibGDX.

● Kotlin

Ещё один язык для геймдева на Java, который появился не так давно. Он полностью совместим с Java, поэтому эти языки можно использовать в проекте одновременно или быстро переписать код с одного на другой. С помощью SDK Kotlin Multiplatform Mobile на этом языке можно создавать кроссплатформенные игры для iOS и Android.

● Objective-C и Swift

Objective-C — первый язык программирования приложений и игр для устройств Apple. Он был создан в 80-х годах XX века как объектно-ориентированное расширение языка C.

Objective-C активно использовался Apple на протяжении многих лет, но всё же с годами его синтаксис и другие особенности устарели. Поэтому в 2014 году в компании создали новый язык программирования Swift. Он имеет более современный и интуитивно понятный синтаксис, обеспечивает статическую типизацию и автоматическое управление памятью, что помогает устранить некоторые ошибки Objective-C и упростить отладку.

Примеры мобильных игр

Коммерческие движки и языки программирования

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

Unity

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

Unity легко освоить даже новичку в геймдеве, но для создания сценариев взаимодействия с сервером понадобится знание C#. Это объектно-ориентированный язык, созданный компанией Microsoft в 2000 году для работы с платформой .NET. Он не такой сложный, как C++, и на нём не нужно писать много шаблонного кода, как на Java.

Примеры игр, созданных на Unity

Unreal Engine

Движок от известной игровой компании Epic Games, выпущенный в 1998 году. Уже больше двух десятков лет его используют в геймдеве для создания сложных игр категории AAA разных жанров — от MMORPG до шутеров от первого лица.

Unreal Engine ценят за шикарные визуальные эффекты, но освоить этот движок сложнее, чем Unity. Для создания сценариев в нём используется C++, правда с определёнными отличиями (без низкоуровневого управления памятью и библиотеки шаблонов).

Это довольно старый и сложный язык, но благодаря визуальному редактору Blueprints создавать скрипты и размещать объекты в Unreal Engine можно и без C++.

Примеры игр, созданных на Unreal Engine

Итоги

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

1. для браузерных игр понадобится знание JavaScript и PHP;
2. мобильных — Java, Kotlin и Swift;
3. консольных и ПК-игр — C++ и C#, а ещё опыт работы с коммерческими движками.

OkHttp предоставляет простой, легкий в использовании API для выполнения HTTP-запросов, включая поддержку протоколов HTTP/1.1 и HTTP/2. Библиотека поддерживает все стандартные методы HTTP и может легко обрабатывать несколько одновременных запросов, а также предоставляет расширенные возможности: кэширование запросов/ответов, объединение подключений в пул (connection pooling), аутентификация и др.

О том, почему иногда стоит использовать OkHttp, а не вездесущий Retrofit, можно посмотреть в видео от Android Broadcast. Краткое пояснение дано в следующем пункте статьи.

В статье подробно рассмотрены основные объекты и методы библиотеки и представлены основы работы с ней в Android-разработке.

Содержание:

• Преимущества OkHttp
• Основные классы и методы
• Простой GET-запрос (синхронный/асинхронный)
• Сериализация/десериализация
• Простой POST-запрос
• Особенности работы с HTTPS
• Аутентификация на сервере
• Использование вместе с ViewModel

Преимущества OkHttp

OkHttp — это библиотека более низкого уровня, чем Retrofit. Это означает, что HTTP-запросы, автоматизированные в Retrofit с помощью аннотаций, придётся писать вручную. Однако в этом и главный плюс библиотеки: она предоставляет более обширный функционал и настройки соединения, что может повысить производительность и сократить использование памяти. К слову, Retrofit под капотом использует OkHttp.

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

Преимущества OkHttp:

• Гибкость: Библиотека предоставляет больше контроля над процессом сетевого взаимодействием за счёт дополнительных функций, например, пользовательской обработки запросов и ответов.
• Лёгкость: OkHttp — более компактная библиотека, чем Retrofit, что позволяет минимизировать размер используемой приложением памяти.
• Кэширование: Библиотека имеет встроенную поддержку HTTP-кэширования, что может повысить производительность и снизить нагрузку на сеть.
• Аутентификация: OkHttp предоставляет гибкий и расширяемый API аутентификации, что упрощает реализацию различных её моделей.
• Перехватчики (Interceptors): Это механизм, позволяющий легко настраивать запросы и ответы, а также хороший выбор для приложений, требующих расширенной обработки запросов.
• WebSockets: OkHttp обеспечивает встроенную поддержку WebSockets, что позволяет легко реализовать коммуникацию с сервером в режиме реального времени.

Основные объекты и методы

Настройка клиента и запроса

Класс OkHttpClient — клиент для HTTP-вызовов, который можно использовать для отправки запросов и чтения ответов.

OkHttpClient.Builder — класс предоставляющий методы для настройки клиента, например кэш, аутентификация, перехватчики, тайм-ауты и др. По завершению настройки используется метод build(), который возвращает экземпляр класса OkHttpClient.

OkHttp работает лучше при создании одного экземпляра OkHttpClient и повторном его использовании для всех HTTP-вызовов. Так происходит потому, что каждый клиент содержит свой собственный пул соединений и пул потоков. Повторное использование соединений и потоков уменьшает задержку и экономит память. И наоборот, создание клиента для каждого запроса приводит к трате ресурсов на незадействованные пулы.

Класс Request представляет собой HTTP-запрос. Request.Builder позволяет установить параметры запроса, например url и заголовки.

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

• header(name, value) — устанавливает только одно значение заголовка name. При этом все существующие значения заголовка будут удалены, и после этого будет установлено новое значение.
• addHeader(name, value) — добавляет заголовок без удаления уже имеющихся значений.

При чтении заголовка из ответа используйте header(name), чтобы вернуть последнее вхождение заголовка (зачастую это единственное вхождение). Если значение отсутствует, header(name) вернет null. Чтобы прочитать все значения заголовка в виде списка, используйте headers(name).

Для установки целевого URL-адреса запроса используется метод url(). По завершению настройки запроса используется метод build(), который возвращает объект Request.

Отправка запроса

newCall — метод класса OkHttpClient, который подготавливает запрос к выполнению в будущем. Принимает объект Request и возвращает объект Call.

Класс Call (вызов) — это запрос, который был подготовлен к выполнению. Вызов может быть отменен. Поскольку экземпляр класса представляет одну пару запрос/ответ, он не может быть выполнен дважды. Для выполнения запроса существуют два метода:

• execute() — при синхронном вызове. Метод незамедлительно выполняет запрос и блокирует поток до тех пор, пока ответ не будет доступен для обработки или пока не возникнет ошибка.
• enqueue() — при асинхронном вызове. Метод назначает запрос на выполнение в определенный момент в будущем. Диспетчер определяет, когда будет выполнен запрос: обычно сразу же, если в данный момент не выполняются несколько других запросов. Позже клиент получает объект responseCallback либо с HTTP-ответом, либо с исключением в случае возникновения ошибки.

Чтение ответа

Класс Response представляет HTTP-ответ. Тело ответа — свойство экземпляра класса, которое может быть использовано только один раз и затем закрыто. Все остальные свойства неизменяемы.

Прежде чем как-либо использовать тело ответа, необходимо проверить, был ли запрос к серверу успешен. Для этого существует метод isSuccessful() вышеупомянутого класса. Метод проверяет код состояния (status code) HTTP-ответа и возвращает значение true, если код находится в диапазоне 200-300. Если код находится за пределами этого диапазона, он возвращает значение false, указывающее, что запрос не был успешным.

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

Для получения тела ответа используется метод body() класса Response, который возвращает экземпляр класса ResponseBody.

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

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

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

• bytes() и string() — считывают весь текст ответа в память, а затем возвращают его в виде массива байтов или строки соответственно. Методы следует использовать только для небольших ответов. При считывании больших ответов будет вызвана ошибка OutOfMemoryError.
• source, byteStream, charStream — предназначены для потокового чтения ответа. Метод source возвращает объект BufferedSource, позволяющий читать тело ответа в виде потока байтов. byteStream работает аналогично, но возвращает объект InputStream. charStream — возвращает объект Reader, который позволяет читать тело ответа в виде потока символов.

Если использовать body() без упомянутых методов, то будет получен сам объект ResponseBody, с которым ничего особо не поделаешь.

Простой GET-запрос (синхронный/асинхронный)

Перед использованием библиотеки нужно добавить соответствующую зависимость в Gradle:

Номер последней версии можно посмотреть на Maven Central.

Синхронный запрос (Java):

Синхронный запрос (Kotlin):

В то время как в Java используются методы объектов, в Kotlin иногда используются их свойства. Например, свойство body объекта Response.

Каждое тело ответа поддерживается ограниченным ресурсом. Поэтому после использования оно должно быть закрыто. Закрытие ресурса освобождает все системные средства, которые были выделены ресурсу, и делает его доступным для сбора мусора (garbage collection). Если не закрыть тело ответа, произойдет утечка ресурсов, что в конечном итоге может привести к замедлению или крашу приложения.

Для закрытия ресурса можно использовать метод close(), но предпочтительнее использовать блок try-with-resources (Java) и метод use (Kotlin). Обе конструкции выполняют блок кода относительно заданного ресурса, а затем корректно закрывают его, независимо от того, вызвано исключение или нет.

Асинхронный запрос (Java):

Асинхронный запрос (Kotlin):

Асинхронный запрос выполняется в потоке Worker. Когда ответ доступен для чтения выполняется обратный вызов (сallback). Этот вызов выполнится после того, как будут готовы заголовки ответа. Чтение тела ответа все еще может блокировать поток. OkHttp в настоящее время не предлагает асинхронных API для получения тела ответа по частям.

Callback имеет два абстрактных метода:

• onResponse — вызывается, когда HTTP-ответ был успешно получен от удаленного сервера.
• onFailure — вызывается, когда запрос не может быть выполнен из-за проблем с подключением, тайм-аута или при его отмене. Поскольку в сети может произойти сбой во время соединения с сервером, возможен случай, когда удаленный сервер успевает принять запрос до сбоя.

Сериализация/десериализация

В данном пункте кратко рассмотрена сериализация и десериализация объектов (их преобразование в определённую последовательность байтов, которую можно передать по сети, и наоборот).

Для того, чтобы преобразовать объект в строку JSON или наоборот можно воспользоваться библиотеками Gson и/или Moshi.

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

Рассмотрим пример сериализации с помощью Moshi (Java).

То же самое в Kotlin:

Для сериализации необходимо создать объект Moshi, адаптер и передать ему тип сериализуемого объекта. В данном случае это тип Class.

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

1) С помощью метода Types.newParameterizedType(), который создает новый параметризованный тип.

2) С помощью класса TypeToken библиотеки Gson. Класс используется для передачи информации о типах во время выполнения программы. Конструктор класса возвращает представленный класс из заданного типа.

Разница способов состоит в том, что TypeToken более типобезопасен (typesafe), а Types.newParameterizedType более эффективен.

Десериализация осуществляется аналогичным образом.

При сериализации/десериализации Moshi может вызывать разного рода исключения, к примеру если десериалируемая строка не является строкой JSON или если строка не соответствует объекту, в который её пытаются преобразовать.

Если серверная и клиентская часть настроены правильно, то такого не должно происходить. Но всё же рекомендуется оборачивать операции Moshi в блок try-catch.

Простой POST-запрос

Чтобы сделать POST-запрос, используется метод post() класса Request.Builder. Метод принимает RequestBody, который он добавляет к запросу.

POST-запрос в Java:

POST-запрос в Kotlin:

Объект MediaType необходим для описания типа содержимого тела запроса или ответа. Обычно он используется для установки заголовка “Content-Type” в HTTP-запросе.

Чтобы получить объект MediaType можно использовать один из статических методов одноименного класса:

• MediaType.parse(String) — создает новый экземпляр MediaType с указанным типом содержимого и кодировкой. Функция возвращает медиатип для строки, или null, если строка не является правильно сформированным медиатипом.
• MediaType.get(String) — работает аналогично MediaType.parse, но если строка сформирована неправильно, то вызывает исключение IllegalArgumentException.

В Kotlin используется метод toMediaType() объекта String. Метод является аналогом MediaType.get(String).

RequestBody — класс, представляющий собой тело запроса. Экземпляр класса создаётся с помощью метода create.

RequestBody.create(MediaType, String) создает тело запроса с указанным содержимым и его типом. Метод имеет несколько реализаций. Содержимое можно передать в виде массива байтов, файла, строки или объекта okio.ByteString. Тип содержимого всегда указывается с помощью объекта MediaType. Этот объект также устанавливает заголовку “Content-type” соответствующее значение, поэтому вручную устанавливать этот заголовок не нужно.

Аналогом RequestBody.create(MediaType, String) в Kotlin является метод toRequestBody(MediaType?) объекта String.

Особенности работы с HTTPS

OkHttp пытается балансировать между двумя задачами:

• Подключение к максимально возможному количеству хостов. Сюда входят как современные хосты, на которых используются последние версии boringssl, так и немного устаревшие хосты, на которых используются старые версии OpenSSL.
• Безопасность соединения. Сюда входит проверка удаленного веб-сервера с помощью сертификатов и конфиденциальность данных, передаваемых с помощью надежных шифров.

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

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

• RESTRICTED_TLS – безопасная конфигурация, предназначенная для удовлетворения более строгих требований по соответствию.
• MODERN_TLS – безопасная конфигурация, позволяющая подключаться к современным HTTPS-серверам.
• COMPATIBLE_TLS – безопасная конфигурация, которая подключается к безопасным, но менее современным серверам HTTPS.
• CLEARTEXT – небезопасная конфигурация, которая используется для URL-адресов http://.

По умолчанию OkHttp будет пытаться установить соединение MODERN_TLS. Если соединение MODERN_TLS не удастся, okhttp3 переключится на другой тип соединения. Точный механизм отката зависит от конкретной реализации okhttp3 и конфигурации, установленной разработчиками.

Настроить конфигурацию можно следующим образом:

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

Аутентификация на сервере

Аутентификацию на сервере можно реализовать двумя способами.

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

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

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

Рассмотрим пример реактивной аутентификации. В таком случае, если код состояния ответа равен 401 (Unauthorized), OkHttp посылает повторный запрос, включающий заголовок “Authorization”.

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

Здесь метод authenticator с помощью лямбда-функции устанавливает экземпляр интерфейса Authenticator, который предоставляет механизм для проверки ответа от сервера и возвращает запрос, включающий в себя учетные данные клиента. Метод Credentials.basic используется для кодирования имени пользователя и пароля при базовой аутентификации.

Использование вместе с ViewModel

Простой асинхронный запрос в ViewModel можно сделать следующим образом.

Метод postValue передаёт задачу по установке значения главному потоку. Если попытаться присвоить значение напрямую, то будет вызвано исключение java.lang.IllegalStateException: Cannot invoke setValue on a background thread.

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

Начиная с SDK 10 при попытке синхронного вызова в главном потоке будет вызвано исключение android.os.NetworkOnMainThreadException.

Чтобы сделать запрос в отдельном api-файле и передать ответ переменной из ViewModel можно воспользоваться механизмом callback.

В файле SomeApiService.kt находится интерфейс RequestCallback, класс SomeApiService с методом makeRequest, который делает запрос к серверу, и объект SomeApi, через который будет осуществляться доступ к экземпляру класса.

В MainViewModel.kt функция getResponseFromApi реализует интерфейс RequestCallback и передает его в качестве параметра методу makeRequest().

Представленный код можно обернуть во viewModelScope.launch {…}, чтобы запрос был отменён при очистке (разрушении) MainViewModel.

Заключение

OkHttp — гибкая библиотека, выступающая в роли HTTP-клиента.

В отличии Retrofit настраивать клиент, писать запросы и обрабатывать ответы необходимо вручную. Это одновременно и преимущество и недостаток OkHttp. Недостаток заключается в необходимости писать много шаблонного кода. Преимущество — возможность кастомизировать соединение.

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

Полезные ресурсы: Подробнее про Authenticator; Различные примеры использования библиотеки; Перехватчики (Interceptors).

Сейчас насчитывается больше 8 000 разных языков программирования (ЯП), и их количество постоянно растёт. Каждый год, если не месяц, появляются новые, в том числе созданные just for fun, но популярных и востребованных всё же гораздо меньше. На какие из них стоит обратить внимание новичку?

Отвечая на этот вопрос, мы проанализировали несколько самых известных языков и сравнили их популярность по двум рейтингам: TIOBE и Stack Overflow. Также мы изучили уровень зарплат для каждого языка из статьи и проанализировали порог вхождения. В статье рассматриваются JavaScript, Golang, C++, Python, Java, Swift и Kotlin из мобильной разработки.

1. JavaScript
2. Golang
3. C++
4. Python
5. Java
6. Swift
7. Kotlin
8. Так что же выбрать?
   

JavaScript

Популярность

Этот язык находится на 7–ом месте по индексу TIOBE, строящемуся на основе подсчёта результатов поисковых запросов, содержащих название ЯП. В 2022 году рейтинг JavaScript вырос на 0,9%. На графике ниже показана динамика изменения рейтинга языка с 2002 года.

Что касается индекса Stack Overflow, то JavaScript находится на 17–ом месте. Он нравится 61,46% пользователей ресурса (индекс составлен с учётом 22 544 голосов).

Уровень зарплат

По данным Хабр Карьеры, медианный уровень зарплаты программистов на JavaScript — 150 000 рублей. Этот показатель не вырос, но и не снизился с 2021 года, что может говорить о стабильном спросе на разработчиков, специализирующихся на этом ЯП.

Порог вхождения и перспективы

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

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

Golang

Популярность

Golang — относительно молодой ЯП, созданный командой Google. За примерно десять лет он поднялся до 12-го места в индексе TIOBE. В 2021 году он занимал 19–ю позицию. Вот динамика изменения рейтинга ЯП с момента его появления в 2010 году.

В индексе Stack Overflow он занимает 8–е место. С ним предпочитают работать 64,58% пользователей ресурса.

Уровень зарплат

По данным Хабр Карьеры, медианная зарплата разработчиков Golang составляет 205 000 рублей, с ростом на 3% по отношению к 2021 году. Рост зарплат может быть свидетельством увеличения популярности языка от года к году.

Порог вхождения и перспективы

По этому показателю Golang несколько проигрывает JavaScript, поскольку язык изучают в основном профессиональные разработчики, которые программируют и на других языках. Как правило, язык изучают в связке с PHP и Python.

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

С++

Популярность

Согласно индексу TIOBE «плюсы» занимают 3–ю позицию, поднявшись с 4–го места в 2021 году. За год рейтинг языка увеличился на 4,21%. Ниже — динамика популярности с 2002 года.

А вот согласно индексу Stack Overflow язык занимает 25–е место. Он нравится 48,39% пользователей ресурса.

Уровень зарплат

Медианный уровень, по данным Хабр Карьеры, — 150 000 рублей. По сравнению с 2021 годом уровень зарплат вырос на 9%.

Порог вхождения и перспективы

У этого языка довольно высокий порог вхождения. Желательно иметь хотя бы базовое представление о том, что такое программирование, как работает аппаратное обеспечение ПК и ОС. При работе с языком требуется контролировать типы данных, а также выделение и освобождение памяти.

Спрос же на разработчиков С++ остаётся стабильно высоким. Их приглашают на работу в компании разного масштаба, включая такие крупные, как Microsoft, Amazon и Google.

Python

Популярность

По данным индекса TIOBE, Python занял в 2022 году 1–е место, его показатель популярности вырос с 2021 года на 3,76%. Судя по динамике изменения рейтинга, востребованность специалистов по этому ЯП постоянно растёт.

В индексе Stack Overflow язык занимает 6–е место. Его выбирают 67,34% пользователей ресурса.

Уровень зарплат

По данным Хабр Карьеры, Python-программисты получают около 140 000 рублей. При этом с 2021 года этот показатель упал на 7%. Падение может быть связано с ростом количества программистов, работающих с этим ЯП, и вследствие этого ростом предложения на рынке.

Порог вхождения и перспективы

Язык считается несложным для изучения. До уровня Junior его могут освоить люди без технического образования. Что касается перспектив Python, то его популярность растёт год от года. Причина — несмотря на относительную простоту, ЯП позволяет разрабатывать серьёзные проекты со сложной архитектурой.

Java

Популярность

В индексе TIOBE Java находится на 4–ом месте, тогда как в 2021 ЯП занимал 3–ю позицию. Язык много лет занимает ведущие позиции рейтинга, перемещаясь в первой пятёрке. Вот динамика изменения рейтинга.

А вот по версии индекса Stack Overflow он находится на 28–ом месте. Язык нравится 45,75% пользователей ресурса.

Уровень зарплат

Согласно данным Хабр Карьеры медианная зарплата Java-разработчика составляет около 200 000 рублей. За год зарплаты в среднем выросли на 13%.

Порог вхождения и перспективы

По мнению ряда разработчиков, порог вхождения в Java средний. Чтобы научиться программировать на языке, нужен технический английский, чтобы разбираться в документации. Требуются общие знания ООП, паттернов проектирования, а также общее хорошее знание Java в объёме Sun’s java tutorial.

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

Swift

Популярность

Согласно индексу TIOBE язык Swift занимает 15–е место по популярности среди разработчиков. Стоит отметить, что за год ЯП опустился сразу на 5 позиций, в прошлом году он занимал 10–е место. Вот динамика изменения популярности языка с 2014 года.

Что касается индекса Stack Overflow, то Swift занимает 12–е место. Язык нравится 62,88% разработчиков.

Уровень зарплат

Хабр Карьеры говорит о том, что Swift-разработчики получают около 200 000 рублей, за год зарплаты остались на прежнем уровне. Это может говорить о стабильном спросе на специалистов по этому ЯП, который остаётся примерно на одном и том же уровне из года в год.

Порог вхождения и перспективы

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

У языка отличные перспективы, поскольку экосистема Apple, для поддержки устройств которой и создан язык, продолжает активно развиваться. Практически у любой относительно крупной компании есть приложение на iOS, что означает, что спрос на разработчиков не будет падать в ближайшие несколько лет.

Kotlin

Популярность

Согласно индексу TIOBE Kotlin занимает 23–е место. Это относительно новый язык, который ещё просто не успел войти в первую двадцатку или тем более десятку. Тем не менее его популярность постепенно растёт. Так, с прошлого года рейтинг ЯП вырос на 0,58%.

По индексу Stack Overflow язык занимает 11–е место. Он нравится 63,29% разработчиков.

Уровень зарплат

Тезис о росте популярности языка подтверждает и уровень зарплат разработчиков, которые специализируются на Kotlin. По данным Хабр Карьеры, медианная зарплата программиста на Kotlin составляет около 185 000 рублей. За год этот показатель увеличился на 3%.

Порог вхождения и перспективы

По мнению разработчиков, порог вхождения в Kotlin низкий по сравнению с другими языками. Ещё быстрее его можно освоить, если разработчик хотя бы на базовом уровне знает Java. При этом родные для Java итераторы и коллекции поддерживаются им «из коробки».

Интересный факт: в Google считают, что Kotlin открывает больше возможностей, чем Java. Его популярность постепенно растёт — некоторые компании предпочитают переходить на Kotlin с Java. Плюс это универсальный язык, на котором можно написать и Android-приложение, и сервис, и приложение для ПК. В ближайшие лет 5 его популярность будет расти, так что и спрос на Kotlin-разработчиков будет стабильно высоким.

Так что же выбрать?

Мы рекомендуем выбирать тот язык программирования, принципы развития и сфера применения которого ближе к вашим профессиональным интересам. Скажем, если вы собираетесь выбрать своей отраслью Data Science, то вам нужен Python. Если хотите посвятить себя мобильной разработке, то без Java, Swift или Kotlin не обойтись.

Так что приведённые данные относительно места разных ЯП в индексе или уровня зарплат разработчиков — лишь ориентир, но далеко не главный фактор, которым стоит руководствоваться при выборе языка программирования, который вы собираетесь начать учить в 2023 году.

Напомним, что индекс TIOBE оценивает популярность языков программирования, основываясь на поисковых запросах, которые содержат тот или иной язык. Для формирования индекса используются такие ресурсы, как Google, YouTube, Amazon, Wikipedia, Yahoo!, Bing и Baidu.

В 2023 году популярность языков изменилась. Какие языки потеряли популярность, а какие — нет, рассказали в этой статье.

1. Python, C и C++ соревнуются за звание лучшего языка
2. Пара слов о других языках
3. Выводы

Python, C и C++ соревнуются за звание лучшего языка

Именно таковы результаты по состоянию на конец декабря — двадцать языков программирования с наибольшей рыночной долей по версии TIOBE:

Ещё в прошлом году Java уверенно держалась в тройке, но теперь уступила своё место «плюсам». Любопытно, что в последний раз C++ становился лидером рейтинга TIOBE в далёком 2003 году, и это впервые, когда данный язык программирования обошёл Java по поисковым запросам. При этом Java входила в топ-3 свыше двадцати лет, начиная с 2001.

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

1. C++ — 1 раз (2003).
2. C — 3 раза (2008, 2017, 2019).
3. Python — 5 раз (2007, 2010, 2018, 2020, 2021).

Пара слов о других языках

Помимо прочего, мы видим, как Kotlin и Julia приближаются к топ-20, JavaScript держится в семёрке, а PHP вырывается в десятку, тогда как в прошлом году занял 12-е место.

Интересно, что Go поднялся аж на 7 позиций и теперь занял 12-е место рейтинга. Стоит отметить, что по версии GitHub за третий квартал 2022 Golang также находится на четвёртом месте по популярности, обогнав при этом PHP, C, C#, Ruby, TypeScript и JavaScript. Тенденция налицо:

На 18-е место рейтинга TIOBE вернулся Perl. Rust удерживает 20 позицию. Что касается Delphi, то он всю осень прыгал туда-сюда:

• сентябрь — 13 место (1.09%);
• октябрь — 18 место (0.85%);
• ноябрь — 14 место (1.08%).

В декабре же язык опустился на 16 место (0.85%), что соответствует результатам декабря прошлого года.

Выводы

Разумеется, рейтинг языков программирования 2022 TIOBE сложно назвать объективным, так как он рассматривает лишь один аспект — популярность ЯП в поисковых запросах пользователей. Он не отражает реальный рыночный спрос или количество написанного кода, как это делает GitHub в своих отчётах на основе проектов.

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

По итогам пятого раунда Python обошёл Pascal, а C# обошёл С. Результаты прошлого раунда можно посмотреть здесь.

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

Голосование по пятому раунду продлится до 18 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

Не хотите пропустить новые раунды? Подпишитесь на тэг Лучший язык 2022 и следите за обновлениями в личной ленте.

Сегодня между собой соревнуются:

• Ruby и PHP;
• Swift и Kotlin.

Голосование по этим языкам программирования продлится до 16 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

Правила батла по-прежнему просты:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 13 декабря, финал — 20 декабря.

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

• Этап 1
• Этап 2
• Этап 3
• Этап 4
• Этап 5
• Этап 6
• Полуфинал
• Финал
• Результаты

Турнирная таблица:

Старт уже завтра — 13 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

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

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

1. Коротко о Dynamic feature delivery
2. Влияние Dynamic delivery на архитектуру нашего приложения
3. Миграция существующих фич
4. Результаты
5. Заключение
6. Дополнительные материалы

Коротко о Dynamic feature delivery

Dynamic delivery — технология от Google, которая позволяет выделить из монолитного приложения фичи, и устанавливать и удалять их прямо во время выполнения программы.

Если вы только начали знакомство с Dynamic delivery, то рекомендую начать с ссылок, которые я собрал в конце статьи.

После ознакомления с этим материалом вы сможете лучше понять принцип работы Dynamic delivery, ознакомиться с предоставляемым API, найти пример с использованием архитектуры RIBs. Однако, не во всех проектах используется эта архитектура. Поэтому я дополню подборку источников и расскажу, как у нас в мобильном штабе «Лаборатории Касперского» происходила миграция существующего кода в динамический модуль.

Влияние Dynamic delivery на архитектуру нашего приложения

Как была построена многомодульность

Начну с короткого описания нашей архитектуры (более подробное можно найти по ссылкам в конце статьи). В нашем проекте Kaspersky Internet Security для Android есть module-injector, который содержит базовые интерфейсы:

BaseDependencies используется для перечисления объектов, которые требуются фиче на вход (зависимости фичи). BaseApi — для перечисления объектов, которые фича предоставляет наружу (внешний интерфейс фичи). ComponentHolder нужен для связки BaseDependencies. BaseApi — позволяет получить реализацию BaseApi конкретной фичи, передав все необходимые зависимости.

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

Связующим звеном выступает SecurityNewsFeatureComponentHolder:

Таким образом, чтобы получить инстанс интерактора в основном модуле, необходимо в метод init объекта SecurityNewsFeatureComponentHolder передать зависимости фичи.

В проекте присутствует и альтернативный вариант базового ComponentHolder — LazyComponentHolder, который создаёт инстанс API фичи только при первом обращении. Реализацию его в статье приводить не буду, чтоб не усложнять материал.

Если в проекте используется Dagger, то в теле метода createApi будет обращение к dagger-компоненту фичи. Однако, такая тройка интерфейсов не обязывает использовать тот или иной DI-инструмент.

В приведённом выше коде SecurityNewsComponent расширяет интерфейс SecurityNewsFeatureApi презентором SecNewsPresenter. Он объявлен в интерфейсе SecurityNewsComponent, а не в SecurityNewsFeatureApi, потому что используется в коде внутри модуля фичи, а не внутри модуля App. Чтобы внутри фичи можно было получить SecNewsPresenter, изменим код SecurityNewsFeatureComponentHolder:

Как можно заметить, теперь мы держим ссылку типа SecurityNewsComponent, а не SecurityNewsFeatureApi. Появился метод getSecurityNewsComponent, который поможет получить SecNewsPresenter внутри кода фичи. В итоге внутри модуля фичи происходит обращение к методу getSecurityNewsComponent, а вне его — к методу get.

Влияние Dynamic delivery на архитектуру приложения

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

Описанные выше ограничения Dynamic delivery подталкивают нас изменить код внутри модуля фичи. Начнём с разделения модуля на API и реализацию.

Такое разделение следует сделать для создания общего для App и Dynamic feature impl-модуля, куда можно положить классы и интерфейсы, на которые ссылаются в коде оба модуля.

В Dynamic feature API выносим SecurityNewsFeatureDependencies, SecurityNewsFeatureApi и все интерфейсы и классы, которые используются в них (в нашем случае — SecurityNewsInteractor). Однако, мы не можем вынести SecurityNewsFeatureComponentHolder — он связан с сущностями фичи, которые должны остаться в том же модуле. Если обращений к SecurityNewsFeatureComponentHolder будет несколько, то увеличится количество использования ReflectionAPI в коде (например, через ReflectionAPI нужно будет вызвать метод init, чтобы проинициализировать фичу, а затем — get, чтобы получить внешний интерфейс фичи).

Для упрощения кода можно уменьшить количество доступных только через Reflection API методов до одного (оставить только метод инициализации init). Для этого в module-injector создаём абстрактный класс ApiHolder:

В модуле FeatureSecurityNewsApi создаём объект SecurityNewsApiHolder:

В модуле FeatureSecurityNewsImpl меняем код в SecurityNewsFeatureComponentHolder:

Таким образом, сперва через ReflectionAPI нужно вызвать метод инициализации у SecurityNewsFeatureComponentHolder, в результате чего будет создан SecurityNewsComponent, а ссылка на компонент сохранится в поле объекта FeatureSecurityNewsApi. После инициализации внутри модуля фичи будет происходить обращение к методу getSecurityNewsComponent объекта SecurityNewsFeatureComponentHolder, а вне модуля — к методу getApi объекта SecurityNewsApiHolder.23ц

Миграция существующих фич

Мы успешно адаптировали архитектуру многомодульного приложения под Dynamic delivery. Следующим шагом применим один из нескольких сценариев включения фичи в состав приложения. Исходя из официального описания, существует 3 сценария:

• при установке (install-time delivery);
• при установке с определёнными фильтрами (conditional delivery);
• по запросу (on demand delivery).

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

Рассмотрим сценарий, когда фича Security news была частью приложения, а теперь мы хотим её сделать динамически подгружаемой по требованию. Если обычный gradle-модуль сделать сразу динамически подгружаемым, то фича в следующем релизе исчезнет у пользователя, который получит обновление. Это может иметь негативные последствия как поведенческого характера, так и юридического. Если это не критично, можно явно пользователя попросить скачать фичу снова. Если по каким-то причинам важно сохранить фичу на девайсах тех, к кому она уже попала (например, если за неё уже заплатили), то нужно проработать процесс миграции. Рассмотрим возможные сценарии миграции от простого к сложному.

1 вариант

Выше мы рассмотрели 3 сценария включения фичи в состав приложения. Чтобы сохранить фичу у пользователя, можно сперва gradle-модуль превратить в динамическую фичу, доступную в момент установки (сценарий install time), а после этого сделать её подгружаемой по требованию (сценарий on-demand delivery). В этом варианте получаем 3 релиза приложения:

• релиз A содержит фичу как обычный gradle модуль;
• релиз B содержит фичу как Dynamic module с dist-параметром install-time;
• релиз C содержит фичу как Dynamic module с dist-параметром on-demand.

В этом случае, при миграции с релиза B на релиз C фича не пропадёт с устройства пользователя. Однако, такой вариант миграции всё равно сохраняет риск потери фичи: если пользователь получит релиз A, не получит релиз B, а затем получит релиз C.

2 вариант

Очевидно, что проблему с неполучением промежуточного релиза можно решить увеличением количества этих промежуточных релизов. То есть между релизами A и C из первого варианта выпустить промежуточные: B1, B2, B3… Если пользователь не получил релиз B1, он сможет получить B2 или B3.

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

3 вариант

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

exception com.google.android.play.core.splitinstall.SplitInstallException: Split Install Error(-7): Download not permitted under current device circumstances (e.g. in background). (https://developer.android.com/reference/com/google/android/play/core/splitinstall/model/SplitInstallErrorCode.html#ACCESS_DENIED).

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

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

Этот вариант тоже не даёт гарантию. Потребуется явное согласие пользователя: нужно будет попросить его подтвердить скачивание. Это 4-й вариант.

4 вариант

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

5 вариант

Google предоставляет возможность отложенной установки (deferred install). Такой вариант не даёт контроля над установкой. В официальной документации можно найти такую фразу: best-effort when the app is in the background. Практика показывает, что скачивание происходит при получении и установке следующего обновления. Таким образом, пользователь может пробыть без фичи какое-то время до получения обновления.

6 вариант

Если важно сохранить какой-то функционал у всех пользователей, можно ядро фичи оставить в приложении, а опциональную часть и тяжёлые ресурсы вынести в динамическую фичу, подгружаемую по требованию. В случае фичи Security news в состав ядра можно включить интерактор, который останется в приложении и продолжит мониторить и получать свежие новости. А всю логику, связанную с UI, — загружать отдельно по требованию.

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

Результаты

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

Стоить отметить, что Dynamic delivery возможен только с использованием AppBundle, который сам по себе даёт хорошую оптимизацию. В нашем случае переход на AppBundle помог уменьшить размер приложения на разных устройствах в среднем на 16%.

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

• dex-файлов вынесением части кода в динамические модули (в том числе вынесением больших используемых библиотек, которые нужны только этой фиче);
• папок res и assets вынесением картинок и других файлов в динамические модули;
• папки lib (например, тяжёлые нативные .so-файлы);
• бинарных ресурсов вынесением большого количества строк и идентификаторов в динамические модули.

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

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

Заключение

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

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

Надеюсь, статья была полезна для вас. Делитесь в комментариях своими результатами и мнениями об этой возможности от Google.

Дополнительные материалы

• Инструкция к Dynamic Delivery;
• Codelabs Android Dynamic features;
• Dynamic Delivery в многомодульных проектах (части 1 и 2);
• Dagger 2. Основы, создание графа зависимостей, Scopes;
• Ещё раз про многомодульность Android-приложений;
• Присоединиться к мобильной команде «Лаборатории Касперского».

Java, по мнению Amazon, один из оптимальных по энергопотреблению и времени выполнения языков программирования. Он зарекомендовал себя для серверной разработки, на тех платформах, где может работать виртуальная машина. Не зря же его называют WORA (Write Once and Run Anywhere — «Напиши один раз, запускай где угодно»). Но кроме того, его применяют для разработки игр, облачных вычислений, больших данных, искусственного интеллекта и интернета вещей.

Кто же ему наступает на пятки и пробует выбить из основных сегментов? Изначальный клон Java под названием Kotlin. Авторы хотели улучшить типобезопасность по сравнению с прародителем и сделать язык более простым, чем Scala.

В мае 2017 года Google объявил, что язык программирования Kotlin теперь является предпочтительным языком для разработчиков приложений для Android. Это стало признанием отрасли.

Google оценивает, что 70% из 1 000 лучших приложений в Play Store написаны на Kotlin. Также на нём сделаны Maps, Play, Drive. Однако этот язык программирования используют и для бэкенд-разработки, например, он доступен в Spring Framework.

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

Для новичков

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

К примеру, новичку поставили задачу написать и backend server, и android-приложение, обращающееся к нему. Какие технологии для этой задачи необходимо будет изучить, чтобы выполнить задачу на Java и Kotlin?! На Java и Kotlin необходимо знать сам язык, принципы Rest взаимодействия, Android-платформу.

Минимальные специфичные для Java технологии, которые будут отличаться от Kotlin, — Spring Boot, Retrofit. Чтобы то же самое сделать на Kotlin, нужно изучить только фреймворк Ktor в дополнение к общему стеку.

Kotlin

+ официальный язык для Android;

+ кросс-платформенность: можно писать backend-, Android-, iOS- и веб-приложения, создавать IoT-решения;

+ де-факто стандарт разработки и в нём много синтаксического «сахара»;

+ более лаконичен и малословен, что позитивно влияет на читабельность;

+ более консистентен при построении межплатформенного взаимодействия.

Java

+ кросс-платформенность: мобильные и серверные приложения, работа с AI и IoT;

− не прощает ошибок: забыл запятую, и всё посыпалось.

Для опытных разработчиков

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

Например, разработчикам передали макеты приложения в Figma. Им нужно создать подходящий код, чтобы дизайн превратился в полноценный продукт. Для ускорения и упрощения разработки нужно выбирать наиболее безопасный и быстрый в плане компиляции язык.

Kotlin

+ совместимость с Java;

+ большая безопасность;

− считается молодым языком программирования с «детскими» болячками.

Java

+ сильное сообщество;

− анализ 2016 года давал преимущество Java над Kotlin в 12–15% для чистых сборок. В текущем году анализ говорит, что быстродействие сопоставимо;

− требует больше памяти.

Для бизнес-процессов

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

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

Kotlin

+ возможность автоматической конвертации в Java и обратно;

+ классная поддержка языковых в фич в IDE экосистемы JetBrains;

− более 3 600 соискателей в Москве;

− мало литературы и обучающих курсов.

Java

+ более 42 400 соискателей в Москве;

− платная коммерческая лицензия начиная с 11 версии.

Kotlin можно использовать везде, где работает Java — а это бэкенд, веб-приложения (как серверная часть, так и интерфейс), десктопные приложения, приложения под Android.

Что же такое коллекция?

Коллекция — это классы-дженерики. Коллекции используются в программировании каждый день.

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

Для чего же необходимы коллекции? Для того, чтобы облегчить хранение данных.

Виды коллекций

В Kotlin существуют три основных типа коллекций: List, Set и Map.

List хранит и отслеживает позицию элементов. Эта коллекция знает, в какой позиции списка находится тот или иной элемент. Несколько элементов List могут содержать ссылки на один объект.

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

Map использует пары «ключ-значение». Этот тип коллекции знает, какое значение связано с заданным ключом.

Два ключа могут ссылаться на один объект, но дубликаты ключей невозможны. Хотя ключи обычно представляют собой строковые имена (например, для составления списков свойств в формате»имя-значение«), ключом также может быть произвольный объект.

Простые коллекции являются неизменяемыми. Это значит, что после инициализации вы не сможете добавлять или удалять элементы из коллекции.

Для редактирования коллекций Kotlin представляет изменяемые версии подклассов MutableList, MutableSet и MutableMap.

List и MutableList

Для создания списка List в программе вызывается функция с именем listOf:

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

Также List можно создать явно, указав тип List:

Для получения элемента вводим:

Перебор всех элементов List выполняется следующим кодом:

Также можно проверить, содержит ли List ссылку на конкретный объект и получить индекс соответствующего элемента.

Если вам нужен список с возможностью обновления элементов, используйте MutableList.

Новые элементы добавляются в MutableList функцией add. При этом новый элемент добавляется в конец списка.

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

Есть два способа удаления значений из MutableList.

В первом способе вызывается функция remove, которой передается удаляемое значение. Например, следующий код проверяет, содержит ли список animals строку «Cow», после чего удаляет соответствующий элемент:

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

Если вы хотите обновить MutableList так, чтобы значение с конкретным индексом было заменено другим значением, это можно сделать при помощи функции set:

Прочие функции MutableList:

1. sort — возвращает список List и сортирует содержимое MutableList в естественном порядке;
2. reverse — возвращает список List и переставляет элементы в обратном порядке;
3. shuffle — возвращает список List и сгенерирует случайную перестановку;
4. addAll — добавляет все элементы, хранящиеся в другой коллекции;
5. removeAll — удаляет элементы, входящие в другую коллекцию;
6. retainAll — оставляет все элементы, входящие в другую коллекцию, и удаляет все остальные;
7. clear — удаляет все элементы.

Set и MutableSet

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

В отличие от List, множество Set не упорядочено и не может содержать повторяющихся значений.

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

Для создания списка Set в программе вызывается функция с именем setOf:

Перебор элементов множества Set в цикле:

Функция contains возвращает true, если содержит элемент, и false в противном случае.

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

Функции MutableSet:

1. add — добляет элемент;
2. remove — удаляет элемент;
3. clear — удаление всех элементов;
4. функции addAll, removeAll и retainAll также могут использоваться для внесения массовых изменений в MutableSet (по аналогии с MutableList).

Map и MutableMap

Коллекция Map работает как список свойств. Вы передаете ей ключ, а Map возвращает значение, связанное с этим ключом. Хотя ключи обычно имеют тип String, они могут быть объектами любого типа.

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

Чтобы создать Map, вызовите функцию с именем mapOf и передайте ей пары «ключ-значение» для инициализации Map.

С Map чаще всего выполняются три операции: проверка наличия конкретного ключа или значения, выборка значения для заданного ключа и перебор всех элементов Map.

Для проверки наличия конкретного ключа или значения в Map используются его функции containsKey и containsValue:

Для получения значения, связанного с конкретным ключом, используются функции get и getValue. Если заданный ключ не существует, get возвращает null, а getValue вызывает исключение.

Также вы можете перебрать все элементы Map. Например, вот как цикл for используется для вывода всех пар «ключ-значение» в recipeMap:

Объект Map неизменяем, поэтому вы не сможете добавлять или удалять пары «ключ-значение», а также обновлять значение, хранящееся для заданного ключа. Для выполнения такой операции следует использовать класс MutableMap. Посмотрим, как он работает.

Давайте создадим MutableMap:

Для добавления элементов в MutableMap используется функция put:

Также в MutableMap можно добавить сразу несколько пар «ключ-значение» при помощи функции putAll:

Удаление элемента с ключом с помощью remove уничтожит все элементы с clear:

Еще можно удалить их таким способом:

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

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

Чем являются функции расширения Kotlin на самом деле

По своей задумке, функция расширения Kotlin — это дополнительный метод для любого объекта, даже для потенциально несуществующего (нуллабельного). Этот инструмент является прямой реализацией переопределения методов паттерна проектирования декоратор. Благодаря удобному синтаксису пользоваться данной сахарной надстройкой в Kotlin очень просто.

Рассмотрим пример:

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

Если скомпилировать данный код и разобрать байткод в Java, то конструкция с методом будет выглядеть следующим образом:

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

Расширение API класса, который вам не принадлежит

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

Конвертация моделей из одной в другую

Потенциально опасное использование, но если держать в голове следующие правила, то очень даже удобное.

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

Расширение возможностей любого класса, но в ограниченной области видимости

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

В данном примере внутри функции расширения Kotlin используется поле сервиса — thirdPartyClient, из которого получаются некие мета данные. Это вполне допустимое использование функции расширения, но следует быть предельно осторожным если вы помещаете внутрь такого метода любое внешнее поле! Для этого должна быть веская причина!

Расширение функционала дженериков

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

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

Для чего никогда нельзя применять функции расширения

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

• Первое. Бесконтрольное расширение любого функционала вместо написание обычного метода на глобальном уровне очень сильно засорит контекст IDE и станет большой болью в поиске всех мест, где был расширен какой-то класс.
• Второе. Если размер функции расширения Kotlin превышает 5 строк, значит настало время писать обычный метод.

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

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

В заключение.

Функции расширения — удобный синтаксический сахар Kotlin, который позволяет использовать язык практически как угодно. Однако будьте бдительны и применяйте их только там, где они действительно упростят жизнь. Эти методы должны быть маленькими и решающими конкретную задачу, никто не намерен сделать cmd+click по методу и провалиться в ад с огромным количеством бизнес-логики.

Используйте их как вспомогательный инструмент и не злоупотребляйте их мощью ?

Зачем нужен переход на Kotlin

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

Kotlin сильно уменьшает количество кода, например, простой Java-объект (Plain Old Java Object), хранящий пять полей, займет примерно 96 строк кода. В то время как на Kotlin аналогичный Data-класс займёт всего одну строку, поскольку компилятор переопределит все нужные методы.

Кроме того, существует несколько серьёзных проблем, которые до сих пор есть в Java, но — внимание — уже решены в Kotlin! Вот некоторые из них:

• Nullability — в Java мы не знаем, возможен ли null в значении данного объекта (и нельзя запретить ему принимать null), из-за чего может случиться всем известная ошибка NullPointerException, поскольку имело место обращение к «нулевому» объекту.
• Raw types — это generic-типы в Java без указания типа-параметра, использование которых может привести к heap
  pollution — ситуации, когда переменная параметризованного типа хранит в себе объект, параметризованный другим типом. В результате может возникнуть ClassCastException в процессе исполнения программы — в Kotlin такие типы исключены.
• Полноценные функциональные типы отсутствуют в Java в отличие от Kotlin.

Преимущества и дополнительные возможности Kotlin

Kotlin относится к объектно-ориентированным языкам программирования, сочетая в себе черты функциональных языков, что отличает его от Java, на котором не получится без проблем писать в функциональном стиле. Если вы разрабатываете под Android, то, скорее всего, выберете Kotlin, так как этот язык теперь официально поддерживается и продвигается Google, всё реже можно найти примеры кода на Java.

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

У Kotlin есть множество возможностей, самые примечательные из которых:

• Extension-функции или функции-расширения класса — делают код «чище», а в сочетании с автодополнением в IDE ускоряют разработку;
• Data-классы хранят данные в лаконичном виде;
• Лямбда-выражения и inline-функции — нужны для использования функций высшего порядка без потери производительности;
• Object-классы позволяют с лёгкостью реализовать полезный паттерн проектирования Singleton;
• Inline-функции с параметрами reified типа  позволяют во многих случаях избавиться от рефлексии, которая может влиять на производительность (на старых версиях компиляторов).

Особенности миграции

Есть некоторые особенности, которые стоит учитывать при переходе.

Во-первых, в Kotlin нет привычных методов с ключевым словом static, для этого используется «companion object» в теле класса либо package level-функции. Аннотация @JvmStatic необходима тогда, когда мы хотим вызвать «companion object» — методы из Java таким же образом, каким бы вызывали любой другой static-метод в Java.

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

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

Специальной подготовки непосредственно данных в БД не требуется. Если вы заменяете обычные Java-объекты на Data-классы, то необходимо проверить, что логика переопределенных вами ранее методов toString(), equlas() и hashCode() соответствует той, что по умолчанию будет сгенерирована в этих методах в Kotlin.

Необходимые шаги по переходу

• Выделите основные участки кода, которые в первую очередь необходимо мигрировать. Выберите места, где максимально сократится код или значительно повысится читаемость и безопасность. Лучше начинать не с core-модулей, а с верхних слоев приложения: из-за того что Kotlin проектировался с учетом необходимости взаимодействия с языком Java, а не наоборот, лучше наследоваться от Java-классов, чем в Java наследоваться от Kotlin-классов.
• Для упрощения перехода используйте встроенные средства конвертации Java-кода в Kotlin-код в IDE
  Intellij Idea или Android Studio, но не забывайте проверять полученный код.
• Начинайте писать всю новую функциональность только на Kotlin и по возможности дорабатывайте старый код тоже на нём.
• Постепенно углубляйте миграцию — переписывайте внутренние, абстрактные слои до тех пор, пока Java-кода не останется в проекте.

Возможные проблемы и уязвимости при переходе на Kotlin

Kotlin создавался как стопроцентно совместимый с Java — это значит, что проблемы при переходе будут минимальными.

Самая распространённая проблема связана с nullability, ведь когда мы вызываем Java-код из Kotlin-кода, то используем платформенные типы, которые не дают никакой информации о допустимости null-значений, а компилятор в свою очередь не делает дополнительной проверки на null. Так мы можем вызвать какой-нибудь метод на возвращённом нам объекте и получить на этапе исполнения кода описанную ранее NullPointerException.

Если в исходном проекте вы использовали популярный плагин Lombok для автоматической генерации методов (getters, setters и так далее), то вам придётся полностью от него отказаться, ведь Kotlin и так выполняет большинство функций Lombok, и вместе работать они не смогут. Полная замена Lombok может привести к масштабным изменениям в коде.

Если вы мигрируете проект, реализованный на Spring Boot, необходимо учитывать, что классы в Kotlin по умолчанию «закрыты» для наследования. Если не «открыть» классы с аннотациями типа @Configuration и @Service, это приведёт к ошибкам при запуске.

Кроме того, могут возникнуть ошибки при недостаточном понимании устройства языка, в редких случаях довольно, казалось бы, простой код ведет себя непредсказуемым образом. Рекомендую ознакомиться с Kotlin Puzzlers на Github, где вы увидите неочевидные головоломки в Kotlin и их решения. Это поможет лучше узнать язык и защитить себя от подобных проблем.

Пример реального кейса

На одном из проектов, где я выступала в роли backend-разработчика, необходимо было мигрировать высоконагруженную интеграционную платформу с Java на Kotlin. Отмечу, что особых проблем с переходом не возникало, несмотря на большой объем исходного кода.

Система сейчас успешно работает в продуктиве — за всё время развития и поддержки доля ошибок, связанных с Kotlin или взаимодействием Java и Kotlin, ничтожно мала. По состоянию на 2020 год все ключевые модули были переписаны, что составляло 60–70% от общего кода. Стоит также отметить, что переход на Kotlin происходил в начале развития этого языка программирования, задолго до пика популярности, что не помешало нам успешно использовать его в продуктиве.

В решающем раунде перед полуфиналом батла схлестнутся:

• C++ vs. C#
• Kotlin vs. Python

Выбирайте язык, основываясь на личных предпочтениях. Голосование в шестом раунде остановится 20 декабря 2021 года в 11:00 по Москве.

В четвёртом раунде за звание лучшего языка программирования 2021 поборются:

• JavaScript vs. C++
• Ruby vs. Kotlin

Слушайте сердце и выбирайте язык, исходя из личной симпатии. Голосование в четвёртом раунде будет завершено 18 декабря 2021 года в 11:00 по Москве.

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

1. Всего участвует 16 языков программирования.
2. Каждый день соревнуются две пары.
3. На возможность проголосовать за любимый язык отводится 24 часа.
4. Пары составляются рандомно.
5. Выбирайте тот язык, который субъективно нравится вам больше.
6. В финале мы определим победителей — языки которые заняли первое, второе и третье место.
7. Старт — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

А вот как мы выбирали лучший язык программирования в прошлом году.

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

Результаты баттла можно посмотреть по ссылке.

А после поменял проект и столкнулся с Kotlin именно в бэкенде. И хочу поделиться преимуществами Kotlin отличиями Kotlin от Java в абсолютно одинаковых задачах.

Забегая вперёд скажу, что колоссальной разницы, из-за которой нужно срочно переписывать всё на Kotlin, нет. Но есть огромное количество фич, которые делают разработку быстрее, проще и безопаснее. На текущем проекте весь новый функционал мы с командой пишем на Kotlin, параллельно переписывая старые куски Java-кода n-летней давности. На Kotlin эти куски получаются гораздо более читабельными и короткими.

Простота интеграции в уже существующий проект, написанный на Java

Если вы только присматриваетесь к Kotlin для бэкенда, то учитывайте что в окружении, которое запускает ваш проект на Java 8, можно без танцев с бубном запустить скомпилированный проект на Kotlin. Да, на той же jvm, на том же окружении и с минимумом усилий.

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

Сейчас доступна компиляция Kotlin-исходников в байткод от Java LTS – 8, 11 и (пока экспериментально) 16.

Инициализация и логика работы с DTO классами

Пример избитый, но максимально наглядный.

И теперь то же самое на Java:

Мне кажется, здесь даже комментарии излишни.

Указатели data class в Kotlin по-умолчанию подразумевают наличие getter, setter (для var полей), equals, hashcode, toString для всех полей. При желании можно переопределить каждый из этих методов по своему, но требуется это крайне редко.

Null safety

В Kotlin требуется явно указывать, может ли тот или иной метод вернуть null или нет. Таким образом можно считать, что все данные уже обернуты в аналог Optional. И NullPointerException будет вами встречаться настолько редко, что вы успеете по нему соскучиться.

Выделение основного конструктора

Суть в чём: есть основной (Primary) конструктор и вспомогательные (Secondary). Вспомогательные обязаны вызывать основной как конструктор родительского класса.

Явное объявление изменяемых и неизменяемых полей

Следующее преимущество: в Kotlin получаются довольно простые и элегантные конструкции. Если требуется, чтобы поле dto можно было менять, то для его объявления используется var. Тогда будет создан метод setter и поле не будет final.

А если нужно сделать поле иммутабельным, для объявления следует использовать val. Смотрится очень красиво и просто. Плюс не нужно следить за вспомогательными методами.

Пример: поля цвета и роста можно изменить после создания, а имя — только при инициализации объекта:

Immutable коллекции по умолчанию.

То, что появилось в Java несколько позже, уже давно было в Kotlin — создание коллекций сразу иммутабельными.

Любые изменения с этими коллекциями будут создавать новую иммутабельную коллекцию после преобразования:

Но изменить какой-то элемент отдельно не получится. Для классических мутабельных коллекций используется явно изменяемые аналоги:

Работа со сложными классами методами примитивов

Преимущество Kotlin, которому не перестаю радоваться — возможность использовать операторы для базовых операций к сложным классам. Если нужно сложить BigDecimal числа — берёшь и пишешь их через плюс. Не нужно явно вызывать метод у первого слагаемого.

То же самое с массивами: хочешь удалить элемент из мутабельного массива – пишешь массив минус этот элемент. И если элемент присутствует, то он удаляется

В Java нужно вызывать специальный метод:

Аналогичные приёмы работают и с более сложными классами, например с коллекциями:

Возможно писать однострочные методы действительно в одну строку

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

Вместо Java варианта:

Контекстные функции.

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

Есть функции let, apply, also, with, run. Из-за их обилия вначале возникает вопрос: что подходит для конкретного кейса. Но когда привыкаешь, становится непонятно как раньше жил без них.

Простой пример: взять результат и как-то его обработать:

Либо инициализировать объект и дополнительно проинициализировать его var поля:

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

Сейчас я по-прежнему продолжаю писать и видеть код на Java, но в 99% случаев это связано с образовательными программами, в которых принимаю участие: профессия Java разработчика на Hexlet и различные вебинары для онлайн школ и курсов. Так что я постоянно сравниваю два языка и радуюсь, что рабочие проекты пишу на Kotlin.

Советую попробовать каждому — как минимум на pet-проекте чтобы понять подходят вам парадигмы Kotlin или нет.

Jetpack Compose — это аналог SwiftUI для Android. Правда, свой UI-инструмент Google анонсировала раньше — ещё два года назад — но с выпуском затянула.

Разработчики ждали стабильную версию, чтобы интегрировать Jetpack Compose в свои приложения, хотя бета 1.0 вышла ещё в марте.

Что полезного

Jetpack Compose позволяет программисту удобно описывать интерфейсы программ — это экономит время на разработку и сопровождение.

В Jetpack Preview есть две новых полезных  фичи:

• Compose Preview визуализирует пользовательские интерфейсы в различных состояниях: в светлой и темной темах, с разными настройками шрифта и так далее.
• Deploy Preview позволяет пушить обновлённый код без необходимости перезапускать приложение.

Что удобно

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

Как начать работу

Чтобы начать работу с Jetpack Compose, нужно обновить Android Studio Arctic Fox.

Подробная инструкция о том, как начать работу с Jetpack Compose, описана на сайте Android Developers.

Каких функций ждать

Google выложила дорожную карту разработки Jetpack Compose.

В следующем релизе обещают завезти виджеты и поддержку WearOS.

Источник: AndroidPolice

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

Представлялось два варианта ускорить процесс:

• нанять больше людей;
• использовать технологию, которая позволит объединить платформы iOS и Android.

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

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

• на тот момент было мало специалистов, которые знают Dart;
• уже была команда, которая писала нативно;
• Android и iOS регулярно выпускают новые версии и UX-паттерны, и между нативным выпуском и его реализацией Flutter будет разрыв.

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

Требовалось кроссплатформенное решение. Узнав про Kotlin Multiplatform Mobile, мы поняли, что это тот самый подход. Технология исключает дублирование бизнес-логики, обеспечивая производительность и безопасность собственного пользовательского интерфейса.

Использование Kotlin в продукте

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

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

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

• UI (презентация);
• домен (уровень бизнес-логики);
• дата (уровень источника данных).

Сначала мы ограничивались перемещением уровня данных, но затем стали перемещать всё остальное, включая бизнес-логику приложения. Единственные части KMM, которые мы не используем, — это пользовательский интерфейс и специфичные для платформы функции, такие как Apple и Google Pay.

Внутри библиотеки мы используем Ktor, Kotlin Serialization и Coroutines. Оболочка Rx применяется для адаптации платформы, но в будущем планируем использовать только Coroutines на Android и, если будет возможность использовать Async\Await на стороне iOS

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

Достоинства и недостатки КММ

Недостатки, которые обнаружились при использовании Kotlin Multiplatform Mobile:

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

Далее выявленные достоинства.

• До KMM основные функции типа корзины требовали 40-60 часов работы для каждой платформы (80-120 часов для обеих), не считая тестирования. С помощью KMM мы можем сократить временные рамки до 50-70 часов для обеих платформ.
• Мы разделяем только бизнес-логику между платформами и используем собственный код для каждого пользовательского интерфейса. Такой подход обеспечивает максимальную производительность при минимальном количестве шаблонного кода.
• Легкий наём и поддержка — KMM работает на Kotlin, которым владеют большинство разработчиков Android. А из-за близости к JVM-языкам любой backend-разработчик теоретически может работать с Kotlin и KMM.
• Идентичная логика на обеих платформах значительно снижает расхождения, а значит, удешевляет разработку и поддержку.

JetBrains сделала отдельную статью про язык C++, в которой собрала мнение экспертов по полученной статистике.

20% используют C++20

Каждый пятый респондент использует последний официально подписанный стандарт C++20, хотя он поддерживается ещё не во всех компиляторах.

Ещё столько же опрошенных собираются перейти с самого популярного стандарта С++11 на C++20.

30% не пишут юнит-тесты

Эксперт Мэтт Годболт (Matt Godbolt) считает, что это очень печальная статистика.

Ещё 32% используют Google Test для написания юнит-тестов.

55% используют CMake для сборки

Принято считать, что в мире C++ какой-то стандартной системы для сборки нет. Однако больше половины пользователей предпочитают CMake.

Ещё в топе — Makefile и Visual Studio.

Где почитать ещё?

Исследование C++ 

Исследование JavaScript

Исследование Python

Исследование Go

Исследование Kotlin

Источник: Блог JetBrains