Я понял, что не публиковал тут шаблон EditorConfig для Android-проектов. Недавно обновил его под последнюю версию IDE — добавил парочку новых настроек и поправил порядок и заголовки в файле, чтобы они соответствовали изменениям в UI.

Что за EditorConfig?

EditorConfig — это спецификация файла конфигурации для кодстайла. Самые общие опции типа indent_size и insert_final_newline заложены в саму спецификацию. Прелесть в том, что эти опции понимают все редакторы кода, а значит будет меньше головной боли когда открываешь файлы проекта в VS Code или ещё где-то. Некоторые IDE поддерживают специфичные для них настройки кодстайла, например, все настройки относящиеся к IDEA начинаются с ij_ и настроить там можно практически всё то же самое, что и в Settings > Code Style.

И всё-таки зачем его использовать?

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

1️⃣ Самое очевидное — пошарить кодстайл между всеми разработчиками. Добавляете файлик .editroconfig в корень проекта и теперь у всех разработчиков одинаковые настройки IDE и автоформатирование работает одинаково (можно ещё EditorConfig в required plugins добавить, чтобы убедиться, что плагин у всех точно включен и настройки не будут игнорироваться).
Такой способ шаринга кодстайла лучше чем распространение через Export/Import архива с настройками или добавление файлов из .idea/ в репозиторий. Во-первых, потому что формат EditorConfig не зависит от версии IDE. Во-вторых, вносить изменения в него куда проще, а проигнорировать их не получится (как в случае с распространением через архив).

2️⃣ Более гибко настраивать кодстайл. К примеру, вы решили, что ненавидите wildcard-импорты и запрещаете их использование в проекте. При этом в скриптах .kts хочется их разрешить. Как это сделать средствами IDE? Не знаю. А в EditorConfig можно определять разный кодстайл для разных файлов и каталогов. Для .kt один кодстайл, для .kts немного другой. Для res/*.xml один, для остальных XML-файлов другой.

3️⃣ IDE-независимость. Я там чуть выше сказал забыть про шаринг настроек между IDE, но всё-таки упомяну, что во Fleet (новом редакторе от JetBrains) формат EditorConfig вообще считается основным форматом для настройки кодстайла. Помимо IDE формат EditorConfig понимает, например, ktlint. То есть это отличная точка синхронизации для любых инструментов, которые хотят знать про кодстайл проекта.

Ок, продал, но зачем нужен шаблон?

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

Шаблон не стоит использовать "as is", проверьте, что настройки не противоречат кодстайлу проекта. Если ваша IDE уже настроена в соответствии с кодстайлом, проще всего экспортировать ваши настройки в формат EditorConfig и посмотреть насколько сильно они отличаются от шаблона (для этого можно предварительно отсортировать строки и взять diff).

#tooling

Чего ждать от Java ближайшие 10 лет?

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

⭐️ Project Loom

Цель: добавить легковесные(виртуальные) потоки

Самая заметная фича со времён Stream API. Большинство проектов получат огромный буст от внедрения виртуальных потоков. Что важно — с минимальными изменениями в коде.

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

⭐️ ZGC / Shenandoah

Цель: сборщик мусора с минимальными паузами

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

Для большинства проектов это не актуально. Сборщик по умолчанию G1 отлично работает и становится лучше с каждым релизом.

⭐️ Project Panama

Цель: упростить работу с native кодом и памятью за пределами JVM

Проект делится на 2 направления:

🔹 Новый вариант JNI

Нужен для работы с библиотеками, которые не написаны на Java, и вряд ли когда-нибудь будут: работа с графикой, манипуляции с ОС, сетью и тд. Текущий JNI очень старый, работает медленно и не безопасен. Поэтому пишут новый:)

🔹 Работа с памятью за пределами JVM

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

⭐️ Project Amber

Цель: упростить язык, добавить новые конструкции

Самые "народные" фичи, которые часто попадают в обзоры и статьи: var, текстовые блоки, records, pattern matching, sealed классы, string templates и так далее.

Что-то получается хорошо, что-то не очень. Где-то много пафосных разговоров про data-oriented programming. Есть странные фичи, вроде упрощения написания Hello world.

⭐️ Project Leyden

Цель: ускорить время старта Java программ

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

⭐️ Project Valhalla

Цель: оптимизировать работу с данными

Здесь так же два направления:

🔹 Создать value types — объект с полями и методами, работа с которым идёт как с примитивом:
✅ Передаётся по значению
✅ Компактно лежит в памяти
✅ Не может быть null

🔹 Создать общую схему работы с примитивами, объектами и value types, избавить разработчика от мыслей про boxing/unboxing

❓ А когда будет готово?

Плохая новость — реализации всех проектов растягиваются на десятки лет.

10 лет — не преувеличение. Лямбда-выражения в java обсуждались с 2004 года, а увидели свет только в 2014.

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

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

Продолжаем разбирать прикольные уязвимости. На этот раз у нас уязвимость в библиотеке Jetpack Navigation. Суть ее в том, что она позволяет стороннему приложению открыть любой экран атакуемого приложения и передать туда параметры. Круто звучит? Вот и я так думаю. А Google не считает это уязвимостью и после получения репорта нам ответили, что "поправят документацию". Не будь как Google, исправляй ошибки в своих приложениях! И знай чем грозит использование библиотеки Navigation.

штош: Джейк сдержал слово и аргументированно рассказал, почему не стоит использовать toolchain-ы в ваших билдах! Приглашаю к ознакомлению 🧑‍💻
https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/

decomposer - Gradle плагин для декомпиляции Java bytecode от Jetpack Compose Compiler Plugin. В результата получается Java класс. Позволит понять вам что происходит под капотом и погрузиться глубже

#tooling @compose_broadcast

Список ресурсов по безопасности Android

AboutLibraries автоматически собирает все зависимости и лицензии Gradle-проекта и предоставляет легко интегрируемые UI-компоненты для сред Android и Compose. Делает это во время компиляции и предлагает простые API для их визуализации в приложении. Никаких накладных расходов во время выполнения. Сильное кэширование. Поддерживаются любые gradle-зависимости. Поддерживает Kotlin Multiplatform.

AboutLibraries на GitHub: https://github.com/mikepenz/AboutLibraries
Платформа: Android
⭐️: 3.5K

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

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

Минутка духоты: На самом деле обёрнутое значение не всегда будет инлайниться. Принцип работы похож на (un)boxing примитивов. Но это тема для отдельного поста.

1️⃣ Объявление собственных примитивов

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

За примером далеко ходить не надо — UInt и другие беззнаковые типы в Kotlin это inline-классы. Но вот где действительно разгулялись с примитивами, так это в Jetpack Compose. Цвета раньше передавались либо как Int в формате 0xAARRGGBB, либо как класс, теперь же Color это inline-class. Получаем все удобства класса и легковесность примитива. Кроме цветов есть ещё Dp, Size, Offset и т.д. (для типов, состоящих их нескольких свойств, например Size, под капотом используется упаковка данных в один примитив). Так что, если вас как и меня мучил вопрос почему нет ничего страшного в том, что мы на каждой рекомпозиции создаём объекты, это потому что на самом деле никаких объектов нет.

2️⃣ Дешевые enum'ы

Помните совет гугла заменять enum'ы на Int с аннотацией @IntDef? Потом Jake Wharton рассказал, что R8 умеет оптимизировать enum'ы и мы выдохнули.
Так вот если всё-таки нужно заменить enum на примитив, inline-классы помогут обойтись без сомнительных конструкций с @IntDef, которые опираются только на стат. анализ.

Примеры этого подхода, опять же, можно посмотреть в Compose: TextAlign , TextOverflow и LineBreak. Да, к сожалению, при таком подходе в when нет проверки, что покрыты все ветви, но на этот компромисс я готов пойти.

3️⃣ Обёртки

Наиболее частое применение inline-классов — создание обёрток над другими типами, чтобы:
👉 Получить более строгую типизацию. Например, чтобы не ошибиться когда у нас много ID-шников одинакового типа у разных сущностей. Или более явно указать в сигнатуре функции, что "этот параметр должен быть не какой угодно строкой, а именно номером телефона". Это работает благодаря важному свойству inline-классов, что их нельзя сравнивать с другими типами. Попытка такого сравнения выкинет ошибку на этапе компиляции.
👉 Сузить скоуп для утилитарных функций. Вот есть у нас номер карты пользователя в формате строки. Мы хотим делать с этим номером много всякого: форматировать группами по 4 цифры, вывести маскированный номер карты вида *1234 и т.д. Можно сделать кучу экстеншенов на String, которые будут видны когда нужно и когда не нужно, а можно завести inline-класс и явно определить что с ним можно делать.
👉 Добавить новые свойства обёртнутой сущности. Добавить @Immutable ко спискам? Запросто.

Напоследок пример где и типизация важна, и новые свойства добавляются. Помните как в onMeasure нам прилетают Int'ы, с которыми нужно работать исключительно через утилитарный класс MeasureSpec? В Compose вместо этого прилетает один класс Constraints и мы сразу, без похода в документацию, понимаем набор действий, который можно совершать с этим классом. Ну не красота ли?

Make drozer great again

Не могу пройти мимо этой новости, спустя 7 долгих лет произошло обновление любимого многими инструмента drozer

Теперь он поддерживает python3! И очень надеюсь на добавление нового функционала.

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

Пока что не поддерживается запуск на Windows и есть определенные проблемы со стабильностью в ряде случаев, но все равно это по настоящему возрождение легенды :)

#drozer #android

Я веду бэклог постов и в рубрике #насмотренность следующий пост должен был быть про функции-конструкторы. Но иногда нужно просто немного подождать и кто-то сделает все за тебя :) На хабре вышла статья "Конструкторы-самозванцы в Kotlin", где автор описывает варианты мимикрии функций под синтаксис конструктора и в каких случаях это может понадобиться. Спасибо ему! Мне остаётся только досыпать примеров использования в Open Source.

1️⃣ Функция-конструктор
Это просто функция высшего порядка, написаная с большой буквы, которая внутри создаёт и возвращает инстанс класса.
Полезно, если хочется дать возможность "создавать инстанс интерфейса". Объявляете интерфейс, кладёте рядом с ним функцию с таким же названием и готово, даже импортировать её отдельно не придётся. Реализация интерфейса при этом может остаться приватной. Вызовы MutableStateFlow и MutableSharedFlow в корутинах, Json в kotlinx.serialization это всё вызовы таких функций. Это помогает уменьшить API-surface, а значит упростить использование API.
Ещё один вариант использования — вместе с inline-классами. Например, у Size в Compose конструктор помечен как internal, а "создание инстанса" происходит через функцию c двумя параметрами.

2️⃣ Перегрузка Companion.invoke
Причины применения указанные в статье (контроль над созданием объекта, создание пула объектов, кэширование и т.д.) классные, но нужны примеры. Пример контроля над созданием объекта можно увидеть в PlatformVersion в ktor. То есть в зависимости от определённой логики мы можем мы либо создаём инстанс, либо возвращаем какой-то существующий.
Но часто применение более банальное — вместо вторичного конструктора. Тут я могу только догадываться почему не используется вторичный конструктор, но примеры такого применения можно увидеть в RuleSet из detekt и MockEngine из ktor. Иногда применение вместо вторичного конструктора можно оправдать тем, что логики для подготовки параметров конструктора очень много. Например в SpriteAnimation из korge (игровой движок на Kotlin).

3️⃣ <Context>.invoke()
То же самое, что предыдущий вариант, но для случая когда нужно ограничить применение invoke контекстом.
В дикой природе этот вариант я не встречал, но сам автор даёт пример применения в yatagan и рассказывает в статье зачем это понадобилось. После выхода context parameters (следующая итерация context receiver'ов) этот вариант будет выглядеть приятнее.

🤔 Как относиться к такому?
Я часто вижу хейт в сторону подобных конструкций, мол мимикрия и переопределение операторов это зло, так как порождает неявность. Да, на самом деле вызывается не конструктор, а функция, но что в этом плохого если она выполняет ту же смысловую нагрузку? Уверен, многие с чистой совестью вызывают MutableStateFlow и им не важно, что под капотом. Главное следовать принципу наименьшего удивления. Если что-то выглядит как конструктор, оно и работать должно как конструктор.
Накидайте аргументов если я не прав!

#kotlin

https://github.com/ShreyashKore/wonderous_compose

Я уже упоминал этот проект как-то раз. Очень красиво и работает на всех возможных платформах! (не надо только пробовать веб версию на мобильных устройствах)
А теперь там появились встроенные карты на всех платформах - стоит изучить 😉

#Предложка #Libs #Compose

Compose Color Preview

Наверняка вы замечали, что при работе с Compose Multiplatform в IntelliJ IDEA нет привычных превью цветов в панели слева. Одним из решений этой проблемы является Compose Color Preview — плагин, автором которого является один из подписчиков канала. Однозначно лайк 👍

Для тех, кому лень или некогда смотреть, хорошая статья на Хабре: https://habr.com/ru/companies/kts/articles/814363/

Fleet - официально IDE для KMP разработки

#kotlinconf #ide #fleet