По Андроид разработке в РУ сегменте есть 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 - более правильное решение.

Пробовал много разных "заметочных" программ - и evernote и маковские заметки и просто google docs 🙂
Пока что остановаился на Notion.

- Он умеет базовые таблички с формулами держать в заметках, что удобно, когда надо рассчеты вести
- Довольно простой и понятный интерфейс
- Удобные прилки на компе и на телефоне, но есть и веб морда
- Можно шарить отдельные страницы
- Есть разные темплейты для страниц
- Можно собрать мини-внутренний портал быстро и без боли

В общем для "личных" целей вообще пушка.
Пробовал вести в нем разработку, показалось не удобно, тут Jira, YouTrack и др. лучше справляются.

А вы чем пользуетесь?

На собесах бывают спршивают очень спацифичные вещи. Тут я даже не про дефолтный "как устроен hashmap". Однажды спросили - когда устанавливается аппка что происходит на устройстве.

Я не фанат under-the-hood движения. Я больше про горизонтальные знания. Например можно знать что такое и уметь применять корутины, но не знать в деталях как они работают. Зато знать что такое Кафка :)

Иногда глубокие знанеия требуются, но на моей практике редко. Если потребуется - можно разобраться. ИМХО куда важнее развить вдобавок софт скилы, знать что такое микросервисы на беке и иметь представления как писать на JS.

Начали за #KMP обсуждать.
Сейчас на проекте пробую максимально переиспользовать все что только можно.
При этом UI оставить нативным пока.
Полезности, которые для себя нашел:

- Decompose, подход который позволяет факту всё от даты до ViewModel написать кросплатформенное
- Список либ, который поддерживают КМП
- Kermit + crashlytics позволяет сделать универсальное логирование в КМП слое.

Еще момент с КМП - скорее всего kotlin будут писать Android разработчики.
Напишут, проверят что работает, зальют... и сломают iOS respective build 🙂

Нужен видимо процесс проверки всех платформ, в идеале автотестами.

С конца прошлого лета делал приложеньку для сервиса построения маршрута Mapmagic (раньше activetrip, manymap).

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

Отзывы (в личку и\или в маркет), замечания, вопросы привествуются:
https://play.google.com/store/apps/details?id=app.mapmagic.android

Из интересного:
- бОльшая часть аппки на #KMP. Ииспользовал Decompose чтобы логически написать viewModel (aka Component) один раз, а UI плагином прицепить на уровне платформы. Это дает теоритическую возможность вообще всю логику, в том число подготовку UI моделей сделать один раз.

- Карты на #maplibre+#maptiler сделаны на уровне платформы, а вот подготовка geoJson для отображения - кросплатформенно.

- Когда необходима платформозависимая реализация, то на уровне домена лежит интерфейс, например AnalyticsDelegate. Он в свою очередь реализован на уровне платформы и прокидывается куда необходимо через DI.

- Для #DI в КМП использован #Koin, а на уровне платформы его можно соединить и с Hilt/Swinject

- По ходу разработки нашел удобный сборник либ для КМП

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

https://play.google.com/store/apps/details?id=app.mapmagic.android

Смотрел статью про модуляризацию проекта:
https://developer.android.com/topic/modularization/patterns

В видео рассказывают как модули должны быть максимально независимы друг от друга и много разного правильного. Потом говорят «а пример смотрите тут».
Заходишь в пример… А там схема… Д - диссонанс.

Официальная позиця Гугла в архитектуре это 3 слоя

- UI
- Domain (опционально)
- Data

(с) https://developer.android.com/topic/architecture

Далее, если есть желания модулизировать всё, предлагается разбивать соответствующий слой на features.

(c) https://developer.android.com/topic/modularization

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

(c) https://habr.com/ru/companies/yandex/articles/584756/

Я вижу это как использование в «молодом» приложении 3 основных модуля UI/Domain/Data. Далее при развитии проекта, найме разработчиков и развитии кодовой базы - при необходимости - выделять целые самостоятельные части в features.

А как вы делаете на проекте и почему\зачем?

Какое-то время назад активно пилил Wesplit - аналог Splitwise и Splid.
Сам им пользуюьсь, но времени активно его пилить сейчас нет.

По-этому решил выложить его к open source - и людям посмотреть полезно и глядишь - развитие обретёт.

https://github.com/dryaz/wesplit - можно смотреть тут, PRы открывать, вопросы задавать и всё в таком роде.

В iOS apple позволяет даже если это российский аккаунт получать оплату от пользователей. (Как выводить - вопрос другой).

А вот Гугл вообще не даст пользователю заплатить если аккаунт разработчика РФ.

Перевел апку на европейский аккаунт. Чтобы заработала оплата после переноса надо только добавить сервис аккаунт в консоль и перепривязать Google play.

Раньше было, что в iOS "Просто всё работает", а в Android "Есть нюансы".

А недавно поменял обратно iOS на Android и встретил обратный кейс.
Есть разные кейсы использования NFC помимо оплаты - транспортная карта например.

Так вот такие NFC кейсы работают после разблокироваки аппки из коробки. В iOS надо открыть приложение, а Android сам поймет что от него хотят 🪄

Уже почти год как работаю в Revolut. Изначально читал прямо противоположные отзывы - сейчас понимаю почему, но мне все нравится :)

Если вдруг кто подумывает сменить проект или просто ищет работу, пинганите, постоянно нанимаем в разные команды.