Поиск первой работы, часть 2: способы поиска.

1️⃣ Откликаться на все платные и бесплатные стажировки, они регулярно бывают у крупняков типа яндекса, тинькоффа, рэдмэдробота, домру и прочих. Конкурс будет жёсткий, харды нужны сильные. Скорее всего надо будет твёрдо знать Java Core, алгоритмы, коллекции и уметь в юнит-тесты.

2️⃣ Откликаться на все вакансии на всех сайтах с поиском работы: Junior Android Developer, Android Developer. И мониторить все телеграм-чаты с поиском работы в вашей сфере.

Лайфхак: можно воспользоваться промтами в гугле:
"site:hh.ru | site:<...> | site:<...> android developer"

Легче всего попасть на "галеры" – проектную разработку в какую-нибудь студию, которая на аутсорсе или аутстаффе клипает проекты для всех подряд. У них обычно требования минимальные. Там будет не "милая приятная айтишечка", но для первого опыта подойдёт.

3️⃣ Сам я работу джуном когда-то нашёл через линкедин. Просто искал там всех андроид-разработчиков senior/lead уровней и писал им в холодную "возьмите меня в команду, я хороший".

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

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

Заметьте – не компания выложила стажировку и он на неё откликнулся, а он сам инициировал стажировку в компании своей активностью. Берите пример. Можете даже попробовать усилить этот кейс и придумать оффер со стажировкой самим, и присылать его компаниям, например: "Я бесплатно постажируюсь у вас по ГПХ 3 месяца, потом устраиваюсь к вам и 3 месяца будет испытательный со сниженным окладом, а потом будет оклад по рынку."

4️⃣ Отдать резюме на вычитку кому-нибудь, кто имеет отношение к найму: лиду, hr-у. Соберите от них обратную связь и внесите исправления.

5️⃣ Участвовать в опенсорсе, активно делать туда пулл-реквесты. Вас будут ревьюить, там можно познакомиться с кем-нибудь и попроситься в команду. Аналогичный подход с участием в хакатонах. + всё это пойдёт в резюме и тоже будет полезно.

Ещё раз: готовьте лоб и ломайте им стены.
Стены поддадутся. Я и сейчас регулярно слышу о кейсах успешного устройства джунами. Да, не так часто, как раньше, но слышу.

#android #работа #советы

@andrdevnotes | androidmentor.ru

Ответ на вопрос подписчика

Как правильно настраивать инструменты обфускации?
В своём проекте заюзал в конфиге gradle флаги
isMinifyEnabled и isShrinkResources, в итоге у меня просто отвалился сетевой клиент после сборки

#android #вопросы #лайфхаки

Ответ на вопрос подписчика

Создал Scaffold, внутри которого вложил TopAppBar. Настроил поведение бара на enterAlwaysScrollBehavior(rememberTopAppBarState()). При скроллинге TopAppBar скрывается и при этом весь внутренний контент Scaffold перерисовывается снова и снова, нагружая экран. Делал все по документации

#android #вопросы

Ответ на вопрос подписчика

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

#android #вопросы #работа

Ответ на вопрос подписчика

Мне интересно, возможно ли без пересоздания активити сменить тему (setTheme()) и дарк и лайт режим? Xml разумеется. И можно это сделать только уже на compose?

#android #вопросы

Ответ на вопрос подписчика

Как должен выглядеть хороший пет-проект в портфолио? Что в нем должно быть?

#android #вопросы #работа

Ответ на вопрос подписчика

Интересно общее мнение по поводу compose)😁
стоит ли например делать сейчас акцент\изучать compose

#android #вопросы

Убеди его сказать "Да"

Для доступа к опасным действиям в android-системе, например выходу приложения в интернет или записи файлов, нужно запросить у системы разрешение.

Есть два основных вида разрешений:

1️⃣ install-time – те, что можно просто выдать через манифест: например, разрешение на интернет.

2️⃣ dangerous (runtime) – те, о которых надо напрямую попросить пользователя. И вот о них поговорим поподробнее.

Запрос runtime разрешения представляет из себя показ соответствующего системного диалога. Это значит, что просто повесить listener на его кнопки и узнать, когда пользователь нажал «Да», «Нет» или «Нет и больше не спрашивать» нельзя. А узнать о том, что в итоге выбрал пользователь, можно только в соответствующем системном коллбэке.

Если вы просто покажете системный диалог с запросом разрешения и не будете слушать коллбэк, то при нажатии на «Да» диалог скроется и всё. А вам надо, чтобы пользователь прошёл дальше по флоу, который раньше был для него закрыт из-за отсутствия разрешения.

Прежде, чем показывать системный диалог, стоит внятно объяснять пользователю, зачем вам нужно разрешение, чтобы:

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

б) не выглядеть в глазах Play Store негодяями, запрашивающими разрешения с дурной целью

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

Если пользователь скажет "Да", то пускаете его дальше по флоу. Если "Нет" – не пускаете.
А вот если скажет "Нет, и больше не спрашивать" – вам надо продумать, что делать в таком случае. Ведь с этого момента вы больше не сможете запросить разрешение у системы, его можно будет выдать только вручную в настройках. Если без этого разрешения можно дальше пользоваться приложением – смиритесь, если нет – объясните пользователю, зачем ему теперь нужно идти в настройки, и что там нужно сделать.

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

#android #лайфхаки

@andrdevnotes | androidmentor.ru

Как Flow меня предал

Решил я недавно заменить синхронный код, длинными макаронами оплетающий приложение, на красивую удобную асинхронщину с Flow. Сказано – сделано.

Было: макароны с проксированием информации через интерфейсы со всех концов приложения в пару мест, где и производятся целевые действия.

interface Interactor {
    fun onCameraMove(mapState: MapState)
}

interactor = parentFragment.checkInstance()

interactor?.onCameraMove(mapState)

interface MapCameraMovable {
    fun onCameraMove(mapState: MapState)
}

override fun onCameraMove(mapState: MapState) {
        (currentFragment as? MapCameraMovable)?.onCameraMove(mapState)
    }

Стало: я сделал репозиторий с Flow, который асинхронно меняется в разных местах приложения, а в целевых местах он обзёрвится. Удобно и без бойлерплейта.

private val channel = Channel<MapState>(Channel.BUFFERED)
private val flow = channel.receiveAsFlow()

override fun observe(): Flow<MapState> = flow

override suspend fun once(): MapState? = flow.firstOrNull()

override suspend fun update(newMapState: MapState) = channel.send(newMapState)

Да вот только работало оно как-то странно: то правильно, то неправильно. Начал я копать:

Из-за того, что эмиты во флоу шли довольно часто, сначала подумал, что буфер у флоу переполняется. Но нет, дело не в этом. А дело было в том, что я, к своему стыду, невнимательно читал документацию:

fun <T> ReceiveChannel<T>.receiveAsFlow():

One element will be emitted to one collector only.

В итоге у меня в приложении вместо отправки одних и тех же данных нескольким подписчикам шла гонка: какой-то подписчик первый успевал получить данные, а остальным они не доставались.

Мораль: слушаете Flow в нескольких местах – используйте MutableSharedFlow.

#android #лайфхаки #рефакторинг

❇️ 5 простых лайфхаков для крутого кода ❇️

Поделился 5 простыми приёмами, которые помогут повысить качество вашего кода.

Приятного просмотра! 🚀

Мне будет приятно, если поддержите лайками и комментариями 👀

#android #видео #лайфхаки #рефакторинг

https://youtu.be/FJo4cRPJPMk?si=mHLUK_oL9_KcpLwV

❇️ 3 простых способа сделать разную вёрстку для планшетов и смартфонов ❇️

Отвечаю на вопрос подписчика: как правильно верстать под разные устройства.

Приятного просмотра! 🚀

Мне будет приятно, если поддержите лайками и комментариями 👀

https://youtu.be/VYQD9URfKVw?si=HsRtJDV1mGfXISHD

#android #видео #вопросы #лайфхаки

@andrdevnotes | androidmentor.ru

А какие вопросы по теории/практике в коде сейчас вас волнуют?

Над какой проблемой в коде сейчас больше всего паритесь?

Пишите в комментариях, разберем 👇🏻

Ответ на самую частую проблему запишу в видео 👀

#android #вопросы

Прежде, чем отвечать на ваши вопросы, решил пробомбиться с одной очень популярной нынче темы.

https://youtu.be/QSuKXT5zBEw?si=bK_EBMcBsM9TZOWl

#android #видео #вопросы

@andrdevnotes | androidmentor.ru

Ответ на вопрос подписчика

Вопрос по архитектуре: в каких случаях нужно создавать отдельную ViewModel и репозиторий? Возьмём за пример простенькое приложение, где есть три основные фичи: просмотр изображений, фильтрация их по категориям и добавление их в избранное.

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

Но если и для избранного и для фильтрации и тд использовать только одну ViewModel, не нарушает ли это single responsibility principle?

Ответ: Single responsibility principle – принцип единственной ответственности. Чтобы ему следовать, нам надо сначала понять, а какая ответственность у вьюмодели и репозитория?

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

Ответственность репозитория: это управление источниками данных, их обработка и предоставление наружу в обработанном виде. Репозиторий ходит в сеть, кэширует, достаёт из кэша, маппит сетевые модели в доменные, обрабатывает ошибки, при необходимости маппит их в бизнесовые ошибки. Репозиторий отвечает за какой-то определённый кусок логики, например UserRepository или ImagesRepository.

Ответственность вьюмодели: вьюмодель – это прослойка между бизнес-логикой и определённым экраном. То есть вьюмодель не к фичам привязана, а к экрану. Если у вас на экране есть и добавление в избранное и фильтрация, значит и во вьюмодели это будет. Но вьюмодель делает это не сама, она обращается в вашем случае к конкретному репозиторию и получает из него результат. А репозитории вы уже проектируете как вам удобно: Например FavoritesRepository и FilterRepository, если хотите эту логику отделить. Или можете сделать один ImagesRepository, если не хотите отделять.

И запомните: однажды вам захочется сделать печально известную SharedViewModel и пошерить её между несколькими экранами. Это приведёт вас на путь, наполненный запутанным и нерасплетаемым спагетти-кодом, куче костылей и конфликтов. Не делайте так. Один экран – одна вьюмодель.

#android #архитектура #вопросы

Запись на менторство:
@andrdevnotes | androidmentor.ru

Привет, друзья!

Разбирая ваши запросы, заметил, что много практических вопросов по коду. Пришла в голову идея: устроить стрим с разбором ваших проектов.

Формат: вы до 19 мая присылаете мне ссылку на репозиторий со своим проектом. Я из них отбираю 5 проектов на разбор.

И я с 20 до 31 мая провожу один или больше стримов (в зависимости от объёма проектов) с подробным разбором и советами по рефакторингу.

Если у вас получится присутствовать на стриме – отлично, сможем лично пообщаться по проекту. Нет – посмотрите в записи.

Стоимость: 1990р за 1 проект.

Как вам идея?

Офигеваю от того, как быстро вы отвечаете 🙂

Раз желающих много, проведу несколько стримов. Один стрим = 3-5 проектов
Проекты кидайте в личку: @ilia_a_popov

Первый стрим будет 21-го мая в 19-00