Не так давно Яндекс опубликовал свой DI Yatagan - типо аналог Dagger 2.
Теперь Яндекс опубликовал свой DI Scout - типо аналог Koin/Kodein.

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

P.S. Глянул доку Scout. Ничо так. Сразу концепция скоупов предлагается. Лайк.

Визуал решает

Любопытная история. Миша Рубанов (Mobile Head в Dodo) сделал твит с вариантом нового дизайна Dodo Pizza и собрал кучу реакций:
https://twitter.com/akaDuality/status/1712843425727349118

Во-первых, в комменты набежали многие популярные ребята. А Аркадий Иванов вообще набросал на Compose макет 😂️️️️
Во-вторых, куча комментов, что дизайн гавно. Ну, собственно, это обычная история. Обычно все эксперты по дизайну и умеют критиковать дизайн.

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

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

Вариант нового дизайна Dodo Pizza.

Кто такое сможет сделать на View? А на Compose? Как вам кажется, сложно?

Совет 4. Давай фидбек сразу

Продолжаем цикл Советы собеседующему.

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

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

Почему это классно?

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

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

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

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

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

#собес #interview

Совет 5. Не прикидывайтесь объективным

Последний мой совет из серии “Советы собеседующему”

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

Когда мы проводим интервью, то мы стремимся объективно и беспристрантно оценить кандидата. Раньше я подходил именно так к собеседованию. Я старался превратиться в самого объективного человека на свете. Но потом я понял, что:
- Во-первых, это нереально. Мы все люди разные, у всех есть свои перекосы в разные области. Даже в институте большая разница, к какому преподавателю вы попадете на сдачу экзамена. Кстати, это одна из причин почему биг техи проводят по 4-5 секций интервью. Потому что даже когда вы решаете алгоритмические задачи (казалось бы объективная штука), вас все равно оценивает конкретный живой человек, который с вами общается по ходу интервью. И компания хочет получить 3-4 разных отзыва от разных специалистов о кандидате.
- Во-вторых это и не нужно! После собеседования конкретно вам (или вашей команде) придется работать конкретно с этим человеком. Поэтому зачем строить из себя что-то искуственно, когда вы можете обратить внимание помимо чисто технических ответов то, на сколько вам комфортно общаться. Нет ли какого-то негатива или неудобства.

Как применять этот совет?
Помимо правильности технических ответов, отмечайте как идет диалог, не прячьте это специально. Если диалог идет туго - оставьте себе пометку. Если идет классно - тоже оставьте пометку. Учитывайте это при решени о найме. Отвечайте себе на вопрос “Хотел бы я работать с этим человекам в команде?”.

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

#собес #interview

Учимся у тачек

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

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

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

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

Вот такая аналогия. Что скажете?

#architecture

Консоль на Compose

Недавно узнал про проект Джейка Mosaic

Это либа, которая билдит консольный UI с помощью Jetpack Compose! Внезапно, да?)

Но что это реально означает? Это означает по сути, что Compose - это универсальная концепция (рантайм + компилятор)! Компилятор для работы с деревьями и свойствами — это то ядро, которое может быть использовано для любого дерева на любой платформе!

Сейчас мы знаем, что Compose становится мультиплатформенным. И это типо не новость. Но! Какую важную мысль я хочу сказать. Это что Compose - это не просто универсальный инструмент для рисования UI. Это универсальный инструмент для работы с деревьями!

#compose

Kodein в Android. Что за зверь и как его готовить

Опубликовано мое выступление с Mobius! В нем я рассказываю:
- что такое DI Kodein, основное API
- как Kodein может работать в KMP и Compose
- как мы писали тесты на целостность DI графа (чтобы предотвратить падения в рантайме)
- как мы работаем со скоупами в Kodein

Моя любимая часть это тесты на целостность графа, кому интересно перематывайте сразу на 22:49
Там я рассказываю, как мы боремся с тем, что в Kodein нет compile-time проверок зависимостей.

https://www.youtube.com/watch?v=ey_RLEltKpo

#di #kodein #video

Как мы делали сложный экран на Compose

Мой коллега, Дима Максимов, написал крутую статью про то, как мы делали непростой экран на Compose.

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

Но есть очень интересные штуки:
- Скролл + снаппинг, сделанный в LazyColumn ручными анимированием скролла
- Анимированное раскрытие элемента через translationY

Все кто любит смотреть реальные кейсы на Compose - вэлкам почитать статью.

#compose

Meta сделала Threads полностью на Compose

Ну ок не полностью, а на 90%

they built over 90% of Threads using Compose.

Но 90% это почти полностью, я считаю.

В статье Richard Zadorozny рассказывает, как они в Meta сделали с нуля приложение Threads за 5 месяцев.

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

Но у нас другое, наш экран в Дринките покруче любых фичей из Threads :) И это я сейчас не шучу.

Что не вошло в те самые 90%?

Видео и медиа пикер.

While Compose did mostly everything Threads engineers needed it to, it was still easy for them to interoperate with Views as necessary. They used Views for Threads’ videos and the media picker that’s available when creating a new post.

Ну с видео согласен, мы тоже для видео использовали View.

В общем такие жирные компании как Meta и их истории успеха с Compose это точно мощно!

И кстати, Threads не тормозит особо.

#compose #google

DataStore vs Proto DataStore

На днях выбирал, где лучше хранить определенные данные, и решил проверить, какая разница у DataStore (c Json серриализацией через kotlinx) vs Proto DataStore по быстродействию. Я был уверен, что Proto уделает обычный DataStore раза в 2. Потому что так показывают разные бенчмарки по сериализации.

Но на мое удивление я не смог увидеть разницу по перфомансу при чтении данных из DataStore и Proto DataStore. Замерял на данных размера 20-30 КB, так и на данных 2-3 MB. Не заметил разницы.

Докопаться до истины пока не смог. Может основное время уходить на IO операции/переключение контекста и т.д. Может еще по какой-то причине.

Прочитал еще раз оригинальные посты от гуглеров. Там они, кстати, в преимущества Proto DataStore нигде не указывают скорость серриализации. Они говорят про размер данных и про type safety, как преимущества. Ну ок.

Ну что ж, будем использовать DataStore c Json серриализацией через kotlinx. По крайней мере на данном этапе в них ранзицы я не нашел, если смотреть со стороны производительности. А работать с файлами ".proto" то еще удовольствие, хоть и есть плагин для Androit Studio.

#datastore #protobuf #persistence

Первая статья на HackerNoon

https://hackernoon.com/5-practical-tips-for-conducting-effective-interviews

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

Но в последний раз я решил попробовать HackerNoon. По правде сказать, не без "помощи" BetterProgramming 🙂 Потому что они мою статью ревьювили больше недели. Я плюнул и решил, не Medium'ом едины, надо попробовать HackerNoon. Это популярный ресурс, интересно посмотреть, как там вообще.

Итак, статья: 5 Practical Tips for Conducting Effective Interviews
Помните, я писал свои советы интервьюерам в этом накале? Так вот, я решил это собрать в единый текст, и получилась неплохая статья!

Если кто-то из вас есть на HackerNoon, то подписывайтесь 😉

#article

Асинхронный map

Хочу поделиться таким приемчиком, как асинхронный map.

Когда мы делаем map для списка, то у нас трансформация будет происходить последовательно. Если эта трансформация не супер быстрая, то общий маппинг может стать не оптимальным.

Как это можно исправить? Через асинхронный map. Вот такая функция (asyncMap) запускает map каждого элемента асинхронно.

При этом:
- несмотря на то, что трансформации выполняются асинхронно, очередность элементов сохраняется
- трансформации выполняются в дочернем скоупе. Structured Concurrency работает, беспокоится не надо. Это означает, что отмена скоупа/джобы корректно отменят и все трансформации.

На примере выше, если бы мы сделали обычный map, то он завершился бы за 6 секунд (1000 + 3000 + 2000). Если мы сделаем asyncMap, то за 3 секунды.

#coroutines #map

Давайте накидаем в комменты, почему iOS-разработчики не любят DI?

Как выполнить код раньше всех?

Сегодня я расскажу, как выполнить что-то раньше всех в Андроид приложении. Или позже всех.

Первое, что надо знать, что при запуске Android приложения (при создании процесса) запускаются все Content Provider'ы. App Initializers тоже работают на контент провайдерах, так что они работают по такому же принципу.

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

Для этого у Content Provider есть поле initOrder. Это просто число Int, которое определяет порядок запуска контент провайдеров. Чем выше initOrder, тем раньше будет запуск вашего Content Provider.

Например, если вы используете библиотеку Firebase Performance, то она добалвяет от себя разные контент провайдеры:
FirebasePerfProvider - имеет initOrder = 101,
FirebaseInitProvider - 100.

Если вы укажете initOrder = 200 у вашего провайдера, то он будет выполнен раньше этих 2х. Если укажете 0, то будет выполнен самый последний.

Если initOrder не указан, то по умолчанию используется значение 0. И если несколько контент провайдеров имеют одинаковый initOrder, то порядок вызова не детерменирован. Он может отличается от версии к версии.

Итого. Если вы хотите быть раньше всех, то установите в initOrder максимальное число Int = 2147483647. Если хотите быть точно последними, то установите минимальное = -2147483648.

Погнали, сделаем что-нибудь раньше всех!

#contentprovider #initializers

В чем разница между ссылкой на метод и лямбдой?

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

Но в чем разница с лямбдой?

Давайте посмотрим на пример выше. Мы создали ссылку reference и лямбду lambda. У нас был объект Mapper с методом map, но потом неожиданно (так делать неорошо) мы меняем значение mapper.

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

Почему так происходит?

Ссылка на метод - сохраняет ссылку на метод в момент объявления ссылки (в этот момент создается объект типа функци)

А лямбда - при объявлении лишь создает объект функции, но не сохраняет сам mapper, а захватывает ссылку на mapper, чтобы потом использовать при выполнении метода.

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

А лямбда выполнит метод и будет использовать ссылку на аргументы (на новый mapper).

P.S. На скриншотике обрезался коммент у использования reference. Там должен быть:
// Map 1 Mike, Map 1 Jane

#kotlin

invalidate

Время идет. Уже все изучают Compose. А как работает старый добрый invalidate так многие и не знают.

Давайте расскажу кратко. А потом если тема пойдёт, то расскажу подробнее.

invalidate() - это метод View, который вызывает перерисовку (onDraw) вьюхи. Это примерно все знают. Но как это происходит? Когда? Если я вызову несколько раз подряд invalidate то перерисуется несколько раз? 🤔

Сейчас расскажу кратко путь от invalidate до реальной перерисовки вьюхи:

1. Вызываем invalidate у вьюхи

2. Вьюха вызывает у своего родителя invalidateChildInParent

3. И так invalidateChildInParent вызывается идя вверх по дереву 👆 пока не дойдем до ViewRootImpl - главного родителя нашей иерархии вьюх (она, кстати, сама вьюхой не является, а больше типо менеджера всего)

4. ViewRootImpl через класс Choreographer (мой любимчик 💙) подписывается на следующий сигнал VSYNC. Или, простыми словами, подписывается на следующее событие отрисовки фрейма.

5. Не путайте 🛑 Не просто кладет сообщение в мейн лупер, чтобы он выполнился как только сможет. А именно подписываемся на следующую отрисовку кадра.

6. Следующая отрисовка кадра произойдет как правило не позднее 16.6 мс с момента подписки.

7. Когда приходит VSYNC, то Choraographer вызывает метод doFrame и там по очереди обрабатывает запросы на: инпут, анимации, инсеты и, наконец, проход дерева и отрисовку.

8. И далее вниз по дереву спускается команда draw 👇и вызывается наш колбек onDraw

9. Наша вьюха перерисовалась 🥳

Easy!

#android #view #ui #performance

R.drawable.ic_close

Немного юмора в воскресный вечерок. Нашел на просторах твиттера.

#joke

Опыт судейства на хакатоне

На прошедших выходных я был судьей на хакатоне Урбатрон. 👨‍⚖️

Я оценивал трек “Единая образовательная система школ дополнительного творческого образования” 🎻

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

Всего было 14 команд и 1 победитель. Битва была нешуточная 🤼

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

- 🗣Первая и главная мысль - питчинг это всё. Здесь недостаточно показать код, который выполняется быстрее других по времени. Здесь нужен крутой проект. То как команда питчит свой проект — это минимум 50% успеха, а то и 60-80%.

- 🎁 Если одна команда сделала что-то сложное и технически крутое, но не смогла это понятно рассказать на питчинге. А вторая команда наполовину сделала простое решение, но которое бьет четко в проблему, и за 10 минут понятно как оно выглядит и работает, то больше “очков” получит от меня вторая команда.

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

Я искренне “болел” за команды, которые включили в свой проект мобильное приложение (но без предвзятости). Я смотрел каждое и запускал у себя код. Но таких было всего 2 команды из 14.

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

Был крутой опыт, я видел как на протяжении выходных 14 команд просто херачили, как не в себя, и реально старались сделать что-то крутое!