Курс Разработка мобильных приложений под Android kotlin: kiparo.com СОДЕРЖАНИЕ: 00:00:00 - кратно о всех видео про Clean Architecture 00:01:19 - проблема при использовании пакетов 00:05:12 - создаем модули в Android 00:17:04 - преимущества мультимодульного проекта 00:19:35 - про следующие видео
а где хранить бизнес логику. К примеру у меня есть база данных со строками мне нужно брать строку переводить ее при помощи запроса в интернет, и получены результат снова записать в базу данных. Где правильно будет разместить этот код.
Как следить за каждым gradle файлом в модулях? Надо везде обновлять одни и теже библиотеки, везде следить за версией SDK и так далее. Ну и хотелось бы поподробнее про виды модулей, про имена пакетов внутри модулей.
Работаю андроид девом около года, в своих проектах, на которых я работал, я хорошо ориентировался, но не было понимания зачем те или иные вещи раскидали по таким то классам, или папкам, или модулям. После просмотра ваших роликов по clean architecture я открыл все свои проекты, сразу же в голову пришло осознание, что для чего сделано и как. И уже по своим проектам я ориентировался не по памяти, а по смыслу. Так же хочу отметить четкую подачу материала, очень нравится, когда вы сперва показываете неправильный вариант, а затем правильный, и по ходу объясняете почему так лучше. Таких лекторов не часто видел я, поэтому желаю вашему каналу развиваться дальше и освещать больше различных тем, с такой подачей новичкам и даже опытным разрабам будет проще вливаться в дело.
Посмотрела все ваши видео по архитектуре) Очень понятно и структурировано объясняете, в голове сразу навелся порядок после просмотра) Да и почти нету воды, все четко и по существу) Плюс иллюстрация материала на диаграмме очень облегчает восприятие) В общем большое спасибо, жду новых видео
Очень долго ломала голову, как же подключить :domain, ведь на новых версиях студии правила подключения зависимостей стали немного отличаться. Методом проб и ошибок получилось подключить путём implementation (project (":domain"))
улыбнула фраза "ну это легкая тема" после 5-ти 30-минутных видео хаххпа, а вообще смысл и вправду несложный ,единственное, что сложно, это не просто понять, а уметь мыслить таким паттерном, и использовать это в проекте, мне как джуну - это как заново начать программировать ппххп))
Я прозрела. Я просто сейчас нахожусь в таком приятном шоке. Реально я раньше никак не могла понять зачем нужны эти папки? Все говорят про ООП, SOLID , но что это такое и как реализовать я не понимала. А здесь буквально за несколько уроков я всё поняла. Спасибо большое 🤗
Канал топ)) я бы добавил, если использовать модули, можно раскомментировать флаг параллельной сборки, если не ошибаюсь, это ускоряет сборку, если модулей больше одного. Можно бы было показать сразу, как настроить koin, потому как by lazy в коде практически не встречается, и еще может приводить к утечке памяти.
Для тех,кто немного не понимаем зачем также нужно писать интерфейсы: 1.Чтобы протестировать приложение,сделать фейковую реализацию класса,для его тестирования 2.Чтобы не нарушать DIP (Dependency Inversion Principle) - 5 принцип SOLID К примеру,мы создавали в пакете домен интерфейс для репозитория,это нужно было для того,чтобы наш домен слой (interactor или usecase) работал не с конкретной реалоизацией репозитория,которая лежит в data слое,а с интерфейсом.Модули верхних уровней(Interactor или usecase) не должен зависеть от модулей нижних уровней(конкретная реализация репозитория,расположенная в data слое). Оба типа модулей должны зависеть от абстракций(от интерфейса)
Конечно, на проверку ДЗ и созвоны 1:1 уходить очень много времени. Мне хоть и очень нравится преподавание, но это очень много сил забирает, что бы бесплатно учить. Да и когда бесплатно делаешь, сложно регулярность поддерживать, быстро энтузиазм кончается).
Поверь) инвестиция в это, окупается быстро =) Если дойдёшь до первой работы и пойдёшь дальше, поверь) будешь готов отдать и х2 и х3 бабла по сравнению с тем что отдал) Сильные джуны с ходу прыгают на ЗП в 1000$ =) а дальше больше, мало какая профессия может похвастаться этим ;)
Заметил, что в каждом модуле есть свой манифест, тогда вопрос - выходит что можно указать свои права для каждого модуля отдельно? Например, чтобы какой-нибудь модуль в принципе не мог добраться до файловой системы или местоположения хорошее видео, спасибо!
Тимофей, добрый день! Очень понравились ваши видео, стал лучше понимать чистую архитектуру. В данный момен открыл свое старое приложение ModbusMaster и решил переписать его под чистую архитектуру. Вкратце приложение соединяется по Блютузу с Ардуино и обменивается с ним информацией. Столкнулся с вопросом в какой слой отнести Блютуз. По логике это слой данных. Но для работы с Блютузом нужна тесная связь с Активити, с ее жизненным циклом. У меня раньше это было через колбэки сделано. А сейчас слой данных должен общаться только с доменом и получается каша. Либо это отдельный слой особенный какой-то должен быть, например, Device? По блютузу вообще мало инфы современной в инете, все примеры десятилетней давности. Буду благодарен, если подскажете или направите в нужном направлении, как реализовать обмен по блютуз в чистой архитектуре. Или снимите видео, думаю тема многим будет интересна.Заранее, спасибо.
Из активити вам нужен ее жизненный цикл же? Вариантов много может быть: 1) Можно сделать отдельный модуль, это вполне рабочий вариант 2) Можно отнести в слой data, но я бы все равно вынес в отдельный слой. Но вот общаться с ним можно через domain. Например завернуть все за корутиновской Flow. Если же вам нужен именно объект активити, что не очень хорошо, то да, лучше отдельный модуль и с его api напрямую работать.
Было бы круто посмотреть видос с features и динамическими фичами, модульное построение функционала приложения, как его отключать или подключать в зависимости от каких-то условий (мб немного теории Gradle) и как это в теории работает в рамках AAB и features delivery в Google Play. Возможно у вас есть бусти, где об этом что-то сказано?) Спасибо вам за замечательное видео!
Если вам не составит труда, а я знаю что это долго объяснять, расскажите пожалуйста про все принципы SOLID, каждый принцип каждой буквы, мы очень очень будем признательны
Типа имеете ввиду андроид или java модуль? Зависит от того к чему эти классы относятся. Обычно создают отдельные модули такие как "core-design", "core-..еще что то", где находятся общие классы для разных модулей.
Подскажи как вы у себя в проектах решате проблему с Parcelable передаваемый в аргементы фрагментов. Оно вроде как работает, но в отчетах крашлитика у людей крашится приложение, причем в бэкграунде. Даже стал задумываться вообще отказаться от Parcelable и передвать примитивами. Еще момент parcelable у меня генерируется анотацией @Parcelize, сам я его не описываю. И еще в этот parcelable иногда входит объект из sealed класса, тоже парселизуемый.
Скорей всего, что-то напортачили с реализацией или сгенерированный код не верный. А вообще, лучше не использовать Parcelable, а передавать только минимум в виде примитивов)
Ради интереса разбил свой пэт на модули. За три недели приложение прилично выросло. DTO-шки, Db-модели, entity, mapper-ы, и по логике теперь захотел чтобы после загрузки с сети, положенная db-модель обновлялась через LiveData. Как прокинуть через domain лайвдату в презентейшн слой, если у нас голый котлин/джава? Можно ли так поступать с точки зрения архитектуры?
Если у вас есть корутины, то лучше используйте Flow для этого, а так конечно же, желательно избежать LiveData в домене, но даже если добавить ничего страшного ;)
Тоже самое будет. А если вы хотите разделять экраны на модули (фича модули), то либо тоже самое. + фича модули, либо у фичей могут быть свои домен и дата.
Большое спасибо) За несколько уроков узнал больше чем за год работы программистом) Скажите пожалуйста а вот на некоторых проектах на модули разделяют конкретные фичи каждая из которых в себе содержит data app и presentation, как тогда внутри этих фич использовать разделение на модули data app presentation? Делать модули в модулях?
Модуль в модуле такого нет, но будет просто папка с группой модулей, которые реализуют одну фичу, то есть модуль фичи и у нее зависимости к домен и дата. Но я бы не советовал так делать в небольших или средних проектах, это больше для очень больших проектов с большим количеством разработчиков.
Знает, вы же должны все вместе собирать как то. А вот презентейшен не должен знать. В нашем примере презентейшен лежит внутри апа, поэтому конечно доступ есть.
Все подумывал как бы мне все эти связи правильно нарисовать, т.к. из головы вылетает то, что еще совсем недавно делал сам, не то, что слушал у других. И тут такой подарок. Большое спасибо, именно то, что надо. Был бы огромный +, если бы были бы письменные уроки, т.к. приходится пом ногу раз возвращаться и вспоминать и т.д. Я в настоящее время такие видео закидываю к себе на страницу, получаю доступ к субтитрам без временной разметки и уже подправляю мелкие ошибки, проще, чем печатать урок с просмотра. Но книжка всегда важнее видео.
Здравствуйте, Тимофей! Спасибо за серию про чистую архитектуру, ничего лучше на ютубе нет) Очень хотелось бы увидеть как делать приложение с горизонтальной модуляризацией. Нигде не могу найти информацию об этом.
Сначала не понимал, что вообще происходит и зачем для такого простого приложение столько папок, классов и вообще так много кода, но было интересно. А когда дошел до этого видео про модули, все вдруг на свои место стало и как дошло. Огромное спасибо за ваши видео, очень помогают понятно организовывать свои проекты.
как использовать один модуль в нескольких приложениях? Хочу иметь возможность менять что то в его классах, методах из одного приложения, чтобы эти изменения отображались и в другом приложении.
Тут разные подходы могут быть. Если оба приложения схожи и являются одним продуктом, то можно просто создать несколько app модулей внутри одного проекта, и они будут иметь общие зависимости от других модулей. Можно сделать модуль в виде библиотеки, которая лежит отдельно и подтягивается разными приложениями: например это может быть либа выложенная на mvnrepository или свой сервер, либо просто физически рядом лежать.
Полезное видео, спасибо! Было бы отлично если в следующих видео будет пример с использованием апи (rxJava 2 + retrofit 2) в рамках архитектуры. Основной вопрос с которым я столкнулся, это useCase должен возвращать уже модельку данных или условный обсервер, где viewModel подпишется на него и будет обрабатывать состояния. Узнать о возможных реализациях и о плюсах/минусах
Да, это будет еще в будущих темах. По поводу возвращаемого объекта из Use Case, можно возвращать все что угодно, тут ограничений нет. Если подписка не нужна, то будет Single(если мы говорим про Rx), либо просто моделька(если корутины или не нужна многопоточность). Все зависит от того, какой функционал должен быть у данного Use Case.
Здравствуйте, спасибо большое за такие замечательные уроки. А для маленьких проектов (экранов 8-10) где работают 2-3 разработчика это не будет считаться OVER ARCHITECTURE?
Базовые принципы разделения в любом проекте не будут считаться лишним. Но если уверены, что проект не обрастет новыми фичами можно и сократить, например не использовать domain. Но жертвовать разделением entity я бы не стал
Parcelable это чисто андроидовская штука, это не ответственность domain слоя и такого там быть не должно. Для этого делайте отдельную модельку на уровне presentation для передачи данных. А лучше вообще постарайтесь избежать передачи целых объектов.
Подскажите пожалуйста, Получается тогда какие виды архитектуры приложения бывают? Чтобы на собесе отвечать. Я просто раньше думал, что MVP, MVVM, MVC и MVI это как раз и есть виды архитектуры.
Их достаточно много, не говоря уже о самописных, у которых нет названия))). Но, те которые применяются сейчас в мобильной разработке, как правило различные вариации Clean Architecture - много вариантов с фича модулями, варианты с разными слоями приложения отличными от классики data, domain и тд. особо то и названий конкретных даже нет у них,
Тимофей, подскажите, создавая приложение с нуля, надо сразу разделять его на модули, т.е. как бы сразу определяя возможность доступа к объектам из других модулей?
Roman Andrushchenko загляни. Он на укр перевел названия, но андроид разраб вся еще на русском. В конце многомодульность, чистая арх, в общем полный курс по андроид разраб без всякой платы. Преподает в Харьковском универе каком-то.
Все круто. Спасибо. Есть вопрос относительно LiveData в репозитории Domain модуля. Как организовать прослушивание данных к примеру в Room, если Domain модуль самый независимый и LiveData не поддерживается в нем?
Я бы порекомендовал использовать корутины. Domain то самый независимый, но глобальные библиотеки, такие как корутины, rx и подобные, в любом случае там будут. А LiveData конечно лучше туда не закидывать.
Все просмотрел все супер! осталась неясность про подключение пакетов в модулях, столкнулся с тем что в domain недоступен android.util.Log решил через отдельный пакет логировать поставил Timber инициализирую его в Application() соответственно подключен он как зависимость в :app build.gradle а использовать его хочу в domain прописываю импорт в градле domain, сборка выдает "Declare repository providing the artifact" что в таком случае делать?
После разбиения на модули появилось ощущение что файлы проекта лежат друг от друга в 10ти метрах 🤔 и перемещаться между ними приходится физически вставать и ходить то за одним файлом то за другим 🤷♀️
В этом и смысл, что-бы все было далеко друг от друга), что-бы каждый из компонентов работал самостоятельно, не влияя на другие. И так меньше ошибок делается на проекте ).
Тимофей, правильно ли я понимаю что в рамках данного ролика рассматривается пример MVP? Так как MVVM by Google, подразумевает одностороннюю связь между слоями и зависимости по соглашению гугла должны быть вот такого плана UI -> DOMAIN -> DATA
Мы тут не рассматривали MVVM/MVP, тут общая концепция слоев. В данном примере у нас просто активити работает с юз кейсом, MVVM/MVP паттерны тут пока не рассматривали. Посмотрите дальше в плей листе, там есть ролик, где мы добавляем MVVM.
@@TimofeyKovalenko не знаю, какой линейкой вы меряете, но эти 4 буквы полностью определяют, на каких принципах будет функционировать приложение, и как связаны его составляющие. можно конечно вьюмодель называть маленькой частью, ответственной за состояние экрана, забыв обо всей логике. и, опять же, смотря что называть архитектурой. сингл-активити тоже по-своему архитектура
@@TimofeyKovalenko Я учусь немного подругому. Я стараюсь перед глазами иметь весь материал, в виде кода - максимально локанично. И отталкиваясь - делать свое. Буду благодарен если вы этим вашим нанопроектом по Clean поделитесь с вашим покорным слугой) Заранее благодарен.)
Тимофей, расскажите пожалуйста как делить приложение на фиче модули и по клин одновременно? Тоесть был один модуль - мод1 И теперь стало: Мод1-domain Мод1-presentation Мод1-data Так что-ли? Теперь как бы стало модулей в 3 раза больше. Так правильно? Спасибо
Тут разные подходы могут быть. Как правило на фичи делят presentation модуль, а domain и data остаются как есть. Но в очень большом проекта(очень очень большом с десятками программистов на каждую фичу), каждая фича может иметь свой домен и дату. Об этом еще попозже буду снимать видео.
@@TimofeyKovalenko спасибо за ответ, Тимофей Но чисто логически если у фиче модулей одна база данных то они тесно связаны, а они в теории должны вообще друг друга не знать, разве нет?
А какая разница, что база одна и та же? Фича работает с юз кейсами и все, больше она ничего не знает. Мыслите всегда публичными методами, которые вам доступны, а то, что за ними, пользователя не должно волновать.
Добрый день, по просьбе автора задаю вопрос: -Почему мы в активити инициализируем репозиторий, насколько я понимаю это неправильно. Не должен ли это делать, какой-то промежуточный слой?
Должно. В след. видео мы делаем это в вью модел фабрике, а потом в DI. Просто, когда сразу все даешь, у студентов каша в голове. Поэтому все постепенно).
Курс Разработка мобильных приложений под Android kotlin: kiparo.com
СОДЕРЖАНИЕ:
00:00:00 - кратно о всех видео про Clean Architecture
00:01:19 - проблема при использовании пакетов
00:05:12 - создаем модули в Android
00:17:04 - преимущества мультимодульного проекта
00:19:35 - про следующие видео
а где хранить бизнес логику. К примеру у меня есть база данных со строками мне нужно брать строку переводить ее при помощи запроса в интернет, и получены результат снова записать в базу данных. Где правильно будет разместить этот код.
Лучшая серия про Clean, что я видел! Спасибо
урок очень изй понятно и конечно супер как всегда, спс за урок Тимофей 😃😃
Спасибо!👍🏻
spasibo bolshoe 😊
Коротко и ясно про clean.) У меня есть вопрос. Для чего нам нужно добавлять data модуль в app ?
Имеете ввиду зачем создавать модуль для этого, а не пекедж?
Как следить за каждым gradle файлом в модулях? Надо везде обновлять одни и теже библиотеки, везде следить за версией SDK и так далее. Ну и хотелось бы поподробнее про виды модулей, про имена пакетов внутри модулей.
Все зависимости можно вынести в один общий файл, что бы не следить за всеми модулями. Надо будет сделать видео про это).
Работаю андроид девом около года, в своих проектах, на которых я работал, я хорошо ориентировался, но не было понимания зачем те или иные вещи раскидали по таким то классам, или папкам, или модулям. После просмотра ваших роликов по clean architecture я открыл все свои проекты, сразу же в голову пришло осознание, что для чего сделано и как. И уже по своим проектам я ориентировался не по памяти, а по смыслу. Так же хочу отметить четкую подачу материала, очень нравится, когда вы сперва показываете неправильный вариант, а затем правильный, и по ходу объясняете почему так лучше. Таких лекторов не часто видел я, поэтому желаю вашему каналу развиваться дальше и освещать больше различных тем, с такой подачей новичкам и даже опытным разрабам будет проще вливаться в дело.
Спасибо!
Посмотрела все ваши видео по архитектуре) Очень понятно и структурировано объясняете, в голове сразу навелся порядок после просмотра) Да и почти нету воды, все четко и по существу) Плюс иллюстрация материала на диаграмме очень облегчает восприятие) В общем большое спасибо, жду новых видео
Здравствуйте, Тимофей! Спасибо за серию про чистую архитектуру. Очень хотелось бы увидеть от вас Retrofit , FireBase
implementation(project(":domain")) у кого ошибки попробуйте такой синтаксис
это то, что я искал, спасибо
Очень долго ломала голову, как же подключить :domain, ведь на новых версиях студии правила подключения зависимостей стали немного отличаться. Методом проб и ошибок получилось подключить путём implementation (project (":domain"))
улыбнула фраза "ну это легкая тема" после 5-ти 30-минутных видео хаххпа, а вообще смысл и вправду несложный ,единственное, что сложно, это не просто понять, а уметь мыслить таким паттерном, и использовать это в проекте, мне как джуну - это как заново начать программировать ппххп))
😀
Великолепный урок! Спасибо учитель. Полезно, красиво, доступно, интересно!
Удивительно четкое изложение материала, просто впечатлён, спасибо!
Я прозрела. Я просто сейчас нахожусь в таком приятном шоке. Реально я раньше никак не могла понять зачем нужны эти папки? Все говорят про ООП, SOLID , но что это такое и как реализовать я не понимала. А здесь буквально за несколько уроков я всё поняла. Спасибо большое 🤗
Лучший, сколько не искал обьяснение для чайников , нашел только тут! Для джунов прекрасно)
Канал топ)) я бы добавил, если использовать модули, можно раскомментировать флаг параллельной сборки, если не ошибаюсь, это ускоряет сборку, если модулей больше одного. Можно бы было показать сразу, как настроить koin, потому как by lazy в коде практически не встречается, и еще может приводить к утечке памяти.
👍, про koin тоже будет, просто все постепенно, иначе каша может быть.
Спасибо
Для тех,кто немного не понимаем зачем также нужно писать интерфейсы:
1.Чтобы протестировать приложение,сделать фейковую реализацию класса,для его тестирования
2.Чтобы не нарушать DIP (Dependency Inversion Principle) - 5 принцип SOLID
К примеру,мы создавали в пакете домен интерфейс для репозитория,это нужно было для того,чтобы наш домен слой (interactor или usecase) работал не с конкретной реалоизацией репозитория,которая лежит в data слое,а с интерфейсом.Модули верхних уровней(Interactor или usecase) не должен зависеть от модулей нижних уровней(конкретная реализация репозитория,расположенная в data слое). Оба типа модулей должны зависеть от абстракций(от интерфейса)
Курс платный ?
Конечно, на проверку ДЗ и созвоны 1:1 уходить очень много времени. Мне хоть и очень нравится преподавание, но это очень много сил забирает, что бы бесплатно учить. Да и когда бесплатно делаешь, сложно регулярность поддерживать, быстро энтузиазм кончается).
Поверь) инвестиция в это, окупается быстро =)
Если дойдёшь до первой работы и пойдёшь дальше, поверь) будешь готов отдать и х2 и х3 бабла по сравнению с тем что отдал)
Сильные джуны с ходу прыгают на ЗП в 1000$ =) а дальше больше, мало какая профессия может похвастаться этим ;)
Заметил, что в каждом модуле есть свой манифест, тогда вопрос - выходит что можно указать свои права для каждого модуля отдельно? Например, чтобы какой-нибудь модуль в принципе не мог добраться до файловой системы или местоположения
хорошее видео, спасибо!
Да, все верно.
Класно, как к модулям подключить DI
Обязательно покажу.
Тимофей, добрый день! Очень понравились ваши видео, стал лучше понимать чистую архитектуру. В данный момен открыл свое старое приложение ModbusMaster и решил переписать его под чистую архитектуру. Вкратце приложение соединяется по Блютузу с Ардуино и обменивается с ним информацией. Столкнулся с вопросом в какой слой отнести Блютуз. По логике это слой данных. Но для работы с Блютузом нужна тесная связь с Активити, с ее жизненным циклом. У меня раньше это было через колбэки сделано. А сейчас слой данных должен общаться только с доменом и получается каша. Либо это отдельный слой особенный какой-то должен быть, например, Device? По блютузу вообще мало инфы современной в инете, все примеры десятилетней давности. Буду благодарен, если подскажете или направите в нужном направлении, как реализовать обмен по блютуз в чистой архитектуре. Или снимите видео, думаю тема многим будет интересна.Заранее, спасибо.
Из активити вам нужен ее жизненный цикл же? Вариантов много может быть:
1) Можно сделать отдельный модуль, это вполне рабочий вариант
2) Можно отнести в слой data, но я бы все равно вынес в отдельный слой. Но вот общаться с ним можно через domain. Например завернуть все за корутиновской Flow.
Если же вам нужен именно объект активити, что не очень хорошо, то да, лучше отдельный модуль и с его api напрямую работать.
Крутейшая подача, обалденный материал. Ничего подобного не встречал не у кого на эту тему. Спасибо Вам
Супер!!! Долго искал и вот оно. Отличная подача материала! Спасибо за ваш труд!
Скорее бы видео по DI)
обязательно будет)
Было бы круто посмотреть видос с features и динамическими фичами, модульное построение функционала приложения, как его отключать или подключать в зависимости от каких-то условий (мб немного теории Gradle) и как это в теории работает в рамках AAB и features delivery в Google Play. Возможно у вас есть бусти, где об этом что-то сказано?)
Спасибо вам за замечательное видео!
давно зреет идея подобного видео, как нибудь дойду до него)
Если вам не составит труда, а я знаю что это долго объяснять, расскажите пожалуйста про все принципы SOLID, каждый принцип каждой буквы, мы очень очень будем признательны
В плане это, еще будут видео по Dagger и тестированию, а после этого про SOLID.
Тимофей очень полезное видео.
У меня вопрос. В модуль какого типа ложить package "base" - там где находятся base fragment и т.д.?
Типа имеете ввиду андроид или java модуль? Зависит от того к чему эти классы относятся. Обычно создают отдельные модули такие как "core-design", "core-..еще что то", где находятся общие классы для разных модулей.
Расскажите пожалуйста про это с примерами в своих видео, что ещё за core?
Огромное спасибо за легкий к восприятию контент!
будет ли видео по фича-модулям?
Конечно, но чуть позже.
@@TimofeyKovalenko ждем
@@TimofeyKovalenko нет в планах сделать видео по фича модулям?
Подскажи как вы у себя в проектах решате проблему с Parcelable передаваемый в аргементы фрагментов. Оно вроде как работает, но в отчетах крашлитика у людей крашится приложение, причем в бэкграунде. Даже стал задумываться вообще отказаться от Parcelable и передвать примитивами. Еще момент parcelable у меня генерируется анотацией @Parcelize, сам я его не описываю. И еще в этот parcelable иногда входит объект из sealed класса, тоже парселизуемый.
Скорей всего, что-то напортачили с реализацией или сгенерированный код не верный. А вообще, лучше не использовать Parcelable, а передавать только минимум в виде примитивов)
Ради интереса разбил свой пэт на модули. За три недели приложение прилично выросло. DTO-шки, Db-модели, entity, mapper-ы, и по логике теперь захотел чтобы после загрузки с сети, положенная db-модель обновлялась через LiveData. Как прокинуть через domain лайвдату в презентейшн слой, если у нас голый котлин/джава? Можно ли так поступать с точки зрения архитектуры?
Если у вас есть корутины, то лучше используйте Flow для этого, а так конечно же, желательно избежать LiveData в домене, но даже если добавить ничего страшного ;)
А как будет выглядеть структура модулей если будет несколько экранов ?
Тоже самое будет. А если вы хотите разделять экраны на модули (фича модули), то либо тоже самое. + фича модули, либо у фичей могут быть свои домен и дата.
Очень полезное видео ,спасибо
Спасибо!
Как потом из этих модулей aab собрать, для размещения в google play?
Так же как и обычно), никаких отличий нет.
Спасибо
Большое спасибо) За несколько уроков узнал больше чем за год работы программистом) Скажите пожалуйста а вот на некоторых проектах на модули разделяют конкретные фичи каждая из которых в себе содержит data app и presentation, как тогда внутри этих фич использовать разделение на модули data app presentation? Делать модули в модулях?
Модуль в модуле такого нет, но будет просто папка с группой модулей, которые реализуют одну фичу, то есть модуль фичи и у нее зависимости к домен и дата. Но я бы не советовал так делать в небольших или средних проектах, это больше для очень больших проектов с большим количеством разработчиков.
@@TimofeyKovalenko Понял. Спасибо большое!
🔥🔥🔥
Апп не знает о дате). Или можно на прямую репу использовать )
Знает, вы же должны все вместе собирать как то. А вот презентейшен не должен знать. В нашем примере презентейшен лежит внутри апа, поэтому конечно доступ есть.
Все подумывал как бы мне все эти связи правильно нарисовать, т.к. из головы вылетает то, что еще совсем недавно делал сам, не то, что слушал у других.
И тут такой подарок. Большое спасибо, именно то, что надо.
Был бы огромный +, если бы были бы письменные уроки, т.к. приходится пом ногу раз возвращаться и вспоминать и т.д.
Я в настоящее время такие видео закидываю к себе на страницу, получаю доступ к субтитрам без временной разметки и уже подправляю мелкие ошибки, проще, чем печатать урок с просмотра.
Но книжка всегда важнее видео.
что делать если выдаёт Cannot access 'java.lang.Object' когда пытаюсь использовать rx в любом модуле кроме app?
комментарий для продвижения
спасибо за труд!
Спасибо за курс, он уникален, очень помог разобрвться с архитектурой
Большое спасибо за подробное объяснение!!!
Здравствуйте, Тимофей! Спасибо за серию про чистую архитектуру, ничего лучше на ютубе нет) Очень хотелось бы увидеть как делать приложение с горизонтальной модуляризацией. Нигде не могу найти информацию об этом.
В планах).
Да, тоже бы хотелось видео на эту тему, потому что остальные авторы объясняют не слишком понятно
Лучшая серия про Clean,
очень полезная серия видео. Не передать словами насколько я благодарна автору, за такую подборку.
спасибо за урок!! а какие еще есть архитектуры кроме "Clean" в андроид?
Сначала не понимал, что вообще происходит и зачем для такого простого приложение столько папок, классов и вообще так много кода, но было интересно. А когда дошел до этого видео про модули, все вдруг на свои место стало и как дошло. Огромное спасибо за ваши видео, очень помогают понятно организовывать свои проекты.
спасибо. все очень понятно. помог
Огромное спасибо! Отличный урок!
как использовать один модуль в нескольких приложениях?
Хочу иметь возможность менять что то в его классах, методах из одного приложения, чтобы эти изменения отображались и в другом приложении.
Тут разные подходы могут быть. Если оба приложения схожи и являются одним продуктом, то можно просто создать несколько app модулей внутри одного проекта, и они будут иметь общие зависимости от других модулей. Можно сделать модуль в виде библиотеки, которая лежит отдельно и подтягивается разными приложениями: например это может быть либа выложенная на mvnrepository или свой сервер, либо просто физически рядом лежать.
Спасибо Вам большое 🤍
Большое спасибо за труд
Вы делаете важное дело!
4:22 эффект бабочки)
Полезное видео, спасибо!
Было бы отлично если в следующих видео будет пример с использованием апи (rxJava 2 + retrofit 2) в рамках архитектуры.
Основной вопрос с которым я столкнулся, это useCase должен возвращать уже модельку данных или условный обсервер, где viewModel подпишется на него и будет обрабатывать состояния. Узнать о возможных реализациях и о плюсах/минусах
Да, это будет еще в будущих темах. По поводу возвращаемого объекта из Use Case, можно возвращать все что угодно, тут ограничений нет. Если подписка не нужна, то будет Single(если мы говорим про Rx), либо просто моделька(если корутины или не нужна многопоточность). Все зависит от того, какой функционал должен быть у данного Use Case.
шикарно!!!
спасибо! 👍
Спасибо!
Здравствуйте, спасибо большое за такие замечательные уроки. А для маленьких проектов (экранов 8-10) где работают 2-3 разработчика это не будет считаться OVER ARCHITECTURE?
Базовые принципы разделения в любом проекте не будут считаться лишним. Но если уверены, что проект не обрастет новыми фичами можно и сократить, например не использовать domain. Но жертвовать разделением entity я бы не стал
Тимофей, большое Вам спасибо!
Что делать, если в слое domain есть модели и эти модели должны быть Parcelable ? Как сделать эти модели Parcelable ?
Parcelable это чисто андроидовская штука, это не ответственность domain слоя и такого там быть не должно. Для этого делайте отдельную модельку на уровне presentation для передачи данных. А лучше вообще постарайтесь избежать передачи целых объектов.
Подскажите пожалуйста,
Получается тогда какие виды архитектуры приложения бывают? Чтобы на собесе отвечать. Я просто раньше думал, что MVP, MVVM, MVC и MVI это как раз и есть виды архитектуры.
Их достаточно много, не говоря уже о самописных, у которых нет названия))). Но, те которые применяются сейчас в мобильной разработке, как правило различные вариации Clean Architecture - много вариантов с фича модулями, варианты с разными слоями приложения отличными от классики data, domain и тд. особо то и названий конкретных даже нет у них,
Вот этот урок прям огонь.
Видео класс. Пронумеруйте видео в плейлисте, пожалуйста. Сразу все просмотреть не удаётся, приходится видео искать по проставленым своим лайкам.
Номерки как-то не очень на оптимизацию видео влияют (, поэтому просто по порядку в плей лист складываю.
Тимофей, подскажите, создавая приложение с нуля, надо сразу разделять его на модули, т.е. как бы сразу определяя возможность доступа к объектам из других модулей?
Лучше сразу, потому что на старте вы закладываете скелет. Если на старте все правильно сделать, потом функционал вешать на это все в разы проще.
Спасибо! Самый понятный урок про многомодульность. Завалил ТЗ проверочное, так как не занл, что это такое)) Теперь буду знать.
Roman Andrushchenko загляни. Он на укр перевел названия, но андроид разраб вся еще на русском. В конце многомодульность, чистая арх, в общем полный курс по андроид разраб без всякой платы. Преподает в Харьковском универе каком-то.
А если у меня вместо бд будет использоваться singleton, общий принцип такой же?
Да
ВСЕ ПОНЯТНО! СПАСИБО!
Спасибо, хороший ролик. )
Добрый день! Спасибо большое за очень полезные видео! Хотелось бы еще знать что такое фича модули и как с этим работать.
Фича модули в планах.
Спасибо за видео.Коммент в поддержку!
Спасибо)
Все круто. Спасибо. Есть вопрос относительно LiveData в репозитории Domain модуля. Как организовать прослушивание данных к примеру в Room, если Domain модуль самый независимый и LiveData не поддерживается в нем?
Я бы порекомендовал использовать корутины. Domain то самый независимый, но глобальные библиотеки, такие как корутины, rx и подобные, в любом случае там будут. А LiveData конечно лучше туда не закидывать.
@@TimofeyKovalenko Еще раз большое спасибо
Все просмотрел все супер! осталась неясность про подключение пакетов в модулях, столкнулся с тем что в domain недоступен android.util.Log решил через отдельный пакет логировать поставил Timber инициализирую его в Application() соответственно подключен он как зависимость в :app build.gradle а использовать его хочу в domain прописываю импорт в градле domain, сборка выдает "Declare repository providing the artifact" что в таком случае делать?
После разбиения на модули появилось ощущение что файлы проекта лежат друг от друга в 10ти метрах 🤔 и перемещаться между ними приходится физически вставать и ходить то за одним файлом то за другим 🤷♀️
В этом и смысл, что-бы все было далеко друг от друга), что-бы каждый из компонентов работал самостоятельно, не влияя на другие. И так меньше ошибок делается на проекте ).
Спасибо. Очень доступно обяснили)
😀
Тимофей, правильно ли я понимаю что в рамках данного ролика рассматривается пример MVP? Так как MVVM by Google, подразумевает одностороннюю связь между слоями и зависимости по соглашению гугла должны быть вот такого плана UI -> DOMAIN -> DATA
Мы тут не рассматривали MVVM/MVP, тут общая концепция слоев. В данном примере у нас просто активити работает с юз кейсом, MVVM/MVP паттерны тут пока не рассматривали. Посмотрите дальше в плей листе, там есть ролик, где мы добавляем MVVM.
@@TimofeyKovalenko Спасибо, я уже все ролики глянул, когда писал комментарий не подумал прокрутить плейлист) Все доходчиво, все по полочкам)
MVVM это именно архитектурный паттерн
да, но не архитектура приложения, как многие называют. Это всего лишь маленькая часть ответственная за состояние экрана.
@@TimofeyKovalenko не знаю, какой линейкой вы меряете, но эти 4 буквы полностью определяют, на каких принципах будет функционировать приложение, и как связаны его составляющие. можно конечно вьюмодель называть маленькой частью, ответственной за состояние экрана, забыв обо всей логике. и, опять же, смотря что называть архитектурой. сингл-активити тоже по-своему архитектура
Тимофей, а вот этот код который вы в примере используете - есть ли он где-то на гитхабе у вас?
Нет, код стараюсь никогда не скидывать, иначе студенты ничего не делают сами)
@@TimofeyKovalenko Я учусь немного подругому. Я стараюсь перед глазами иметь весь материал, в виде кода - максимально локанично. И отталкиваясь - делать свое. Буду благодарен если вы этим вашим нанопроектом по Clean поделитесь с вашим покорным слугой) Заранее благодарен.)
Спасибо большое!!!
Всё очень понятно.
Ждем MVVM)))
Вышло видео по MVVM: th-cam.com/video/KeQWIu8bA-Y/w-d-xo.html
@@TimofeyKovalenko Спасибо ещё вчера посмотрел
Тимофей, расскажите пожалуйста как делить приложение на фиче модули и по клин одновременно?
Тоесть был один модуль - мод1
И теперь стало:
Мод1-domain
Мод1-presentation
Мод1-data
Так что-ли? Теперь как бы стало модулей в 3 раза больше. Так правильно?
Спасибо
Тут разные подходы могут быть. Как правило на фичи делят presentation модуль, а domain и data остаются как есть. Но в очень большом проекта(очень очень большом с десятками программистов на каждую фичу), каждая фича может иметь свой домен и дату. Об этом еще попозже буду снимать видео.
@@TimofeyKovalenko спасибо за ответ, Тимофей
Но чисто логически если у фиче модулей одна база данных то они тесно связаны, а они в теории должны вообще друг друга не знать, разве нет?
А какая разница, что база одна и та же? Фича работает с юз кейсами и все, больше она ничего не знает. Мыслите всегда публичными методами, которые вам доступны, а то, что за ними, пользователя не должно волновать.
@@TimofeyKovalenko спасибо
Пока сложно это все, буду ждать Ваших видео
@@TimofeyKovalenko сделайте пожалуйста видео по фиче модулям и их сложностям
Добрый день, по просьбе автора задаю вопрос: -Почему мы в активити инициализируем репозиторий, насколько я понимаю это неправильно. Не должен ли это делать, какой-то промежуточный слой?
Должно. В след. видео мы делаем это в вью модел фабрике, а потом в DI. Просто, когда сразу все даешь, у студентов каша в голове. Поэтому все постепенно).