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

Недавно я стал клиентом Generali Srbija (страховая компания) и пользователем их замечательного мобильного приложения. Зарегистрировался, авторизовался и... приложение моментально закрывается когда я его открываю.

Первая догадка — возможно приложению не понравилось, что я отклонил все запросы пермишенов, включая доступ к микрофону, совершению звонков и контактам. Это оказалось ни при чём. Тогда я решил проверить есть ли что-то полезное в logcat (см. скриншот). Логи, которые выводят мой токен, хэш пароля и персональные данные, а так же сообщения типа "Я тут" пропускаем. В конце видим, что приложение само вызывает System.exit(0), написав перед этим "Это настоящая загрузка".

Дальше остаётся только декомпилировать APK через APKTool и поиском найти нужное сообщение лога. Отгадка оказалась простой — если у пользователя обнаружен root, приложение просто закрывается. Кто-то скажет, что это не user-friendly решение, но я парирую цитатой одного мудрого разработчика: "Пользователь всё равно найдёт как сломать приложение, поэтому мы решили не обрабатывать краевые сценарии".

А теперь представьте как было бы сложно понять что происходит, если бы не было никаких логов, приложение бы закрывалось не через System.exit и была включена обфускация! Поэтому если вы не уверены в стабильности приложения, оставляйте логи и отключайте обфускацию. Так пользователи смогут сами подебажить приложение и отправить вам на почту результаты своего исследования, останется только пофискить. Можно было бы ещё флаг debuggable=true выставить, но Google Play такое не пропустит ☹️

Ещё один вывод — если вы ищете работу в Сербии, Generali Srbija отчаянно нуждаются в разработчиках, просто пока этого не поняли.

#security

В общем, я ВНЕЗАПНО понял, что уже вообще-то почти декабрь, а значить вот-вот начнётся новый Advent of Code. Забираю обратно все свои подтрунивания над коммунальными службами, которые "не были готовы к зиме". Я тоже не был готов.

Для новых подписчиков – я уже третий год организую "клуб решал Advent of Code" и мы 25 дней решаем задачи и страдаем получаем положительные эмоции. В этом году организацию начал очень поздно, так что скорее всего состав решающих будет достаточно камерный :)
Заходите в канал @aoc_club и зовите друзей!

Всем привет! Самое время вкатываться в ежегодный Advent of Code! 🎄

Advent of Code — это адвент-календарь, в котором с 1 по 25 декабря тебя будут ждать 25 задач. Задачи связаны в одну рождественскую историю, и решение каждой из них поможет нам спасти Рождество.

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

Advent of Code — это про фан, а не про самое оптимальное решение. Не нужно быть чемпионом ICPC и сертифицированным вертельщиком деревьев, чтобы решать задачи. Нет требований к алгоритму по времени/памяти и ограничений по используемым языкам — их можно вообще не использовать. Всегда находятся люди, которые решают задачи в Excel :)

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

Присоединяйся и зови друзей!

Этого ещё никто не видел, вы первые 👀
Теперь принятие архитектурных решени и проектирование нового функционала для Ktor происходит публично в репозитории ktor-klip!

Первый KLIP на очереди – официальное решение для DI. Все желающие могут посмотреть какой планируется дизайн и повлиять на него на ранней стадии!
Если вы используете Ktor в качестве клиента, эти изменения пока никак вас не коснутся, они направлены на то чтобы упростить использование DI при написании серверов.

А здесь в комментариях можно похоливарить про "зачем ещё один DI?", "почему не Koin?", "будет compile-time валидация графа?". Хотя если прочитать документ, это вопросы отвалятся 😀

#ktor

Пробежавшись по постам за год я понял, что безнадёжно отстаю от трендов. Во-первых я ни разу не поругал дядюшку Боба, а во-вторых ни разу не бомбил про Gradle (предупреждение о сломанном релизе не в счёт). Негоже уходить в новый год с такими пробелами, поэтому буду исправляться. Хотя бы частично.

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

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

Речь, конечно, про lazy API. Это прям штука про которую нужно знать сразу, как только начинаешь делать в Gradle что-то сложнее чем объявление зависимостей. Но не стоит терять бдительность после прочтения документации. Допустим, ты знаешь, что нужно использовать tasks.named("javadoc") , а tasks.getByName("javadoc") в большинстве случаев не нужно, так как этот вызов создаёт запрошенный таск на месте вместо того чтобы возвращать ленивый провайдер. Но что если нужно сразу сконфигурировать этот таск? Вроде всё просто:

tasks.named("javadoc") { enabled = false }

А если хотим сконфигурировать все таски определённого типа? Можно написать так:

tasks.withType<Javadoc> { enabled = false }

И это будет ошибка. Если в withType передать лямбду, то под капотом вызывается withType<T>().all(configure), а all в моменте создаёт все таски в коллекции. Правильно будет делать так:

tasks.withType<Javadoc>()
    .configureEach { enabled = false }

Хорошо, а если хотим выключать таски по какому-то условию? Например, по флажку в gradle.properties:

tasks.withType<Javadoc>().configureEach {
    enabled = properties["tasks.javadoc"].toBoolean()
}

Ой-ой, опять ошибка! Нужно использовать findProperty("..."). Почему? Посмотрите документацию к getProperties... а, погодите, там ничего полезного не написано... тогда документацию к Project (скриншот снизу). Этот метод ищет "свойства" в более широком смысле — смотрит на поля convention'ов, Gradle-экстеншены, поля внутри Project, все таски, extras, причём не только для текущего проекта, но и для всех родительских. И все это собирается в одну большую Map'у. Привести это может к довольно неожиданным проблемам.

Так что в новом году желаю вам выбирать всегда правильные APIшки (и не только в Gradle). С Рождеством и Новым Годом :)

#gradle

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

Во-первых, конечно, есть уже какое-то чувство усталости от бесконечных статей про SOLID, Clean Architecture и прочие новшества типа ЖЦ Activity.
А во-вторых... ИМХО, проблема всех статей с объяснением SOLID в том, что они пытаются каждый принцип объяснить как можно проще, на элементарных примерах. Чтобы человек посмотрел и сказал: "так SOLID это оказывается просто!". Но в итоге получается, что до применения SOLID было три строки кода, а после стало 10 классов и у читателя возникает только отторжение. Ну потому что дичь. До "рефакторинга" было коротко и понятно.

По сути основная цель SOLID – подстелить себе соломку на будущее, чтобы вносить изменения в существующий код было не "мучительно больно", а хотя бы просто "больно". А чтобы это понять нужно либо самому испытать что получается, когда принципы не соблюдаются, либо посмотреть на реальные примеры из практики, которые должны прям откликаться в сердечке. Такие примеры найти безумно сложно, даже в оригинальных статьях (S O L I D) примеры не всегда удачные. Поэтому, остаётся только пробовать приземлять SOLID на свой опыт, прочитав первоисточник с подробным объяснением принципов и проблем, которые эти принципы призваны решать.

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

Документация меня предупреждала, но я всё равно туда зачем-то полез...

Кто-то скажет, что это очень неудачный нейминг, а это на самом деле гениальное решение! Четыре адреса, как-бы символизируют четыре октета из которых состоит IPv4.

P.S. Два адреса из-за java.net.InetSocketAddress и ещё +1 из-за обёртки в Ktor'овский тип, ну и название локальной переменной +1 🥲

Когда я только начал работать в команде Ktor, я поставил себе "внутреннюю цель" сделать так чтобы использовать Ktor на Android было максимально удобно. И вот в Ktor 3.2.0 благодаря моим правкам Android-проекты перестали собираться 🤡

Причина максимально глупая — пробелы в названиях полей. Возникает логичный вопрос: "Зачем?". А просто потому что когда-то я увидел подобный подход для компановки сообщений в Dokka и подумал "вау, как выразительно получается".
Перед тем как применить это в коде я подумал может ли это что-то сломать, и пришёл к выводу, что нет. Это ж константы, они при компиляции заинлайнятся и вообще использований не будет, что может пойти не так? То что D8 споткнётся о пробел я, конечно, не предусмотрел.

Так что вы знаете кого винить, что не получается обновиться на новый Ktor. А я пойду думать как на CI гонять проверки, что проекты с Ktor собираются с D8, R8 и ProGuard.

P.S. Workaround нашёлся, но достаточно страшный. Через AGP Transformation API вырезать проблемные поля 🙈

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

Опять внезапный анонс (в этом канале бывают другие?)

Завтра начинается 14-й сезон Podlodka Android Crew. В этот раз сезон тема сезона — Мобильный System Design. Так получилось, что я в четверг буду выступать с докладом про архитектуру Ktor Client. Расскажу как с точки зрения архитектуры устроен клиент Ktor и как подключаются плагины.

Будет интересно, если:
👉 Используете Ktor (или не используете, но хотели бы попробовать)
👉 Хотите сделать свою библиотеку расширяемой через плагины
👉 Хотите узнать как происходит проектирование и разработка новых фичей в Ktor

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

🎟 Бесплатные билеты
Если вы хотели попасть на подлодку, наверняка уже купили билет, но если вдруг нет, то есть шанс получить его бесплатно. Условия простые:
– участвуйте только если у вас есть возможность посетить все (или почти все) сессии на следующей неделе
– оставьте к этому посту комментарий с любым числом до 23:00 МСК сегодняшнего дня
– если в этом же комментарии поделитесь болью или зададите любой вопрос касательно Ktor в целом или доклада в частности, шанс выигрыша увеличится в два раза
– после 23:00 случайно будут выбраны два победителя

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

Билеты достаются @aslapov и @Ilichev_pavel. Поздравляю, скоро приду в личку :)

А вот и запись доклада, как обещал.

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

Если вдруг решаете Advent of Code, присоединяйтесь к лидерборду, (а можно даже к каналу где мы вместе решаем и обсуждаем AoC).
Кстати, как вам Advent of Code в этом году?

IDEA Community и Ultimate слились во едино. Благодаря этому IDE плагин для более удобного написания серверов на Ktor теперь будет доступен всем, а не только пользователям Ultimate.