Подкаст от деды в IT:
Стажировки, джуны, начало пути в IT, менторство
Два андроид-разработчика:
Senior (я) и Lead (https://t.me/LeadTales)
обсудили, как нынче стать джуном и всё вокруг этого.
Пока только на Spotify, поэтому запускать под VPN.
Позже, думаю, перенесём на более удобный хостинг и выложим на другие сервисы.
Жду вашей обратной связи: что отозвалось, что стало неожиданным открытием, а с чем бы вы поспорили?
@andrdevnotes | androidmentor.ru
Стажировки, джуны, начало пути в IT, менторство
Два андроид-разработчика:
Senior (я) и Lead (https://t.me/LeadTales)
обсудили, как нынче стать джуном и всё вокруг этого.
Пока только на Spotify, поэтому запускать под VPN.
Позже, думаю, перенесём на более удобный хостинг и выложим на другие сервисы.
Жду вашей обратной связи: что отозвалось, что стало неожиданным открытием, а с чем бы вы поспорили?
@andrdevnotes | androidmentor.ru
Spotify
Стажировки, джуны, начало пути в IT, менторство... - Деды в IT | Podcast on Spotify
Listen to this episode from Деды в IT on Spotify. 00:20 - Intro. 00:20 - Приветствие. 00:54 - Что изучать и когда остановиться? 04:46 - Когда остановиться и прийти за помощью? 06:55 - Нужно ли учить Compose? 11:47 - Маркеры на собеседовании. …
👍6🔥3👏2❤1
Поиск первой работы, часть 1: подготовка.
📌Давайте сразу уточним: если вы ещё не работали андроид-разработчиком, значит вы ещё не являетесь джуном, а тем более миддлом. Какие бы у вас ни были навыки, вы пока только кандидат на первую работу. Если до этого у вас была работа в IT, особенно в смежных сферах (бэкенд / iOS) – это сильно сыграет вам в плюс.
Да, раньше войти в IT было проще, но это не повод руки опускать. Джуны с опущенными руками точно никому не нужны, и если вы отчаялись, не успев даже найти работу – в IT вам делать нечего.
Подход к поиску работы – такой же, как и раньше: набраться терпения и стучаться во все двери, параллельно качать навыки. У кого-то получается с первого раза, у кого-то с пятьдесят первого.
На ваш гитхаб работодатели смотрят. Проект желательно делать настолько сильный, насколько можете: Clean Architecture и MVVM, DI, REST с кэшированием, сможете в многомодульность – совсем хорошо. А если ещё и опубликуете и решите проектом какую-то мелкую реальную проблему – ещё круче (но это уже миддл-уровень).
Пройдите успешно одно-два мок-собеседования на джуна, убедитесь в наличии необходимых навыков. Обязательно укажите это в резюме.
С точки зрения абсолютного большинства работодателей, миддлом без опыта реальной работы стать практически невозможно, сколько навыки ни качай. Однако, если все остальные способы не сработают, я бы и на низкооплачиваемые вакансии миддла попробовал пооткликаться. Некоторые работодатели под миддлом подразумевают не уровень навыков, а самостоятельного разработчика. Теоретически, таковым может стать и джун, хотя результат его работы будет хуже – но, учитывая пониженный оклад, некоторые компании это может устроить.
В подкасте, кстати, тему поиска работы тоже обсуждали ;)
🔜 Следующим постом расскажу о том, где и как бы я искал свою первую работу.
#android #работа #советы
@andrdevnotes | androidmentor.ru
📌Давайте сразу уточним: если вы ещё не работали андроид-разработчиком, значит вы ещё не являетесь джуном, а тем более миддлом. Какие бы у вас ни были навыки, вы пока только кандидат на первую работу. Если до этого у вас была работа в IT, особенно в смежных сферах (бэкенд / iOS) – это сильно сыграет вам в плюс.
Да, раньше войти в IT было проще, но это не повод руки опускать. Джуны с опущенными руками точно никому не нужны, и если вы отчаялись, не успев даже найти работу – в IT вам делать нечего.
Подход к поиску работы – такой же, как и раньше: набраться терпения и стучаться во все двери, параллельно качать навыки. У кого-то получается с первого раза, у кого-то с пятьдесят первого.
На ваш гитхаб работодатели смотрят. Проект желательно делать настолько сильный, насколько можете: Clean Architecture и MVVM, DI, REST с кэшированием, сможете в многомодульность – совсем хорошо. А если ещё и опубликуете и решите проектом какую-то мелкую реальную проблему – ещё круче (но это уже миддл-уровень).
Пройдите успешно одно-два мок-собеседования на джуна, убедитесь в наличии необходимых навыков. Обязательно укажите это в резюме.
С точки зрения абсолютного большинства работодателей, миддлом без опыта реальной работы стать практически невозможно, сколько навыки ни качай. Однако, если все остальные способы не сработают, я бы и на низкооплачиваемые вакансии миддла попробовал пооткликаться. Некоторые работодатели под миддлом подразумевают не уровень навыков, а самостоятельного разработчика. Теоретически, таковым может стать и джун, хотя результат его работы будет хуже – но, учитывая пониженный оклад, некоторые компании это может устроить.
В подкасте, кстати, тему поиска работы тоже обсуждали ;)
#android #работа #советы
@andrdevnotes | androidmentor.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍3👌2🤝1
Next Level Dev
Подкаст от деды в IT: Стажировки, джуны, начало пути в IT, менторство Два андроид-разработчика: Senior (я) и Lead (https://t.me/LeadTales) обсудили, как нынче стать джуном и всё вокруг этого. Пока только на Spotify, поэтому запускать под VPN. Позже, думаю…
Привет, друзья!
Подкаст стал доступен на apple-подкастах и яндекс-музыке, залетайте по новой ссылке
#android #подкаст #работа #советы
https://veterans-in-it.mave.digital/
Подкаст стал доступен на apple-подкастах и яндекс-музыке, залетайте по новой ссылке
#android #подкаст #работа #советы
https://veterans-in-it.mave.digital/
mave · Деды в IT
Подкаст «Деды в IT»
Около IT-шная болталка двух мобильных разработчиков: https://t.me/andrdevnotes https://t.me/LeadTales
❤6🔥2😍1
Поиск первой работы, часть 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
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
❤8👏3🔥1🥰1
Ответ на вопрос подписчика
Создал Scaffold, внутри которого вложил TopAppBar. Настроил поведение бара на enterAlwaysScrollBehavior(rememberTopAppBarState()). При скроллинге TopAppBar скрывается и при этом весь внутренний контент Scaffold перерисовывается снова и снова, нагружая экран. Делал все по документации
#android #вопросы
Создал Scaffold, внутри которого вложил TopAppBar. Настроил поведение бара на enterAlwaysScrollBehavior(rememberTopAppBarState()). При скроллинге TopAppBar скрывается и при этом весь внутренний контент Scaffold перерисовывается снова и снова, нагружая экран. Делал все по документации
#android #вопросы
👌4🔥1👀1
Убеди его сказать "Да"
Для доступа к опасным действиям в android-системе, например выходу приложения в интернет или записи файлов, нужно запросить у системы разрешение.
Есть два основных вида разрешений:
1️⃣ install-time – те, что можно просто выдать через манифест: например, разрешение на интернет.
2️⃣ dangerous (runtime) – те, о которых надо напрямую попросить пользователя. И вот о них поговорим поподробнее.
Запрос runtime разрешения представляет из себя показ соответствующего системного диалога. Это значит, что просто повесить listener на его кнопки и узнать, когда пользователь нажал «Да», «Нет» или «Нет и больше не спрашивать» нельзя. А узнать о том, что в итоге выбрал пользователь, можно только в соответствующем системном коллбэке.
Если вы просто покажете системный диалог с запросом разрешения и не будете слушать коллбэк, то при нажатии на «Да» диалог скроется и всё. А вам надо, чтобы пользователь прошёл дальше по флоу, который раньше был для него закрыт из-за отсутствия разрешения.
Прежде, чем показывать системный диалог, стоит внятно объяснять пользователю, зачем вам нужно разрешение, чтобы:
а) увеличить вероятность того, что он согласится дать разрешение и продолжит пользоваться вашим приложением
б) не выглядеть в глазах Play Store негодяями, запрашивающими разрешения с дурной целью
Не надо запрашивать на старте приложения все разрешения, нужные вам в разных местах приложения. Лучше привяжите, например, запрос разрешения камеры к нажатию кнопки открытия камеры.
Если пользователь скажет "Да", то пускаете его дальше по флоу. Если "Нет" – не пускаете.
А вот если скажет "Нет, и больше не спрашивать" – вам надо продумать, что делать в таком случае. Ведь с этого момента вы больше не сможете запросить разрешение у системы, его можно будет выдать только вручную в настройках. Если без этого разрешения можно дальше пользоваться приложением – смиритесь, если нет – объясните пользователю, зачем ему теперь нужно идти в настройки, и что там нужно сделать.
Важно сделать путь пользователя удобным, а не раздражающим. Отлавливайте в коллбэках момент, когда пользователь выдаёт или не выдаёт разрешение, не оставляйте пользователя в подвешенном состоянии, не заставляйте нажимать на кнопку повторно. Пользователи будут вам за это благодарны.
#android #лайфхаки
@andrdevnotes | androidmentor.ru
Для доступа к опасным действиям в android-системе, например выходу приложения в интернет или записи файлов, нужно запросить у системы разрешение.
Есть два основных вида разрешений:
1️⃣ install-time – те, что можно просто выдать через манифест: например, разрешение на интернет.
2️⃣ dangerous (runtime) – те, о которых надо напрямую попросить пользователя. И вот о них поговорим поподробнее.
Запрос runtime разрешения представляет из себя показ соответствующего системного диалога. Это значит, что просто повесить listener на его кнопки и узнать, когда пользователь нажал «Да», «Нет» или «Нет и больше не спрашивать» нельзя. А узнать о том, что в итоге выбрал пользователь, можно только в соответствующем системном коллбэке.
Если вы просто покажете системный диалог с запросом разрешения и не будете слушать коллбэк, то при нажатии на «Да» диалог скроется и всё. А вам надо, чтобы пользователь прошёл дальше по флоу, который раньше был для него закрыт из-за отсутствия разрешения.
Прежде, чем показывать системный диалог, стоит внятно объяснять пользователю, зачем вам нужно разрешение, чтобы:
а) увеличить вероятность того, что он согласится дать разрешение и продолжит пользоваться вашим приложением
б) не выглядеть в глазах Play Store негодяями, запрашивающими разрешения с дурной целью
Не надо запрашивать на старте приложения все разрешения, нужные вам в разных местах приложения. Лучше привяжите, например, запрос разрешения камеры к нажатию кнопки открытия камеры.
Если пользователь скажет "Да", то пускаете его дальше по флоу. Если "Нет" – не пускаете.
А вот если скажет "Нет, и больше не спрашивать" – вам надо продумать, что делать в таком случае. Ведь с этого момента вы больше не сможете запросить разрешение у системы, его можно будет выдать только вручную в настройках. Если без этого разрешения можно дальше пользоваться приложением – смиритесь, если нет – объясните пользователю, зачем ему теперь нужно идти в настройки, и что там нужно сделать.
Важно сделать путь пользователя удобным, а не раздражающим. Отлавливайте в коллбэках момент, когда пользователь выдаёт или не выдаёт разрешение, не оставляйте пользователя в подвешенном состоянии, не заставляйте нажимать на кнопку повторно. Пользователи будут вам за это благодарны.
#android #лайфхаки
@andrdevnotes | androidmentor.ru
👍7🔥4👏1😁1
Как Flow меня предал
Решил я недавно заменить синхронный код, длинными макаронами оплетающий приложение, на красивую удобную асинхронщину с Flow. Сказано – сделано.
Было: макароны с проксированием информации через интерфейсы со всех концов приложения в пару мест, где и производятся целевые действия.
Стало: я сделал репозиторий с Flow, который асинхронно меняется в разных местах приложения, а в целевых местах он обзёрвится. Удобно и без бойлерплейта.
Да вот только работало оно как-то странно: то правильно, то неправильно. Начал я копать:
Из-за того, что эмиты во флоу шли довольно часто, сначала подумал, что буфер у флоу переполняется. Но нет, дело не в этом. А дело было в том, что я, к своему стыду, невнимательно читал документацию:
One element will be emitted to one collector only.
В итоге у меня в приложении вместо отправки одних и тех же данных нескольким подписчикам шла гонка: какой-то подписчик первый успевал получить данные, а остальным они не доставались.
Мораль: слушаете Flow в нескольких местах – используйте MutableSharedFlow.
#android #лайфхаки #рефакторинг
Решил я недавно заменить синхронный код, длинными макаронами оплетающий приложение, на красивую удобную асинхронщину с 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 #лайфхаки #рефакторинг
👍8❤3
❇️ 5 простых лайфхаков для крутого кода ❇️
Поделился 5 простыми приёмами, которые помогут повысить качество вашего кода.
Приятного просмотра! 🚀
Мне будет приятно, если поддержите лайками и комментариями 👀
#android #видео #лайфхаки #рефакторинг
https://youtu.be/FJo4cRPJPMk?si=mHLUK_oL9_KcpLwV
Поделился 5 простыми приёмами, которые помогут повысить качество вашего кода.
Приятного просмотра! 🚀
Мне будет приятно, если поддержите лайками и комментариями 👀
#android #видео #лайфхаки #рефакторинг
https://youtu.be/FJo4cRPJPMk?si=mHLUK_oL9_KcpLwV
YouTube
Как писать код чище
Даю советы о том, как писать код android-приложений на kotlin, которым вы будете гордиться.
Телеграм-канал: https://t.me/andrdevnotes
Обучение android: https://androidmentor.ru
Телеграм-канал: https://t.me/andrdevnotes
Обучение android: https://androidmentor.ru
🔥7🤩2👾2💯1🍓1
❇️ 3 простых способа сделать разную вёрстку для планшетов и смартфонов ❇️
Отвечаю на вопрос подписчика: как правильно верстать под разные устройства.
Приятного просмотра! 🚀
Мне будет приятно, если поддержите лайками и комментариями 👀
https://youtu.be/VYQD9URfKVw?si=HsRtJDV1mGfXISHD
#android #видео #вопросы #лайфхаки
@andrdevnotes | androidmentor.ru
Отвечаю на вопрос подписчика: как правильно верстать под разные устройства.
Приятного просмотра! 🚀
Мне будет приятно, если поддержите лайками и комментариями 👀
https://youtu.be/VYQD9URfKVw?si=HsRtJDV1mGfXISHD
#android #видео #вопросы #лайфхаки
@andrdevnotes | androidmentor.ru
YouTube
Вёрстка для планшетов
3 способа, как в android приложении удобно сделать разную вёрстку для планшетов и обычных смартфонов.
Телеграм-канал: https://t.me/andrdevnotes
Обучение android: https://androidmentor.ru
Телеграм-канал: https://t.me/andrdevnotes
Обучение android: https://androidmentor.ru
🔥10👍3🥰1
Практика over теория
Всегда и во всех дисциплинах и сферах ненавидел подход, при котором на первом этапе всё объясняется на совершенно синтетических, оторванных от реальности примерах. И только спустя какое-то время (и то не всегда) рассказывают, как и где это применять.
🚫 Проблема такого подхода для меня в том, что я плохо усваиваю вещи, пока не понимаю их смысла. Я могу заучить, не понимая, но я очень быстро это забуду.
✔️ Поэтому со своими менти я следую подходу "Practice first", с самого начала и до конца объясняя всю теорию на примере написания конкретного приложения. Да, я, разумеется, даю необходимые ссылки на статьи и книги для изучения, но мы сразу применяем изученное, реализовывая очередную фичу в приложении. Так приложение постепенно обрастает "мясом", а в мозге менти всё складывается на нужные полочки и закрепляется.
✔️ В самостоятельном обучении я советую следовать тому же принципу. Например – не пытайтесь просто выучить, как устроены корутины, не применяя их. Лучше придумайте несколько ситуаций, при которых в приложении понадобятся разные кейсы с корутинами, сначала попроще, потом посложнее. Попробуйте синхронизировать корутины между собой, позапускать асинхронно из разных мест и так далее.
Не понимаете смысла многострадальных inline и reified? Попробуйте написать экстеншн с дженериком
который будет проверять, является ли этот Context типом T, если да – возвращать его, а если нет – кидать эксепшн.
Так информация усвоится быстрее, да и на собеседовании, если вы ответите на вопрос, исходя из своей практики, это подействует на интервьюера куда сильнее, чем академический ответ из книжки.
#android #лайфхаки
@andrdevnotes | androidmentor.ru
Всегда и во всех дисциплинах и сферах ненавидел подход, при котором на первом этапе всё объясняется на совершенно синтетических, оторванных от реальности примерах. И только спустя какое-то время (и то не всегда) рассказывают, как и где это применять.
Не понимаете смысла многострадальных inline и reified? Попробуйте написать экстеншн с дженериком
fun Context?.checkInstance(): T
который будет проверять, является ли этот Context типом T, если да – возвращать его, а если нет – кидать эксепшн.
Так информация усвоится быстрее, да и на собеседовании, если вы ответите на вопрос, исходя из своей практики, это подействует на интервьюера куда сильнее, чем академический ответ из книжки.
#android #лайфхаки
@andrdevnotes | androidmentor.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
💯5👍3❤1😍1
Прежде, чем отвечать на ваши вопросы, решил пробомбиться с одной очень популярной нынче темы.
https://youtu.be/QSuKXT5zBEw?si=bK_EBMcBsM9TZOWl
#android #видео #вопросы
@andrdevnotes | androidmentor.ru
https://youtu.be/QSuKXT5zBEw?si=bK_EBMcBsM9TZOWl
#android #видео #вопросы
@andrdevnotes | androidmentor.ru
YouTube
Хватит учить Compose!
Если вы – начинающий андроид-разработчик, то прекратите учить Compose!
Телеграм-канал: https://t.me/andrdevnotes
Обучение android: https://androidmentor.ru
Телеграм-канал: https://t.me/andrdevnotes
Обучение android: https://androidmentor.ru
🔥7🫡3❤1
Ответ на вопрос подписчика
Вопрос по архитектуре: в каких случаях нужно создавать отдельную ViewModel и репозиторий? Возьмём за пример простенькое приложение, где есть три основные фичи: просмотр изображений, фильтрация их по категориям и добавление их в избранное.
Для каждой фичи нужно создавать ViewModel и репозиторий или раз все между собой тесно связано, лучше использовать один на все приложение, а отдельные создавать только для чего-то очень слабо связанного между собой.
Но если и для избранного и для фильтрации и тд использовать только одну ViewModel, не нарушает ли это single responsibility principle?
Ответ: Single responsibility principle – принцип единственной ответственности. Чтобы ему следовать, нам надо сначала понять, а какая ответственность у вьюмодели и репозитория?
На самом деле, на этот вопрос, как и на большинство вопросов по архитектуре, нельзя ответить однозначно, потому что подходы могут быть разные: кому-то нравится делать вьюху максимально пассивной, кому-то нет, но я вам расскажу подход, которому следую я, которому следуют в моей компании и которому я всех учу.
Ответственность репозитория: это управление источниками данных, их обработка и предоставление наружу в обработанном виде. Репозиторий ходит в сеть, кэширует, достаёт из кэша, маппит сетевые модели в доменные, обрабатывает ошибки, при необходимости маппит их в бизнесовые ошибки. Репозиторий отвечает за какой-то определённый кусок логики, например UserRepository или ImagesRepository.
Ответственность вьюмодели: вьюмодель – это прослойка между бизнес-логикой и определённым экраном. То есть вьюмодель не к фичам привязана, а к экрану. Если у вас на экране есть и добавление в избранное и фильтрация, значит и во вьюмодели это будет. Но вьюмодель делает это не сама, она обращается в вашем случае к конкретному репозиторию и получает из него результат. А репозитории вы уже проектируете как вам удобно: Например FavoritesRepository и FilterRepository, если хотите эту логику отделить. Или можете сделать один ImagesRepository, если не хотите отделять.
И запомните: однажды вам захочется сделать печально известную SharedViewModel и пошерить её между несколькими экранами. Это приведёт вас на путь, наполненный запутанным и нерасплетаемым спагетти-кодом, куче костылей и конфликтов. Не делайте так. Один экран – одна вьюмодель.
#android #архитектура #вопросы
Запись на менторство:
@andrdevnotes | androidmentor.ru
Вопрос по архитектуре: в каких случаях нужно создавать отдельную ViewModel и репозиторий? Возьмём за пример простенькое приложение, где есть три основные фичи: просмотр изображений, фильтрация их по категориям и добавление их в избранное.
Для каждой фичи нужно создавать ViewModel и репозиторий или раз все между собой тесно связано, лучше использовать один на все приложение, а отдельные создавать только для чего-то очень слабо связанного между собой.
Но если и для избранного и для фильтрации и тд использовать только одну ViewModel, не нарушает ли это single responsibility principle?
Ответ: Single responsibility principle – принцип единственной ответственности. Чтобы ему следовать, нам надо сначала понять, а какая ответственность у вьюмодели и репозитория?
На самом деле, на этот вопрос, как и на большинство вопросов по архитектуре, нельзя ответить однозначно, потому что подходы могут быть разные: кому-то нравится делать вьюху максимально пассивной, кому-то нет, но я вам расскажу подход, которому следую я, которому следуют в моей компании и которому я всех учу.
Ответственность репозитория: это управление источниками данных, их обработка и предоставление наружу в обработанном виде. Репозиторий ходит в сеть, кэширует, достаёт из кэша, маппит сетевые модели в доменные, обрабатывает ошибки, при необходимости маппит их в бизнесовые ошибки. Репозиторий отвечает за какой-то определённый кусок логики, например UserRepository или ImagesRepository.
Ответственность вьюмодели: вьюмодель – это прослойка между бизнес-логикой и определённым экраном. То есть вьюмодель не к фичам привязана, а к экрану. Если у вас на экране есть и добавление в избранное и фильтрация, значит и во вьюмодели это будет. Но вьюмодель делает это не сама, она обращается в вашем случае к конкретному репозиторию и получает из него результат. А репозитории вы уже проектируете как вам удобно: Например FavoritesRepository и FilterRepository, если хотите эту логику отделить. Или можете сделать один ImagesRepository, если не хотите отделять.
И запомните: однажды вам захочется сделать печально известную SharedViewModel и пошерить её между несколькими экранами. Это приведёт вас на путь, наполненный запутанным и нерасплетаемым спагетти-кодом, куче костылей и конфликтов. Не делайте так. Один экран – одна вьюмодель.
#android #архитектура #вопросы
Запись на менторство:
@andrdevnotes | androidmentor.ru
👍9🔥4💯2❤1
Привет, друзья!
Разбирая ваши запросы, заметил, что много практических вопросов по коду. Пришла в голову идея: устроить стрим с разбором ваших проектов.
Формат: вы до 19 мая присылаете мне ссылку на репозиторий со своим проектом. Я из них отбираю 5 проектов на разбор.
И я с 20 до 31 мая провожу один или больше стримов (в зависимости от объёма проектов) с подробным разбором и советами по рефакторингу.
Если у вас получится присутствовать на стриме – отлично, сможем лично пообщаться по проекту. Нет – посмотрите в записи.
Стоимость: 1990р за 1 проект.
Как вам идея?
Разбирая ваши запросы, заметил, что много практических вопросов по коду. Пришла в голову идея: устроить стрим с разбором ваших проектов.
Формат: вы до 19 мая присылаете мне ссылку на репозиторий со своим проектом. Я из них отбираю 5 проектов на разбор.
И я с 20 до 31 мая провожу один или больше стримов (в зависимости от объёма проектов) с подробным разбором и советами по рефакторингу.
Если у вас получится присутствовать на стриме – отлично, сможем лично пообщаться по проекту. Нет – посмотрите в записи.
Стоимость: 1990р за 1 проект.
Как вам идея?
👍4❤3🔥2