Clean Architecture Android на практике - применяем Use Case
ฝัง
- เผยแพร่เมื่อ 11 ก.ค. 2024
- Показываю реальный пример на пальцах для "чайников" :) с применением Android и Kotlin. Рассказываю про Clean Architecture Android на практике (Чистая архитектура).
Тема супер важная для разработки приложений под Android.
Предыдущее видео с теорией про Use Case: • Clean architecture And...
Я веду курсы программирования по разработке мобильных приложений для Android с менторингом 1 на 1. Записаться на курсы можно по ссылке: ✅ kiparo.com.
СОДЕРЖАНИЕ:
00:00:00 - краткое содержание к видео
00:00:55 - Clean Architecture на диаграмме
00:04:57 - Чистая архитектура Android на практике с реальным примером
00:22:20 - краткий обзор выполненного примера на Kotlin
00:24:26 - подводим итоги
Найти меня можно вот тут:
✅ Linkedin: / timofeykovalenko
✅ Instagram: / ttimofey
✅ На моем сайте: kiparo.com/teacher/timofey-ko...
✅ FB: / kiparocom
#чистаяархитектура #сleanarchitecture #kiparo
Предыдущее видео с теорией про Use Case: th-cam.com/video/Ao3d1R1TCYc/w-d-xo.html
СОДЕРЖАНИЕ:
00:00:00 - краткое содержание к видео
00:00:55 - Clean Architecture на диаграмме
00:04:57 - Чистая архитектура Android на практике с реальным примером
00:22:20 - краткий обзор выполненного примера на Kotlin
00:24:26 - подводим итоги
Огромное спасибо.
Вам реально дано объяснять сложные вещи простыми словами.
Рад что наткнулся на ваш канал
Я вообще бэкендер, но из за малого количества хороших уроков по чистой архитектуре, это видео очень помогло, спасибо)
Просто огромнейшее человеческое спасибо! Очень полезные видео! Очень мне сейчас они помогают!
До этого я смотрел много видео , но после ваших видео я начал понимать что к чему, молодец ! Теперь скоро собираюсь купить ваш курс! Супер!
Спасибо! Очень ясно и доступно :)
Больше уроков пожалуйста ) отлично обьясняете!!!
Потрясающе просто о сложных вещах. Огромное спасибо вам за труд.
Очень крутые уроки!!! Спасибо вам за детальное разъяснение!
Благодарю, процветания каналу!
Очень понятное видео. Прям я пока лучше не видел. Для чайников самое то! Спасибо!
Спасибо за видео! Очень круто
Большое, огромное спасибо за науку учитель. Очень интересно смотреть. Спасибо.
Спасибо большое, Тимофей! Все сверх понятно!
Очень все понятно! Спасибо!
Спасибо огромное!! Как бы я жил без твоих видео без чистой архитектуре.
спасибо большое, отлично передана информация!)
Наконец-то я нашел достойные уроки по архитектуре приложения!!!Спасибо Вам!!!❤
сходи в гости к Roman Andrushchenko, будет полезно.
Спасибо за видео.Коммент в поддержку!
Спасибо)
класс! смотрим остальные уроки!
Все просто и понятно, спасибо!
Очень понятно объясняешь, спасибо за урок
Спасибо за видео!!!! Очень хорошо объясняете!
😉
Огромное спасибо Тимофей! Мне очень нравится. Пожалуйста, делайте видео о Room SQLite.
Видео огонь! Спасибо!
Доброго времени суток! Уроки очень полезные, недавно только закончил курсы, но там мне не было понятно по clean Architecture. Сейчас, по вашим урокам заново перепрохожу и все доходчиво понятно. Спасибо огромное!!!🤝🥳
Ееееее, очень крутое видео, жду некст!)
Продолжение уже доступно ;)
th-cam.com/video/zt07bObIpSk/w-d-xo.html
Благожарю за отличный материал !
Ув. Тимофей! Вы - настоящий Профессор. Без шуток. Зашел в тупик с этими тремя слоями. Без них приложение работает, а с ними нет. Интуитивно искал то, что Вы преподнесли. Спасибо большое!
Отличный урок!!!!
Отличный материал. Были бы ещё strarter/final проекты c кодом, как почти у всех остальных, было бы круто.
Спасибо большое за труды
Больше спасибо!
Однозначно лайк и подписка )))
Спасибо за видео!
Полезное видео, спасибо
Мега спасибо!
Супер!
Благодарю!
Супер бомба 🎉
очень очень хорошо объясняете. Не знаю почему это назвали чистой архитектурой )) но ладно. Но пожалуйста продолжайте тенденцию, как объяснять вещи вот таким вот образом. Такого в рускоязычном компьюнити мало на самом деле. Многие прям все заворачивают сразу в сложные конструкции, как будто так и надо. В англоязычном объясняют сначала на пальцах, типа Couter простейший, чтобы было понятно с чего все начинается. Вот в этом видео я вижу тоже самое и мне это очень нравится. Отличное видео. Спасибо!
я потому только на английском и смотрю. там намного проще рассказывают, и комьюнити менее токсичное. этот канал - первый русскоязычный канал, на который я зашла и не пожалела.
@@luckydevil1601 можете посоветовать хорошие каналы по Андроиду? Конечно. можно англоязычные) Знаю парочку, но всегда хочется узнавать еще больше от классных спецов.
Я просто в восторге. Очень подробно!
Благодаря вашему видео я начал изучать Kotlin. Хотелось бы увидеть реализацию на java. Может дальше есть, пока что смотрю лишь второй урок. Но даже не зная Kotlin, смог написать подобный ваше реализации код на Java
Сейчас уже все на Kotlin на Android, поэтому реализации на Java не будет (.
Видео крутое, информативно, голос приятный, большое спасибо. Какой у вас опыт в разработке под анлроид?
Под андроид начал писать в 2011, почти 12 лет уже.
Благодарю
Огромное спасибо. Жаль нельзя поставить несколько лайков.
Спасибо!
Спасибо большое
чувак, как же ты крут
Еще можно у UseCase классов вместо execute воспользоваться фишкой Kotlin, назвав метод invoke, тем самым переопределив вызывание через (), например UseCase()
Вы такой классный!!!
Спасибо))).
Отличное видео спасибо! Подскажите как человек работающий в Android Studio уже долго (я полагаю) если у меня класс состоит из 10ти полей допустим класс "фильма" как в андройд студии настроить так что бы при печатании названии класса (при создании где нибудь переменной) что бы он автоматически вставлял все эти поля типа:
val film = Film(title=,year=, genre=,actors= .... ) а не пустой класс Film() то есть что бы не приходилось вбивать 10 полей вручную. Это как нибудь настраивается? все разрбрался плагин для студии "Kotlin Function Arguments Helper"!
Спасибо
Ранее работал в Android Studio, ваши уроки проходят в IntelliJ IDEA.
Может есть инструкция, как правильно подключить Genymotion к этой среде разработки?
Спасибо за видео, супер доходчиво! На просторах гугла вычитал что UseCase === Interactor, так ли это?
Вопрос: если юзкейс представляет собой гет запрос к апи, и в этом запросе есть параметр @Path который может меняться, то нужно ли создавать три юзкейса под каждый возможный path или можно через параметры в execute передавать?
Это не верный вопрос. Создавая юз кейсы вы не должны опираться на API. Вы создаете юз кейсы из необходимости в том или ином функционале, а уже затем смотрите, какие API и как нужно вызвать. То есть это вы решаете, какие юз кейсы создать, а не бекенд разработчик, который создал для вас API.
Но добавлю пример, что-бы прояснить конкретно ваш вопрос: зависит от того, что вы отсылаете в @Path и относится ли это к одному функционалу. Например, если через @Path вы делаете поиск данных или фильтрацию, то тут понятное дело будет один юз кейс. А если через @Path вы получаете 3 совершенно разные функциональности, то есть по хорошему это должно быть 3-мя разными API, то тут логично разделить это на разные юз кейсы.
Скажите пожалуйста, а логика кнопок копировать, вставить и поделиться где Клин архитектуре должна быть размещена ? У меня сейчас в майн активити. Или надо бы ее по юс кейсам распихать ?
Domain не может содержать платформенно зависимые вещи, то есть в домене вы такое размещать нельзя. Идеальнее всего пробрасывать это в ViewModel, которая дальше раздаст нужные команды что делать.
Для SaveUserNameUseCase я бы использовал data class. Так как он больше подходит под логику временного сохранения в памяти, как мне кажется.
Да, но если вы не используете методы, которые создает дата класс, то нет никакого смысла его использовать. Например, в видео про юнит тесты, мы меняем их на дата класс, потому, что нам нужно сравнивать объекты. Но в задаче данного видео, нам дата класс не нужны.
Я бы рекомендовал никогда не делать лишний код из расчета, что когда-то понадобится, лучше делать все по факту, иначе будет копиться не нужны мусор.
Можно ли UseCase с Mapper как то использовать? Ведь не всегда нужно использовать все данные которые приходят с сервера/бд. Спасибо
В UseCase мапперы не нужны, все ненужное можно обрезать еще в data слое, в момент когда делаете маппинг в domain модели.
Подскажите Тимофей, а следует ли нам наши модельки также на диаграмку набрасать?! Если да, то как это более понятно и стандартизировано должно выглядеть?! Спасибо.
Обычно это не делают, так как получиться очень уж большая диаграмма.
Я с помощью твоих видосов только начал понимать, что такое клин архитектура.
Я так понял, что „Clean Architecture“ это не есть альтернатива патерну MVVM. Скажите пожалуйста. Если использовать совместно с MVVM то нужно каждый Use Case в отдельный класс ViewModel выносить?
Конечно не альтернатива, задачи у них совершенно разные. Каждый Use Case в отдельный класс ViewModel выносить не нужно. ViewModel контролирует состояние конкретного экрана или части экрана, сколько там юз кейсов нужно, столько и подключайте.
@@TimofeyKovalenko благодарю
Так всё же - а когда будем проходить Room? Не совсем понятно как без интерфейсов будет выглядеть управление через UseCase
А причем тут UseCase к Room? UseCase ничего не знает про то как и откуда получаем данные(как правило не знает). Room пройдем но буквально чуть чуть, я все же считаю это сильно простой темой, и не хочется на нее много времени уделять.
А могут один и тот же UseCase использовать к примеру два или более активити?
Конечно можно.
А модельки тоже надо было в диаграмме делать ? Или это не важно ?
10:11 почему мы тут используем не data class ?
Спасибо за урок! Есть вопрос, у меня при создании package usecase, когда я хотел поместить его в package domain, получалось вместо отдельных пакетов один общий.
Тоесть, грубо говоря, такой результат - domain.usecase и я сюда уже use case помещал свои.
Это ведь неправильно, можете подсказать в чём может быть проблема?)
Это просто Android Studio так отображает, если пакеты пустые то склеивает вместе, в настройках можно поменять.
@@TimofeyKovalenko подскажите, а как это поменять, чтобы сделать как у вас в уроке?)
может кому будет полезно, compact middle packages нужно убрать галочку.
нужно нажать на шестерёнку, прямо над project
можно ваш телеграмм, у меня есть несколько вопросов ?
А почему models располагаете в domain, а не в data-слое?
Потому, что там им и место. Посмотрите подробнее диаграмму, если модель будет в дата, то как с ней работать юз кейсам?
Можно ли модели делать на абстрактных классах?
Технически можно, но зачем так усложнять все?
А модельки должны только общую информацию содержать или внутри правильнот иметь содержания какой-то доп. логики?! Или же если это доп логика то как-то выносится в абстракцию?!
Модельки лучше держать чистыми без какой-либо логики.
Я тоже бэкендер. Не знаю почему, у нас большинстве случаев топят за 3х слойную архитектуру. Хотя в ней есть много минусов.
Поэтому тоже было интересно посмотреть как в андройде вы используете Clean Architecture и подобное.
По поводу SOLID. DIP - игнорируется в вашем случае для useCase. По хорошему через интерфейс стоит их сделать, как считаете?
Как минимум для мок тестирования? Я бы так сильно не придирался, но вы сами упомянули solid))
Т.е. вы предлагаете сделать интерфейс, в нём объявить один метод execute и имплементить его в каждом UseCase? Я просто сам начинающий только, и хочу убедиться, что правильно вас понял)
@@user-ns8qh2en9u Да всё, верно. Плюсом мы получаем то, что интерфейс ещё и функциональным становиться.
Ну и для написания тестов мы сможем "мокать" наши интерфейсы.
Да, по хорошему нужно делать с интерфейсом, но это часто избыточно, а моки и без интерфейса будут работать.
За 3 слойную топят потому что, это с одной стороны достаточно просто, а с другой позволяет обезопасить код от менее опытных разработчиков. Плюс эта архитектура понятна подавляющему числу разработчиков, не нужно лишний раз вникать в новый проект.
Насчёт 10 use case в активити(фрагменте) не совсем согласен. Я в своём рабочем проекте использовал Interactor класс, как фасад над несколькими логически взаимосвязанными use case. За счёт этого уменьшается размер конструктора ViewModel твоего активити(фрагмента) и код становится чище и понятнее.
Да это хороший вариант.
entities и models это одно и то же?
Можно сказать, что одно и тоже, сейчас эти понятие смешались, но entities изначально были моделями для базы данных именно
Сейчас уже пишут Data Domain Ui
Ну.. пусть пишут ;)
Видео классные, многое становится понятно. Но объяснять конечно clean architecture начинающим разработчикам сомнительное удовольствие 😂
Такие уж времена, если не объяснить, то сожрут студента на собеседовании ;)))
класс SaveUserNameParam назван странно( Просто UserNameParam нужно
Это что-бы более четко понимать для чего он, так как юз кейсов связанных с UserName несколько.
@@TimofeyKovalenko все равно не убедили. Убирать Save(к тому же это "Save" - это действие, а имя класса лучше начинать с существительного)
😉
Если я правильно понимаю, в Activity не должно быть никакой логики, а выражение типа dataTextView.text = "${userName.firstName} ${userName.lastName}" и dataTextView.text = "Save result: $result" это же уже логика? Я делаю все в C#. Если бы я это делал в C#, то я бы переопределил методы ToString в UseCase и ничего в Activities не выносил из логики. И ещё. Пример корявый. Вводим одни данные, а получаем совершенно не в тему данные. Хотя общий смысл ясен более менее. Можно было продумать пример, конечно, получше.
Да, все верно. Но мы еще в этом видео не дошли до создания ViewModel ;). В этом видео показываю общую концепцию, детали презентации разбираем в следующих видео, уже выложены на канале.
У меня например в активити 50 функций, да мне проще будет разобраться в коду, чем щелкать эти юзкейсы и открывать. Жесть
Тебе, да. Но не след. разработчикам, которым придется утопать в этом коде)
Спасибо
Спасибо большое
Незачно)