Прямо давно ничего не писал, пора исправлять.

И Кстати, через 25 минут начинается keynote Google I/O 2023:

https://io.google/2023/program/396cd2d5-9fe1-4725-a3dc-c01bb2e2f38a/

Весь Google I/O был пронизан тематикой AI.

Гениальную шутку встретил в инетах на эту тему
«I/O is deprecated, it's now Google A/I»

То, что напрямую касается Android прогера - в новой AS Hedgehod (Canary) поселился Studio Bot - ИИ помощник. Правда US only пока что.

Google мощно продвигает Jetpack Compose как правильный способ делать UI.

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

О том как правильно дебажить Compose рассказывали вчера на Google I/O:

https://www.youtube.com/watch?v=Kp-aiSU8qCU

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

Paging3 библиотека по идее делает что надо, но по факту придется завязываться на нее на всех слоях - от data до UI.

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

Итого возник вопрос - в проекте используете Paging(1/2/3) либу, или пишите сами ручками?

Игрался с плагином в AS, который показывает статистику по строкам кодам, файлам и т.д. в проекте.

В небольшом side проекте статистика показала, что суммарно строк кода в тестах больше, чем в файлах, которые тесты покрывают 🙂

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

В рамках google I/O был доклад как делать data layer:
https://io.google/2023/program/373ef4ca-1e69-4af4-ac21-f51b967c4742/

Не до конца согласен с разделением на Repository и DataSource.
DataSource по факту является таким же репозиторием. .
Предлагают реализовать DefaultTaskRepository, реализующий интерфейс TaskRepository.
При этом реализация внутри зависит от конкретных реализаций DataSource (локального хранилища и сети).

Я бы спрятал оба DataSource также за TaskRepository и DefaultTaskRepository использовал как прокси репозиторий.
В таком случае можно использовать любой TaskRepository и не менять логику основного репозитория. Например, если захочется переехать на другую БД или сделать in-memory зачем-то.

Впечатлило как #Compose из коробки поддерживает темную тему.

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

А Key Promoter (плагин для AS) непхол, когда выполняешь какой-то экшн, подсказывает что для него есть хоткей.

Rainbow Brackets.
Классный плагин для AS, который подсвечивает скобки разным цветом.

Может звучать странно, но на самом деле визуально сильно помогает.

Смотрел примеры по навигации и поддержки разных форм-факторов на Compose.

Офф. пример JetNews:
https://github.com/android/compose-samples/tree/main/JetNews

Они используют NavComponent для верхнеуровневой навигации. Дальше, на home screen во viewModel держат текущий uIState:

data class HasPosts(
val postsFeed: PostsFeed,
val selectedPost: Post,
val isArticleOpen: Boolean,
…

В зависимости от размера экрана строят нужный compose.

По сути и лента и detailed page существуют в рамках одного «экрана» и на уровне UI решается как через Composable строить представление.

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

Или есть варианты интереснее?

Не самое очевидное применение Github Copilot.

В проекте есть дата классы на уровне общения с сервером. Надо было создать Sample Json из класса (в некоторых тестах, где то уже лежат разные части такого примера jsona).

Зашел в Data class, написал final val DemoResponseJsonDemo = и Copilot сам написал пример Jsona.

В следующем data классе достаточно было написать только final, чтобы Copilot понял что хочу пример Jsona.

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

Не могу не поделиться удобнейшей и бесплатной (в базе) тулзой Calendly.

Можно быстро выбрать удобные тебе слоты, скинуть ссылку и всё - профит. Человек сможет выбрать удобное для него время в его тайм зоне.

Раньше для работы с траффиком в приложении использовал charles или fiddler. Начиная с Flamingo Android Studio позволяет добавлять правила в Network Inspector 🔥

https://betterprogramming.pub/how-to-use-the-android-studio-network-inspector-to-debug-and-optimize-your-apps-network-requests-22f98dd02349

Есть ios, есть android, для одного свифт, для другого котлин.
Есть армия фронтедщиков на JS, им дали React Native, чтобы они могли кроме мобильной версии сайта сделать чуть более нативное приложение.
Есть kotlin разработчик, ему дают kotlin multiplatform, KMP compose (https://www.jetbrains.com/lp/compose-multiplatform/) и т.д., чтобы он мог запустить свое андроид приложение например в вебе или на ios.

А вот зачем вот тут флаттер нарисовался :) ?
Для кого он?

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

По Андроид разработке в РУ сегменте есть Android Broadcast, StartAndroid и другие.

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

По-этому решил слегка переформатировать формат контента.
Хочу попробовать писать НЕ только про Android разработку в техническом плане, а в целом про разработку продукта и то, с чем сталкиваюсь, как решаю и что делаю.

Например.
Прохожу system design interview, можно сделать выжимку что это, как прошло и зачем это вообще надо.
Искал долго баг, можно рассказать как искал и почему долго.

Получается из инфо канала про анроид пробую перейти в формат практических примеров в контексте разработки.

В примере о том, в каком формате буду писать упомянул System Design Interview.
Так это не с проста. С начала этого года с разной степенью интенсивности ищу новый проект.

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

Очередным этапом должен был быть system design interview. При этом в почте часть текста про него была синим (типа ссылка, которую я заметил после того как зафейлил секцию). Так вот я думал что system design это про архитектуру приложения и вот это всё. А вот нет. Оказалось, что я раньше проходил всякие архитектурные секции, а system design нет.

Тот собес я зафейлил с фидбеком "Хоть кандидат всё сделал нормально и всё работает, но вопросов мало задавал". После провала я пошел изучать в чем суть. Оказывается system design интервью очень сильно заточен на то как кандидат понимает задачу, спрашивает уточняющие вопросы и тд.

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

Для подготовки юзал ютуб канал проекта ByteByteGo и просто всё что находлось по запросу.

Главный вывод, который я сделал, то что к каждой секции надо готовиться, чтобы хотя бы понимать что от тебя хотят. Хотя это не панацея. Собеседовался в Glovo и там провалил последнюю секцию про "Cultural alignment". Хотя готовился. Об этом тоже расскажу, но потом.

Сейчас делаю мобилку для https://mapmagic.app/
Первая версия уже даже в закрытой бетке, скоро катнем на всех.

Изначально был вопрос на чем ехать, прототип даже на react native сделали.
Посмотрел на windy.com - у них в мобилке capacitorjs.com.

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

ReactNative, Capasitorjs by Ionic - все про то, что если ты хорошо знаешь JS, то тебе не надо учить новый язык и можешь еще и мобилку написать. Не совсем супер нативную. Могут быть вопросики если нужно что-то не самое распространенное и тд.

Для себя пока отвечаю так.

Кроссплатформенное решение хорошо, когда
- Надо протестить MVP, сделать очень быстро и очень на коленке
- Уже есть команда крутых JS разработчиков, у которых есть время сделать мобилку
- Продукт подразумевает мобилку в основном как витрину (airbnb/booking/facebook)

Так как по-моему мнениею MapMagic про аппку как самостоятельный продукт и я не JS разработчик, то выбор пал на натив. А чтобы сократить время релиза (или увеличить, если не повезет 😄 ), всё что не касается UI делаю на kotlin multiplatform.

Есть Compose Multiplatform, когда можно и UI сделать на ios. Но пока что кажется, что в его текущей реинкарнации сделать нативный SwiftUI - более правильное решение.