Clean Architecture Android на практике - применяем Use Case

[@TimofeyKovalenko]

Предыдущее видео с теорией про Use Case: kzbin.info/www/bejne/d6CWlWSIZrl2j8U СОДЕРЖАНИЕ: 00:00:00 - краткое содержание к видео 00:00:55 - Clean Architecture на диаграмме 00:04:57 - Чистая архитектура Android на практике с реальным примером 00:22:20 - краткий обзор выполненного примера на Kotlin 00:24:26 - подводим итоги

[@AlexFromKiev]

Ув. Тимофей! Вы - настоящий Профессор. Без шуток. Зашел в тупик с этими тремя слоями. Без них приложение работает, а с ними нет. Интуитивно искал то, что Вы преподнесли. Спасибо большое!

[@MrOnlineCoder]

Я вообще бэкендер, но из за малого количества хороших уроков по чистой архитектуре, это видео очень помогло, спасибо)

[@Arman_127]

Огромное спасибо. Вам реально дано объяснять сложные вещи простыми словами. Рад что наткнулся на ваш канал

[@artlinestudio6735]

Большое, огромное спасибо за науку учитель. Очень интересно смотреть. Спасибо.

[@jkronz]

Спасибо огромное!! Как бы я жил без твоих видео без чистой архитектуре.

[@ШарьярЕсемуратов-о4х]

До этого я смотрел много видео , но после ваших видео я начал понимать что к чему, молодец ! Теперь скоро собираюсь купить ваш курс! Супер!

[@speedrages]

Благодарю, процветания каналу!

[@KingDev6363]

Доброго времени суток! Уроки очень полезные, недавно только закончил курсы, но там мне не было понятно по clean Architecture. Сейчас, по вашим урокам заново перепрохожу и все доходчиво понятно. Спасибо огромное!!!🤝🥳

[@GriNAME]

Просто огромнейшее человеческое спасибо! Очень полезные видео! Очень мне сейчас они помогают!

[@89Razin]

Наконец-то я нашел достойные уроки по архитектуре приложения!!!Спасибо Вам!!!❤

[@МихаилАкулов-ю7ж]

сходи в гости к Roman Andrushchenko, будет полезно.

[@rudinandrey]

очень очень хорошо объясняете. Не знаю почему это назвали чистой архитектурой )) но ладно. Но пожалуйста продолжайте тенденцию, как объяснять вещи вот таким вот образом. Такого в рускоязычном компьюнити мало на самом деле. Многие прям все заворачивают сразу в сложные конструкции, как будто так и надо. В англоязычном объясняют сначала на пальцах, типа Couter простейший, чтобы было понятно с чего все начинается. Вот в этом видео я вижу тоже самое и мне это очень нравится. Отличное видео. Спасибо!

[@luckydevil1601]

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

[@bunnyrin]

@@luckydevil1601 можете посоветовать хорошие каналы по Андроиду? Конечно. можно англоязычные) Знаю парочку, но всегда хочется узнавать еще больше от классных спецов.

[@stasleonov5196]

Потрясающе просто о сложных вещах. Огромное спасибо вам за труд.

[@chriswaytt6009]

Больше уроков пожалуйста ) отлично обьясняете!!!

[@senya_tall]

10:11 почему мы тут используем не data class ?

[@arthurtargonsky9952]

Спасибо! Очень ясно и доступно :)

[@Revakovskyi]

Очень крутые уроки!!! Спасибо вам за детальное разъяснение!

[@RomkinVideo]

Очень понятное видео. Прям я пока лучше не видел. Для чайников самое то! Спасибо!

[@sovrinfo]

Спасибо за видео.Коммент в поддержку!

[@TimofeyKovalenko]

Спасибо)

[@yourchoice2917]

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

[@АлександрБугримов-о1е]

Спасибо за видео! Очень круто

[@kovshichek5933]

Еще можно у UseCase классов вместо execute воспользоваться фишкой Kotlin, назвав метод invoke, тем самым переопределив вызывание через (), например UseCase()

[@Relax-4-Relax]

Добрый день У мнея маленький опый, пытаюсь понять что тут происходит . Скажите а вы можете както посмотреть мой код может сделать замечания ?

[@KirillAndreevich-c9w]

Ееееее, очень крутое видео, жду некст!)

[@TimofeyKovalenko]

Продолжение уже доступно ;) kzbin.info/www/bejne/sKWTaJWFl66jic0

[@kafychannel]

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

[@TimofeyKovalenko]

Под андроид начал писать в 2011, почти 12 лет уже.

[@yura.kuznetsov]

Ранее работал в Android Studio, ваши уроки проходят в IntelliJ IDEA. Может есть инструкция, как правильно подключить Genymotion к этой среде разработки?

[@annadanilenko3600]

Спасибо большое, Тимофей! Все сверх понятно!

[@denissavast]

Благожарю за отличный материал !

[@ohjelmistokehittaja4446]

Отличный материал. Были бы ещё strarter/final проекты c кодом, как почти у всех остальных, было бы круто.

[@romanstirskyi]

Очень все понятно! Спасибо!

[@dervanowsky]

класс! смотрим остальные уроки!

[@AkramAzizmurodov]

Огромное спасибо Тимофей! Мне очень нравится. Пожалуйста, делайте видео о Room SQLite.

[@MxMayers]

Отличное видео спасибо! Подскажите как человек работающий в Android Studio уже долго (я полагаю) если у меня класс состоит из 10ти полей допустим класс "фильма" как в андройд студии настроить так что бы при печатании названии класса (при создании где нибудь переменной) что бы он автоматически вставлял все эти поля типа: val film = Film(title=,year=, genre=,actors= .... ) а не пустой класс Film() то есть что бы не приходилось вбивать 10 полей вручную. Это как нибудь настраивается? все разрбрался плагин для студии "Kotlin Function Arguments Helper"!

[@speedrages]

Вопрос: если юзкейс представляет собой гет запрос к апи, и в этом запросе есть параметр @Path который может меняться, то нужно ли создавать три юзкейса под каждый возможный path или можно через параметры в execute передавать?

[@TimofeyKovalenko]

Это не верный вопрос. Создавая юз кейсы вы не должны опираться на API. Вы создаете юз кейсы из необходимости в том или ином функционале, а уже затем смотрите, какие API и как нужно вызвать. То есть это вы решаете, какие юз кейсы создать, а не бекенд разработчик, который создал для вас API. Но добавлю пример, что-бы прояснить конкретно ваш вопрос: зависит от того, что вы отсылаете в @Path и относится ли это к одному функционалу. Например, если через @Path вы делаете поиск данных или фильтрацию, то тут понятное дело будет один юз кейс. А если через @Path вы получаете 3 совершенно разные функциональности, то есть по хорошему это должно быть 3-мя разными API, то тут логично разделить это на разные юз кейсы.

[@hackim2554]

Благодаря вашему видео я начал изучать Kotlin. Хотелось бы увидеть реализацию на java. Может дальше есть, пока что смотрю лишь второй урок. Но даже не зная Kotlin, смог написать подобный ваше реализации код на Java

[@TimofeyKovalenko]

Сейчас уже все на Kotlin на Android, поэтому реализации на Java не будет (.

[@motohiker3435]

Я так понял, что „Clean Architecture“ это не есть альтернатива патерну MVVM. Скажите пожалуйста. Если использовать совместно с MVVM то нужно каждый Use Case в отдельный класс ViewModel выносить?

[@TimofeyKovalenko]

Конечно не альтернатива, задачи у них совершенно разные. Каждый Use Case в отдельный класс ViewModel выносить не нужно. ViewModel контролирует состояние конкретного экрана или части экрана, сколько там юз кейсов нужно, столько и подключайте.

[@motohiker3435]

@@TimofeyKovalenko благодарю

[@codemachine19]

Очень понятно объясняешь, спасибо за урок

[@oleg12395]

Скажите пожалуйста, а логика кнопок копировать, вставить и поделиться где Клин архитектуре должна быть размещена ? У меня сейчас в майн активити. Или надо бы ее по юс кейсам распихать ?

[@TimofeyKovalenko]

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

[@курбанбекАтанбай]

можно ваш телеграмм, у меня есть несколько вопросов ?

[@spam397]

А модельки тоже надо было в диаграмме делать ? Или это не важно ?

[@АлександрРоманов-р5ф]

Спасибо за видео!!!! Очень хорошо объясняете!

[@TimofeyKovalenko]

😉

[@OCEH6]

Видео огонь! Спасибо!

[@AndrewMatusevich]

Больше спасибо!

[@DenisBezrukov-jr1tp]

Я тоже бэкендер. Не знаю почему, у нас большинстве случаев топят за 3х слойную архитектуру. Хотя в ней есть много минусов. Поэтому тоже было интересно посмотреть как в андройде вы используете Clean Architecture и подобное. По поводу SOLID. DIP - игнорируется в вашем случае для useCase. По хорошему через интерфейс стоит их сделать, как считаете? Как минимум для мок тестирования? Я бы так сильно не придирался, но вы сами упомянули solid))

[@MajorTom-r6s]

Т.е. вы предлагаете сделать интерфейс, в нём объявить один метод execute и имплементить его в каждом UseCase? Я просто сам начинающий только, и хочу убедиться, что правильно вас понял)

[@DenisBezrukov-jr1tp]

@@MajorTom-r6s Да всё, верно. Плюсом мы получаем то, что интерфейс ещё и функциональным становиться. Ну и для написания тестов мы сможем "мокать" наши интерфейсы.

[@TimofeyKovalenko]

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

[@TimofeyKovalenko]

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

[@samuilzhumakhanov6056]

Все просто и понятно, спасибо!

[@berspoland5667]

Подскажите Тимофей, а следует ли нам наши модельки также на диаграмку набрасать?! Если да, то как это более понятно и стандартизировано должно выглядеть?! Спасибо.

[@TimofeyKovalenko]

Обычно это не делают, так как получиться очень уж большая диаграмма.

[@antonselitskiy8143]

Так всё же - а когда будем проходить Room? Не совсем понятно как без интерфейсов будет выглядеть управление через UseCase

[@TimofeyKovalenko]

А причем тут UseCase к Room? UseCase ничего не знает про то как и откуда получаем данные(как правило не знает). Room пройдем но буквально чуть чуть, я все же считаю это сильно простой темой, и не хочется на нее много времени уделять.

[@_Iovan_]

Спасибо за видео, супер доходчиво! На просторах гугла вычитал что UseCase === Interactor, так ли это?

[@ЕвгенийМинаенков-х8е]

Я просто в восторге. Очень подробно!

[@ЮкаРазраб]

Полезное видео, спасибо

[@berspoland5667]

А модельки должны только общую информацию содержать или внутри правильнот иметь содержания какой-то доп. логики?! Или же если это доп логика то как-то выносится в абстракцию?!

[@TimofeyKovalenko]

Модельки лучше держать чистыми без какой-либо логики.

[@НазарРадванецький-л5л]

Супер бомба 🎉

[@КахарманБалтабаев-б2о]

Отличный урок!!!!

[@ivan.legenda]

Однозначно лайк и подписка )))

[@ВладСизых-ю5ж]

чувак, как же ты крут

[@olegkovalenko5708]

Спасибо большое за труды

[@ЕвгенийМоскаленко-у9щ]

Можно ли UseCase с Mapper как то использовать? Ведь не всегда нужно использовать все данные которые приходят с сервера/бд. Спасибо

[@TimofeyKovalenko]

В UseCase мапперы не нужны, все ненужное можно обрезать еще в data слое, в момент когда делаете маппинг в domain модели.

[@jarjaju9524]

Можно ли модели делать на абстрактных классах?

[@TimofeyKovalenko]

Технически можно, но зачем так усложнять все?

[@devit4910]

Спасибо за урок! Есть вопрос, у меня при создании package usecase, когда я хотел поместить его в package domain, получалось вместо отдельных пакетов один общий. Тоесть, грубо говоря, такой результат - domain.usecase и я сюда уже use case помещал свои. Это ведь неправильно, можете подсказать в чём может быть проблема?)

[@TimofeyKovalenko]

Это просто Android Studio так отображает, если пакеты пустые то склеивает вместе, в настройках можно поменять.

[@devit4910]

@@TimofeyKovalenko подскажите, а как это поменять, чтобы сделать как у вас в уроке?)

[@devit4910]

может кому будет полезно, compact middle packages нужно убрать галочку. нужно нажать на шестерёнку, прямо над project

[@Majjabee-np9nq]

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

[@dopamine5071]

А почему models располагаете в domain, а не в data-слое?

[@TimofeyKovalenko]

Потому, что там им и место. Посмотрите подробнее диаграмму, если модель будет в дата, то как с ней работать юз кейсам?

[@MarchenkoAnton]

А могут один и тот же UseCase использовать к примеру два или более активити?

[@TimofeyKovalenko]

Конечно можно.

[@АлександрПурышев-б5щ]

Для SaveUserNameUseCase я бы использовал data class. Так как он больше подходит под логику временного сохранения в памяти, как мне кажется.

[@TimofeyKovalenko]

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

[@Андрей-в4й6л]

Спасибо за видео!

[@konstantinmezler5238]

Спасибо все понятно

[@ЕленаМ-о7щ]

Мега спасибо!

[@papirka33]

entities и models это одно и то же?

[@TimofeyKovalenko]

Можно сказать, что одно и тоже, сейчас эти понятие смешались, но entities изначально были моделями для базы данных именно

[@ArtemSamoshkin]

Благодарю!

[@MentorOfMentors]

Сейчас уже пишут Data Domain Ui

[@TimofeyKovalenko]

Ну.. пусть пишут ;)

[@АлександрГлебов-х4я]

Насчёт 10 use case в активити(фрагменте) не совсем согласен. Я в своём рабочем проекте использовал Interactor класс, как фасад над несколькими логически взаимосвязанными use case. За счёт этого уменьшается размер конструктора ViewModel твоего активити(фрагмента) и код становится чище и понятнее.

[@TimofeyKovalenko]

Да это хороший вариант.

[@Мах-в2п]

Супер!

[@cinderellarouge]

Вы такой классный!!!

[@TimofeyKovalenko]

Спасибо))).

[@motohiker3435]

Благодарю

[@АлександрКар-з9ш]

Видео классные, многое становится понятно. Но объяснять конечно clean architecture начинающим разработчикам сомнительное удовольствие 😂

[@TimofeyKovalenko]

Такие уж времена, если не объяснить, то сожрут студента на собеседовании ;)))

[@mikhailgureev218]

Спасибо большое

[@TimofeyKovalenko]

Незачно)

[@break8090]

Спасибо

[@marknoyanzin6108]

Если я правильно понимаю, в Activity не должно быть никакой логики, а выражение типа dataTextView.text = "${userName.firstName} ${userName.lastName}" и dataTextView.text = "Save result: $result" это же уже логика? Я делаю все в C#. Если бы я это делал в C#, то я бы переопределил методы ToString в UseCase и ничего в Activities не выносил из логики. И ещё. Пример корявый. Вводим одни данные, а получаем совершенно не в тему данные. Хотя общий смысл ясен более менее. Можно было продумать пример, конечно, получше.

[@TimofeyKovalenko]

Да, все верно. Но мы еще в этом видео не дошли до создания ViewModel ;). В этом видео показываю общую концепцию, детали презентации разбираем в следующих видео, уже выложены на канале.

[@ddsdcww434-wi4fo]

класс SaveUserNameParam назван странно( Просто UserNameParam нужно

[@TimofeyKovalenko]

Это что-бы более четко понимать для чего он, так как юз кейсов связанных с UserName несколько.

[@ddsdcww434-wi4fo]

​@@TimofeyKovalenko все равно не убедили. Убирать Save(к тому же это "Save" - это действие, а имя класса лучше начинать с существительного)

[@TimofeyKovalenko]

😉

[@tpov_oleg]

У меня например в активити 50 функций, да мне проще будет разобраться в коду, чем щелкать эти юзкейсы и открывать. Жесть

[@TimofeyKovalenko]

Тебе, да. Но не след. разработчикам, которым придется утопать в этом коде)

[@armangukasian]

спасибо большое, отлично передана информация!)

[@Ucozar]

Спасибо!

[@Silveryization]

Спасибо

[@muhammadkurbonov4779]

Спасибо большое