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