Javanese Online

Пять стадий написания LayoutManager 1. 😨 Быть такого не может, чтобы ранее такую штуку никто не делал! 2. 😡 Нет, ну почему никто не запилил?! 3. 🤬 Может, как-нибудь попроще, без менеджера? 4. 😢 *гуглинг в гитхабе* 5. 😌 Ладно-ладно, пойду писать. Итого: Flow (раскладывает в строчку, переносит на новую при необходимости) с возможностью ограничить количество строк и показать специальную вьюшку «ещё 100500». https://github.com/Miha-x64/FlowLayoutManager/

Концентрированная мудрость Ежедневно я пишу код, коплю опыт и делаю выводы. Каждые десять лет у меня выкристаллизовывается ровно одно идеальное, чётко сформулированное и неопровержимое утверждение. Впервые я делюсь своим арсеналом, накопленным за всю сознательную жизнь. • Глобальные переменные — сила. Легко дебажить, сразу видно всё состояние приложения, как на ладони. Нет необходимости передавать какие-либо параметры в функции. • Полиморфизм — мракобесие: разобраться в нём — это как выбрать себе подходящий гендер из 50 вариантов. • Вариативные дженерики нужны только для написания диссертаций на эту тему. • В рестухе коды состояния излишни. Всегда отвечай 200 Ок, ошибку же можно вернуть в теле ответа. • Главное топливо для работы — кофе. На завтрак, обед и ужин. • Решение абсолютно любой проблемы можно копипастить со стека. Люли там неглупые, сообщество активное, а значит, и код 100% рабочий и качественный. • Самая важная языковая фича — деструктор. Особенно в джаве! Правильно написанный конструктор в руках умелого прогера превращается в мощный деструктор.

Весь путь андроид разработки с 2015 по сегодняшний день за 4 часа: в гостях Миша @Harmonizr https://www.youtube.com/watch?v=LG_C-igSTP8

Поболтали с Оганнесом за жизнь.

Давно я на собесы не ходил… Во вторник пойду, наконец!

О, у меня ж ревью на днях вышло. Немного про ProGuard rules, чучуть про анимации, капельку про навигацию, ну и всякое по мелочи.

Приятно видеть, что плагин востребован и набирает обороты. Сложность в том, что фичи придумываются быстрее, чем я успеваю их реализовывать. По самым грубым подсчётам у меня 20 фич, почти все можно улучшить, ещё с десяток хочется сделать. Поэтому есть два предложения: 1. Тем, кто хочет вкатиться в плагиностроение, предлагаю парное программирование. Тебе — бесценный опыт, всем нам — улучшения плагина, мне — потенциальные пуллреквесты в будущем. 2. А если вдруг здесь есть люди с опытом плагиностроения (преимущественно инспекций), то я хотел бы заполучить кусочек вашего опыта, можно даже не бесплатно. Пишите в личку, кому интересно.

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

Кстати, у всем известного нам @Harmonizr вышел апдейт его IDE плагина, который в текущей версии обладает крайне важной и нужной функцией, а именно чистит ваши SVG от всякого лишнего мусора. Установить плагин можно по ссылке - https://plugins.jetbrains.com/plugin/12690-mike-s-idea-extensions/versions/stable/148933

Скоро начнём!

Всем привет! Мы вместе с Алексеем Гладковым (YouTube-канал Mobile Developer) проводим онлайн-дискуссию про то, как выбрать идеальный SDK для Android-приложений и существует ли он, какие SDK — must-have для Android, а когда лучше обойтись без интеграции внешних библиотек. В ходе беседы соберём мнения тех, кто широко использует SDK для себя, кто разрабатывает их для других и кто предпочитает использовать только свои решения. 30 ноября в 17:00, регистрация здесь: https://qonversion.io/sdk-meetup Приходите!

Всем привет! Мы вместе с Алексеем Гладковым (YouTube-канал Mobile Developer) проводим онлайн-дискуссию про то, как выбрать идеальный SDK для Android-приложений и существует ли он, какие SDK — must-have для Android, а когда лучше обойтись без интеграции внешних библиотек. В ходе беседы соберём мнения тех, кто кто широко использует SDK для себя, кто разрабатывает их для других, и кто предпочитает использовать только свои решения. 30 ноября в 17:00, регистрация здесь: https://qonversion.io/sdk-meetup Приходите!

Дополнил ❤️

Решают ли DI-фреймворки больше проблем, чем создают? В моём канале с мемами много шуток про то, что в спорах между Dagger 2 и Koin на самом деле побеждают фабрики. Так вот, это не шутки. Я считаю что DI-фреймворки в android – это подражание спрингерам, дань моде, следствие хронического ООП-клинкода головного мозга и просто переоценённое излишество. Жёсткий наброс вкинут, погнали подкреплять его аргументами. Что вообще решают DI-фреймворки? DI фреймворки в основном решают очень простую проблему – как написать код, который собирает объект из зависимостей. Это очень простой код, который легко написать и потом читать и дебажить. Есть ли в этом вообще проблема? Ну да, кажется, что это "бойлерплейт". Слишком скучно и неинтересно. Но когда скучный код был проблемой? Проблемой обычно бывает как раз "интересный" код. Его надо прочесть, понять, переспать с ним, вдуматься, ошибиться в нём пару раз. Со скучными фабриками проблемы нет. Я готов их писать каждый день. Что если вы не такой устойчивый к рутине? Ладно, допустим, рутина написания фабрик для вас – это проблема. Настолько большая, что вы не представляете, что можете отказаться от DI-фреймворка и начать писать всё руками. Но вы пробовали? В Kotlin, благодаря интерфейс- и проперти-делегатам неплохо получается писать код фабрик кратко. И при этом вам и вашим джунам не придётся учить доменный язык Koin или язык аннотаций Dagger. Серьёзно, я помню джуновскую дрожь в коленках от словосочетания Inherited subcomponent multibindings в документации Dagger. Я честно говоря до сих пор не понимаю, какие задачи стоят перед теми кто в такое упарывается. Да и в простых случаях помню как смотрел как баран на новые ворота и пытался понять, а какой магией зависимости прилетают ко мне в конструктор? Почему иногда я вешаю @Inject надо конструктором и всё работает, а иногда мне выплёвывают портянку красного кода где ни слова о том, что мне просто нужно поставить ещё одну такую же аннотацию и всё снова будет работать? Ух, аж передёрнуло от волны флешбеков. Koin я начал изучать на более сознательном этапе карьеры, но всё равно надо было посидеть поразбираться, чем их модули и компоненты отличаются от Dagger и Ninject. А так был бы только Kotlin, только хардкор прагматичный подход. Какие проблемы не решают DI-фреймворки? При этом мы расплачиваемся более высоким порогом входа только за решение тривиальной задачи "собери из спичек домик". На более сложные, смежные с DI вопросы типа навигации иили передачи данных из одного скоупа в другой, восстановления графа зависимостей, жизненного цикла зависимостей, кооперативного очищения скоупов зачастую во фреймворке готового ответа нет или ответы в лучшем случае medium rare. Эти проблемы приходится решать самому, и тут есть 100500 решений и в каждом проекте будет немного по-другому. А это задача сложная, из тех что на подумать. Хорошо если у вас в команде будет условный Владимир Тагаков, который всё вам настроит и будет бить по рукам за неправильное использование и срезание углов. Но в современной разработке мы часто слишком мало думаем, у нас нет возможности лечь в гамак как Рич Хикки и думать о наилучшем способе показать пользователю промку с акцией на чёрную пятницу. Сложная проблема + сложный инструмент + ограниченные ресурсы = неоптимальные решения, которые стрельнут через пару лет, треснув под грузом нового кода как плохо залитый фундамент.

Чёт все новости — про Компоуз, Хилт или компайл-тайм рефлекшен в Котлине. 30 октября в 10:00 Мск будет бесплатная онлайн-конфа. В кубернетесах я ничего не понимаю, а вот про Loom, Graal Native Image и Java 17 послушаю с интересом.

Дано: проект с Gson и смешанным кодом на Java и Kotlin. Задача: пилить фичи, добавлять эндпоинты. Хотелки: 1. Не иметь геттеров. Из существующего джавового кода они выглядят многословно. 2. Поля должны быть финальными. Не хочу нежданчиков в виде случайных присваиваний. 3. Нужны фоллбэки. Если опциональное поле не приходит, пусть у него будет удобное значение — emptyList() или "". Вариант описывать данные на котлине с @JvmField я отмёл: многословно. За что боролись, об то и навернулись. Вместе с @SerializedName может и в строчку не уместиться. Остаётся джава, поля объявил в таком виде: @SerializedName("user_name") public final String userName = ""; Проблема первая: для такой конструкции у поля генерируется ConstantValue и инлайнится в места использования. В итоге Gson успешно переписывает финальные поля, но их уже никто не читает. Случай описан выше. Выход — таки унести присвоения в конструктор, как в B и C. Проблема вторая: опциональное поле может прийти null. Тогда я хочу оставить фоллбэк. Есть GsonBuilder#serializeNulls(), но мне нужно наоборот: не десериализовать нуллы. Настройки такой нет, конский ReflectiveTypeAdapterFactory копипастить ради одного ифа не хочется. В итоге написал JsonReader, который эти нуллы пропускает.

Фишка в том, что я в детстве невнимательно читал JLS. Поле считается константным, если оно финальное и инициализировано константным выражением в месте объявления. Про static здесь ни слова. В итоге класс А после декомпиляции выглядит так, как показано на картинке. B и C (E, F) этому правилу не подчиняются, поэтому все поля честно используются. D тоже «нормальный» — котлин решил не повторять «странностей» джавы, потому что сейчас уже ясно, что такая конструкция может использоваться для десериализации.

Какие классы ведут себя эквивалентно, а какие принципиально отличаются? Только не надо говорить, что у них имена разные и у Kotlin-версий есть метадата, речь про практическую разницу ;)