Хорошие канал и обзоры! Но, на мой взгляд, есть некоторые нюансы 11:22 для чего оборачивать Defered в suspend функцию, когда можно ограничиться либо одним либо другим? 15:30 launch внутри async создает новую вложенную корутину, оптимальнее использовать withContext для переключения между dispatcher 46:45 вызывать #setValue из вью модели не очень хорошая практика, так как выполняться это обязательно должно на main thread. Лучше использовать #postValue
спасибо, видео как всегда на высоте! ИМХО, с MVP получается очень-очень много файлов, приходится всегда выделять интерфейсы, соответственно, много времени уходит на все это. с MVVM все проще, есть VM, который меняет стейты, и View просто подписывается на нужные значения
с mvvm проблематично разобраться когда садишься за чужой проект и пытаешься вникнуть со всеми подписками. Особенно если их много на экране. С mvp открыл интерфейс и всё становится понятно (если наименования методов нормальные)
Класс, видео топчик!! Очень помогло разобраться в чем разница этих архитектур, да еще и с примером в коде, да еще и в одном видео... да еще и на одном и том же проекте. Не знаю, можно ли это объяснить еще лучше, чем автор
Теперь могу говорить, что делал не говнокод, а по архитектуре MVC😂. А вообще спасибо за урок, столько нового и полезного открыли для меня, раньше не понимал смысл MVP и MVVM, а теперь наконец-то дошло.
Алексей, спасибо за долгожданное видео. Как я понял, не для новичков, а для тех, кто уже поплавал немного. Рассмотрены некоторые проблемы MVP, это радует. Я, наоборот, ушёл от MVP к MVC, потому что в MVP слишком много кода (больше, чем в MVC). На мой взгляд, если грамотно перенести из View методы в другие классы, объём кода во View тоже уменьшится (будет чем-то похоже на MVP). Главным преимуществом MVP, MVVM я бы назвал работу с жизненным циклом Андроида, это нелегко грамотно сделать в MVC. Часто мне рассказывают про тестируемость кода, разделение на слои, изолированность, но я не считаю это чем-то приоритетным, а вот проблема ЖЦ при легковесном вью решается куда проще. В MVP есть ещё одна странность: презентер и вью непрерывно взаимодействуют и вызывают друг друга чаще, чем это делается в MVC. Т.е. надо отобразить список - обращаемся к презентеру, он обращается обратно к вью (покажи прогресс, покажи заглушку, покажи список, скрой прогресс). В MVC это решается в одно действие.
Как я и говорил в видео, основная проблема MVC в том, что его обычно неправильно готовят )) работа с жизненным циклом имхо хорошо сделана только в MVVM да и то потому что Гугл постарался ) ну и Мокси ) а так - все одинаково мучаются. Насчёт тестируемости, разделения на слои и так далее. Это же по сути не имеет отношения конкретно к этим патиернам. Ну то есть в моих проекта MVP (теперь уже MVVM) используется для UI слоя ну или для презентейшн слоя. Это не мешает остальному коду то есть модели быть поделённым на слои и тестируемых. Тоже самое в подходе делегатов со списками ) так что принципы солид и так далее это в целом про разработку а не только про эти паттерны. Ну эт мое имхо )
@@MobileDeveloper Спасибо, рад услышать такой взвешенный ответ. Далеко не все "архитекторы" это понимают и постоянно рассказывают про разделение на слои. Согласен, что MVC, MVP, MVVM - это работа со слоем презентейшен (UI), собственно, в Андроиде это одна из самых больших сложностей, т.к. отделить модель от представления гораздо проще и там почти нет разночтений (достаточно использовать Clean Architecture). Разделение на слои и тестирование более актуально для бека, вот там про архитектуру думают постоянно.
@@MobileDeveloper Извините за рекламу, увидел неплохое видео для новичков по MVVM: th-cam.com/video/QtXddCAAZ8k/w-d-xo.html. Понравилось, что автор рассказывает о плюсах и минусах не как многие: больше про ЖЦ и меньше про тестирование.
как всегда все круто! А есть ли какие-нибудь критерии при выборе архитектуры между MVP и MVVM? Каким вы пользуетесь и какой посоветуете лучше использовать?
Мне лично больше нравится MVP (потому что на мой взгляд он более четко структурирован). Но походу придётся переходить к MVVM, потому что разработчики обеих платформ склоняют к этому.
Ради интереса вопрос, не особо знаком с Android и корутинами, на 14:37 - не будет ли риска утечек памяти в случае, если наш запрос зависнет где-нибудь? Пользователь, например, уже давно закроет эту активити, а в корутине у нас будет висеть жесткая ссылка на textview? Или тут нет такой проблемы? Касательно же MVC - вот все везде повторяют про этот цикл(5:35), про то что model обновляет данные во view... Картинки даже в интернете есть. Но как доходит до реализации - нигде не видел, чтобы люди из модели сразу апдейтили view, всё сводится к тому, что модель возвращает данные в контроллер, а уже он обновляет View. В вашем варианте, в принципе, это тоже так. Так зачем повторять эту мантру про "цикл" и про связь модели с view?
Сейчас используется viewModelScope почти везде (ну где есть вью модель разумеется) либо иной скоуп привязанный к жизни view, тогда никаких утечек не будет. В случае же GlobalScope да, такое возможно + еще есть момент, что если допустим зафейлится одна корутина, то умрут все, потому что они живут в одном скоупе. Ну опять же развитие мое происходит параллельно с выпуском видео, поэтому такое бывает. В случае с тем, что в видео таких рисков не должно быть. Насчет MVC. С MVC забавная штука в том, что как-то так получилось что за View считается Fragment/Activity, а не View (xml) и поэтому такая путаница и все работает неправильно. Вроде бы я про это говорил.
@@MobileDeveloper Я не говорил конкретно про реализации в андроид, я про сам подход. В определении из "интернетов" везде говорится про то что модель связаны с вью и вы тоже про это говорите, но в вашем же примере этого нет. Да и почти никогда не видел такой реализации, ибо это глупо. Я просто уже кучу времени пытаюсь найти четкое и точное определение разницы между MVC и MVP, но не могу... Настолько все по разному их трактуют, что истинно верных MVC и MVP, получается, не существует. Каждый крутит их как он понимает, но при этом, про них очень любят задавать вопросы на собеседованиях...
Отчасти да, но про модель (а именно то, что под ней некоторые понимают и как это связанно с вью) попробуйте найти в видео про MVI. По моему я там про это говорил
Алексей, а разве вью(активти), которую мы атачим в презентере, имеющая слабую ссылку не удалится при вызове сборщика мусора, до изменения конфигурации?
уже второе приложение пишем с MVVM и стейтами. С одной стороны всё неплохо. Но вот всё же тянет назад на MVP+Moxy. Как по мне там код в итоге читабельнее. А это тоже очень важно. А за видео спасибо, ничего нового для себя не открыл, жаль не было такого несколько лет назад, когда я и сам пытался разобраться с этими паттернами.
Классный обзор, хотел добавить по поводу экстеншенов. Если у вас они используют параметризованные типы, то можно делать эти экстеншены linline, будет лучше производительность приложения.
Еще я видел, что во многих видео вью моделе передают контекс, т.к. все равно вью модель создается через провайдер с передачей контекста (хотя сейчас я говорю об андроид вью модели). Но видео топ!
Небольшой вопрос по клину: Правильно ли делать чтобы репозитории возвращали Observable или Deffered, не должен ли этим заниматься интерактор или презентер?
@@MobileDeveloper Готовые объекты, тогда сам репозиторий не будет завязан ни на rx, ни на корутины, а интерактор уже будет оборачивать все это в потоки) Интересно ваше мнение по поводу такого подхода
@@MobileDeveloper Ну room например может возвращать один объект или список, а в retrofit через call.execute(). Можно ещё обернуть ответ в какой-то RepositoryResponse, где будут либо данные, либо ошибка. А потом интерактор все это вызывает в io потоке. Мне просто понравился такой подход из-за того, что сложную логику данных в репозитории можно писать в функциональном стиле и нет привязки к rx и корутинам)
Сам по себе даггер тоже мало что решит, разве что вы неявно протянете контекст в презентер. Нужно передавать в презентер сконфигурированный класс для работы с бд. Сделать это более изящно можно через даггер. Но в целом обычно RoomAppDataSource доступен из application. Обратите внимание на то что ваш слой работы с бд должен быть независим от реализации конкретной бд а логика касающаяся работы рум должна быть вынесена отдельно
А разве это правильно использовать в mvvm фиксированный состояния ? Просто к тому что допустим у меня есть множество observable объектов исходя из которых я и меняю view и рассчитывать для всего этого состояния тоже занимает множество времени
@@MobileDeveloper когда не знаешь Kotlin - сложновато для понимания. Вроде бы понимаешь о чем речь, но при этом и знания java не такие хорошие, чтобы взять и переложить на нее) уровень - подготовка на junior android :)
@@MobileDeveloper в любом случае, спасибо за контент! Объясняешь очень хорошо и наконец-то я хоть где-то у кого-то увидел структуру папок реального нормального проекта!) За это отдельное спасибо!!
Очень жаль, что во многих видео идёт отсылка на другие. С одной стороны понятно, что не хочется рассказывать одно и то же, с другой - проваливаешься в то видео, а там опять отсылка. Все видео посмотреть нет абсолютно никакой возможности, потому что хронометраж уже снят огромный
Тема важная и не простая. Как новичок, из видео нихрена не понял во всей этой каше. Куча открытых файлов, что-то куда-то копируется, миллион правок и дописываний. В общем понял только теорию в переложении на магазин, а как реализовать на практике так и не смог понять.
@@MobileDeveloper если разместить это видео в другом источнике, например в группе вконтакте то это уже будет не канал. Нарушается принцип единой ответственности.
Зачем для объяснения кодить, 50 минут смотреть кажется напряжно, для объяснения архитектур 30 лет назад придумали uml. Кажется тут диаграммой взаимодействия можно обойтись и тогда видео будет 5 минут и будет все понятно.
Спорное утверждение. Видео с диаграммами полным полно и они как раз ничего не объясняют, потому что проблема возникает как раз, когда ты начинаешь все это с бумаги переносить на практику.
@@MobileDeveloper ну я пришел например не с мира мобильной разработки, зачем мне вникать в особенности мобильной среды, когда видео про архитектуру. Я поэтому видео не досмотрел ваше, но ценю ваш труд. Наверно для мобильщиков это будет норм. С другой стороны вот видео индуское th-cam.com/video/izZ858Gbwh0/w-d-xo.html тут далеко не uml, да и инглишь ломанный, но по диаграммам понятно что разница во взаимодействии объектов. Видео короткое, есть визуализация. Многие просто не умеют готовить uml диаграммы, поэтому их и не понимают. Но если я не умею их рисовать это не значит что они плохие. Если они нормально нарисованы, то они дают хорошую визуализацию и мозг легче воспринимает это все. То есть я бы показал в общем сначала концепцию, а потом в коде как у меня это реализовано. В любом случае вы молодцы, удачи.
Да, нет я умею пользоваться диаграммами. Просто канал посвящен именно мобильной разработке, поэтому я показываю код для людей из мобильной разработки) Плюс архитектура MVP и MVC имеет некоторую специфику для мобильной разработки именно ) Спасибо! )
прошу прощения(не баньте меня) но когда я искал инфу про MVC то там говорилось что вьюха общается с моделью через контролер но никак ни напрямую 5:36 , оговорились или я не праильно понял?
А почему я должен вас банить?)) Все правильно view общается через controller, но конкретно в мобилке с этим случилась путаница, так как непонятно, что считать за view в андроиде? Xml? Activity? Проблема вышла в том, что за вью стали считать xml, а так как контроллер вынужден общаться и с моделью и с xml и есть еще разные операции там жизненного цикла, то активити раздувалась до огромных размеров
![Архитектура. MVI [RU] / Мобильный разработчик](http://i.ytimg.com/vi/IRCv3mkc6jY/mqdefault.jpg)
Прошу прощения случилась накладка. Промокод дает 20% скидку, но я считаю, что это тоже очень много :)
Хорошие канал и обзоры! Но, на мой взгляд, есть некоторые нюансы
11:22 для чего оборачивать Defered в suspend функцию, когда можно ограничиться либо одним либо другим?
15:30 launch внутри async создает новую вложенную корутину, оптимальнее использовать withContext для переключения между dispatcher
46:45 вызывать #setValue из вью модели не очень хорошая практика, так как выполняться это обязательно должно на main thread. Лучше использовать #postValue
Да это все учел в будущих своих проектах ) спасибо за ваш комментарий
Это очень круто, то что ты делаешь , а главное бесплатно, то бишь для начинающего не всегда есть возможность использовать платное обучение.
Спасибо :)
спасибо, видео как всегда на высоте!
ИМХО, с MVP получается очень-очень много файлов, приходится всегда выделять интерфейсы, соответственно, много времени уходит на все это.
с MVVM все проще, есть VM, который меняет стейты, и View просто подписывается на нужные значения
Ну как говорится на вкус и цвет ) на мой взгляд MVVM не так структурирован как MVP
Там где много recyclerview mvvm по-моему не очень, много лишних подписок
с mvvm проблематично разобраться когда садишься за чужой проект и пытаешься вникнуть со всеми подписками. Особенно если их много на экране. С mvp открыл интерфейс и всё становится понятно (если наименования методов нормальные)
О да )) MVVM очень запутанная штука
@@MobileDeveloper Почему вы не рекомендуете MVVM.
Google Android рекомендует MVVM
35:50 - MVVM
Класс, видео топчик!! Очень помогло разобраться в чем разница этих архитектур, да еще и с примером в коде, да еще и в одном видео... да еще и на одном и том же проекте. Не знаю, можно ли это объяснить еще лучше, чем автор
Спасибо!
Теперь могу говорить, что делал не говнокод, а по архитектуре MVC😂. А вообще спасибо за урок, столько нового и полезного открыли для меня, раньше не понимал смысл MVP и MVVM, а теперь наконец-то дошло.
Пожалуйста :)
тоже себя поймал на этой мысле с первым приложением в маркете))
Спасибо за видео!) Было бы интересно увидеть от Вас видео о связке паттернов со всевозможными Сервисами\Службами в Android (Jobintent\Intent тд)
Оооо ) спасибо за вопрос это интересная тема. Как-нибудь сниму
@@MobileDeveloper надеюсь, не затерялась тема среди других возможных, очень интересно было бы увидеть ваше видео на эту тему
Не затерялась, но тем много. Пока я сам решаю какие видео снимать, но вы можете влиять на темы выпусков за небольшой донат
M(VC, VP, VVM) - так-то V тоже можно за скобки вынести))
Роль V в MVC чутка отличается от других, но я вообще считаю MVP частным случаем MVC, так что в MVC можно сделать и не хуже.
Ну вообще да )) Ну да ладно )
Нет это не частный случай - там разные связи между сущностями
По идее, да, но если убрать часть связей, получится MVP, могу ошибаться.
Как говорит мой папа если бы у бабушки был первичный половой орган мужчины мы бы звали ее по другому )))
Алексей, спасибо за долгожданное видео. Как я понял, не для новичков, а для тех, кто уже поплавал немного. Рассмотрены некоторые проблемы MVP, это радует. Я, наоборот, ушёл от MVP к MVC, потому что в MVP слишком много кода (больше, чем в MVC). На мой взгляд, если грамотно перенести из View методы в другие классы, объём кода во View тоже уменьшится (будет чем-то похоже на MVP). Главным преимуществом MVP, MVVM я бы назвал работу с жизненным циклом Андроида, это нелегко грамотно сделать в MVC. Часто мне рассказывают про тестируемость кода, разделение на слои, изолированность, но я не считаю это чем-то приоритетным, а вот проблема ЖЦ при легковесном вью решается куда проще.
В MVP есть ещё одна странность: презентер и вью непрерывно взаимодействуют и вызывают друг друга чаще, чем это делается в MVC. Т.е. надо отобразить список - обращаемся к презентеру, он обращается обратно к вью (покажи прогресс, покажи заглушку, покажи список, скрой прогресс). В MVC это решается в одно действие.
Как я и говорил в видео, основная проблема MVC в том, что его обычно неправильно готовят )) работа с жизненным циклом имхо хорошо сделана только в MVVM да и то потому что Гугл постарался ) ну и Мокси ) а так - все одинаково мучаются. Насчёт тестируемости, разделения на слои и так далее. Это же по сути не имеет отношения конкретно к этим патиернам. Ну то есть в моих проекта MVP (теперь уже MVVM) используется для UI слоя ну или для презентейшн слоя. Это не мешает остальному коду то есть модели быть поделённым на слои и тестируемых. Тоже самое в подходе делегатов со списками ) так что принципы солид и так далее это в целом про разработку а не только про эти паттерны. Ну эт мое имхо )
@@MobileDeveloper Спасибо, рад услышать такой взвешенный ответ. Далеко не все "архитекторы" это понимают и постоянно рассказывают про разделение на слои. Согласен, что MVC, MVP, MVVM - это работа со слоем презентейшен (UI), собственно, в Андроиде это одна из самых больших сложностей, т.к. отделить модель от представления гораздо проще и там почти нет разночтений (достаточно использовать Clean Architecture). Разделение на слои и тестирование более актуально для бека, вот там про архитектуру думают постоянно.
Как говорит моя мама - заставь дурака богу молиться он лоб расшибет )) у некоторых архитекторов есть нечто похожее
@@MobileDeveloper Извините за рекламу, увидел неплохое видео для новичков по MVVM: th-cam.com/video/QtXddCAAZ8k/w-d-xo.html. Понравилось, что автор рассказывает о плюсах и минусах не как многие: больше про ЖЦ и меньше про тестирование.
Отличное видео от понимающего человека :)
как всегда все круто! А есть ли какие-нибудь критерии при выборе архитектуры между MVP и MVVM? Каким вы пользуетесь и какой посоветуете лучше использовать?
Мне лично больше нравится MVP (потому что на мой взгляд он более четко структурирован). Но походу придётся переходить к MVVM, потому что разработчики обеих платформ склоняют к этому.
Ради интереса вопрос, не особо знаком с Android и корутинами, на 14:37 - не будет ли риска утечек памяти в случае, если наш запрос зависнет где-нибудь? Пользователь, например, уже давно закроет эту активити, а в корутине у нас будет висеть жесткая ссылка на textview? Или тут нет такой проблемы?
Касательно же MVC - вот все везде повторяют про этот цикл(5:35), про то что model обновляет данные во view... Картинки даже в интернете есть. Но как доходит до реализации - нигде не видел, чтобы люди из модели сразу апдейтили view, всё сводится к тому, что модель возвращает данные в контроллер, а уже он обновляет View. В вашем варианте, в принципе, это тоже так. Так зачем повторять эту мантру про "цикл" и про связь модели с view?
Сейчас используется viewModelScope почти везде (ну где есть вью модель разумеется) либо иной скоуп привязанный к жизни view, тогда никаких утечек не будет. В случае же GlobalScope да, такое возможно + еще есть момент, что если допустим зафейлится одна корутина, то умрут все, потому что они живут в одном скоупе. Ну опять же развитие мое происходит параллельно с выпуском видео, поэтому такое бывает. В случае с тем, что в видео таких рисков не должно быть.
Насчет MVC. С MVC забавная штука в том, что как-то так получилось что за View считается Fragment/Activity, а не View (xml) и поэтому такая путаница и все работает неправильно. Вроде бы я про это говорил.
@@MobileDeveloper Я не говорил конкретно про реализации в андроид, я про сам подход. В определении из "интернетов" везде говорится про то что модель связаны с вью и вы тоже про это говорите, но в вашем же примере этого нет. Да и почти никогда не видел такой реализации, ибо это глупо. Я просто уже кучу времени пытаюсь найти четкое и точное определение разницы между MVC и MVP, но не могу... Настолько все по разному их трактуют, что истинно верных MVC и MVP, получается, не существует. Каждый крутит их как он понимает, но при этом, про них очень любят задавать вопросы на собеседованиях...
Отчасти да, но про модель (а именно то, что под ней некоторые понимают и как это связанно с вью) попробуйте найти в видео про MVI. По моему я там про это говорил
О видос на вечер. Благодарствую
Спасибо!
Можно ли сделать видео по разбору MVI (Model-View-Intent)? Он сейчас становится популярным
Да сделаю )
Алексей, а разве вью(активти), которую мы атачим в презентере, имеющая слабую ссылку не удалится при вызове сборщика мусора, до изменения конфигурации?
классный канал в целом да и много плюшек узнал, подходов
Спасибо )
уже второе приложение пишем с MVVM и стейтами. С одной стороны всё неплохо. Но вот всё же тянет назад на MVP+Moxy. Как по мне там код в итоге читабельнее. А это тоже очень важно. А за видео спасибо, ничего нового для себя не открыл, жаль не было такого несколько лет назад, когда я и сам пытался разобраться с этими паттернами.
Да, как говорят дорога ложка к обеду. Ну все равно рад, что понравилось
Хотите узнать что-то о паттернах - найдите другое видео. Сэкономите час жизни
А про AAC будет?
Про что?)
@@MobileDeveloper android architecture components. Или уже было?
TiMYP64 нет ещё не было ) но будет обязательно
Интересное видео, спасибо
А как поведет себя код, если я успею два раза нажать кнопку LOGIN? Кнопка будет еще не заблокирована и пойдет второй запрос?
Классный обзор, хотел добавить по поводу экстеншенов. Если у вас они используют параметризованные типы, то можно делать эти экстеншены linline, будет лучше производительность приложения.
Тоже верно ) спасибо! Век живи, век учись как говорится
То есть MVC в android при разработке фактически не используется?
Ну практически да
У вас в плейлисте Архитектура второе видео с другого канала (про евровидение). Как это? Что это?)
Это случайно ))) один блоггер из Томска ))
Давай видео про model view intent
Не знаю есть ли смысл про это отдельно снимать ) mvi не очень большое распространение имеет )
Добрый день! А что за классы sealed? И почему не создать простой Enum? Просто с джавы перешел на котлету, не слышал про них:)
Sealed class это возможность четко ограничить число наследников класса ) что позволяет с ними работать как в enum
@@MobileDeveloper Спасибо.
ну и с sealed классами в when не надо использовать else
@@pavlosoia Прошло 6 месяцев, без силдов жить не могу )
Спасибо за видео, а можно название фонового трека узнать?)
Название не скажу, но вот сам трек. Взято из музыкального банка TH-cam.
hdd.tomsk.ru/desk/unxlonmc#
А как же MVI?
Сделал даже опрос ) ну видимо сделаю отдельное видео ) хотя mvi это не самостоятельный паттерн и я это покажу в видео )
Еще я видел, что во многих видео вью моделе передают контекс, т.к. все равно вью модель создается через провайдер с передачей контекста (хотя сейчас я говорю об андроид вью модели). Но видео топ!
Спасибо )) я все таки сторонник подхода что контекст должен быть только у контекстозависимых вещей )
Такой вот вопрос у меня - Что лучше использовать?
1 - findViewById
2 - synthetic
3 - dataBinding ?
Мне больше всего нравится второй вариант )
@@MobileDeveloper synthetic больше не поддерживается, получается ты вынужден использовать dataBinding в проектах где много визуальных элементов?
Я использую findViewById
Небольшой вопрос по клину: Правильно ли делать чтобы репозитории возвращали Observable или Deffered, не должен ли этим заниматься интерактор или презентер?
А что будет возвращать репозиторий тогда?)
@@MobileDeveloper Готовые объекты, тогда сам репозиторий не будет завязан ни на rx, ни на корутины, а интерактор уже будет оборачивать все это в потоки) Интересно ваше мнение по поводу такого подхода
Я бы посмотрел как вы вытащите готовые объекты из room или retrofit без колбэков rx или корутин))
@@MobileDeveloper Ну room например может возвращать один объект или список, а в retrofit через call.execute(). Можно ещё обернуть ответ в какой-то RepositoryResponse, где будут либо данные, либо ошибка. А потом интерактор все это вызывает в io потоке. Мне просто понравился такой подход из-за того, что сложную логику данных в репозитории можно писать в функциональном стиле и нет привязки к rx и корутинам)
Как поступить, если в MVP нужно получить например данные из базы, а там нужно в параметры context передать
использовать даггер
Сам по себе даггер тоже мало что решит, разве что вы неявно протянете контекст в презентер. Нужно передавать в презентер сконфигурированный класс для работы с бд.
Сделать это более изящно можно через даггер. Но в целом обычно RoomAppDataSource доступен из application. Обратите внимание на то что ваш слой работы с бд должен быть независим от реализации конкретной бд а логика касающаяся работы рум должна быть вынесена отдельно
Не совсем понял. Если у нас есть такая хорошая библиотека moxy под MVP, то почему бы не применять ее всегда ?
Есть масса причин не использовать сторонние библиотеки - от безопасности до подхода
А разве это правильно использовать в mvvm фиксированный состояния ? Просто к тому что допустим у меня есть множество observable объектов исходя из которых я и меняю view и рассчитывать для всего этого состояния тоже занимает множество времени
Да я там немножко от MVI взял, в целом, в каноничном MVVM правильнее на каждую вью иметь свои observable
О и давно у тебя звуковой пульт ?)
Нет ) это первое видео ))
Лучшее ru объяснение в интернете, так держать!
Спасибо! ))
а есть тоже самое на java? (
Нет, но не думаю, что это сложно на java переложить все.
@@MobileDeveloper когда не знаешь Kotlin - сложновато для понимания. Вроде бы понимаешь о чем речь, но при этом и знания java не такие хорошие, чтобы взять и переложить на нее) уровень - подготовка на junior android :)
@@MobileDeveloper в любом случае, спасибо за контент! Объясняешь очень хорошо и наконец-то я хоть где-то у кого-то увидел структуру папок реального нормального проекта!) За это отдельное спасибо!!
Пожалуйста :)
люблю твои видео
Спасибо )
Видео хорошее, лайк поставил, но делиться им в соц сетях я конечно же не буду.
Это типа шутка такая?)
in mvvm viewmodel must extends ViewModel Class or AndroidViewModel,,,in AndroidViewModel we have a context
Все равно это плохой паттерн) никто меня в этом не переубедит )
Очень жаль, что во многих видео идёт отсылка на другие. С одной стороны понятно, что не хочется рассказывать одно и то же, с другой - проваливаешься в то видео, а там опять отсылка. Все видео посмотреть нет абсолютно никакой возможности, потому что хронометраж уже снят огромный
Павел Качан, а кто неудачные дубли будет вырезать?)) Ждём видос про Флаттер
Можно таймкод неудачного дубля попросить вас скинуть?
@@paulk3222 37:08, 57:50 , ещё вроде где-то было, уже не помню
Вроде там ничего такого нет )
Лайк не глядя!
Спасибо!
)
Музыка на фоне.... такая мрачная...
в уроке по dagger музыка была бомбовой
Надо будет найти ее )) вообще музыку стараюсь разную делать ) и чтобы не мешала )
А кстати как называется? Очень зашла!
Не смог зашазамить, риквестую трек
Его нет нигде кроме этих видео ) но я попрошу выложить где нибудь )
Тема mvc раскрыта не полностью. Существует ещё как минимум две реализации этой архитектуры. Достаточно заглянуть в вики
Вот кому интересно, тот и заглянет. MVC практически не встретишь в андроиде, поэтому на нем не акцентировал внимание
Самый простой способ решить проблему переворота экрана:
android:screenOrientation="portrait"
Окей эту проблему решили ) а что насчёт других ситуаций когда Активити умирает? Или когда нужно переворачивать экран?)
а что тогда делать если в приложении надо открыть камеру и повернуть экран?
Тема важная и не простая. Как новичок, из видео нихрена не понял во всей этой каше. Куча открытых файлов, что-то куда-то копируется, миллион правок и дописываний. В общем понял только теорию в переложении на магазин, а как реализовать на практике так и не смог понять.
Если что, винду можно активировать при помощи проги "KMSAuto"
Это не мой компьютер ) дома я лицензионную винду юзать
Научи клавиатурой шелестеть 😀
@@nersomy в смысле? 😂
@@MobileDeveloper Та такой шелист в видео слышно немного утомляет ну это я наверно нервный )))
Какой мерзкий звук у клавиатуры :)
Ну что вы хотите этому видео уже несколько лет) у меня не сразу появился хороший микрофон и камера)
Когда ты говоришь "это значит вы на канале
Mobile Developer ", нарушается архитектура SOLID.
😂 долго думал, но так и не понял где именно )
@@MobileDeveloper если разместить это видео в другом источнике, например в группе вконтакте то это уже будет не канал. Нарушается принцип единой ответственности.
@@antonalyabyev5207 может принцип замены Барбары Лисков?
@@antonalyabyev5207 ничего не нарушается, неудачный пример
Неплохо, но это не для начинающих
Там нигде обратного не сказано ))
Зачем для объяснения кодить, 50 минут смотреть кажется напряжно, для объяснения архитектур 30 лет назад придумали uml. Кажется тут диаграммой взаимодействия можно обойтись и тогда видео будет 5 минут и будет все понятно.
Спорное утверждение. Видео с диаграммами полным полно и они как раз ничего не объясняют, потому что проблема возникает как раз, когда ты начинаешь все это с бумаги переносить на практику.
@@MobileDeveloper ну я пришел например не с мира мобильной разработки, зачем мне вникать в особенности мобильной среды, когда видео про архитектуру. Я поэтому видео не досмотрел ваше, но ценю ваш труд. Наверно для мобильщиков это будет норм. С другой стороны вот видео индуское th-cam.com/video/izZ858Gbwh0/w-d-xo.html тут далеко не uml, да и инглишь ломанный, но по диаграммам понятно что разница во взаимодействии объектов. Видео короткое, есть визуализация. Многие просто не умеют готовить uml диаграммы, поэтому их и не понимают. Но если я не умею их рисовать это не значит что они плохие. Если они нормально нарисованы, то они дают хорошую визуализацию и мозг легче воспринимает это все. То есть я бы показал в общем сначала концепцию, а потом в коде как у меня это реализовано. В любом случае вы молодцы, удачи.
Да, нет я умею пользоваться диаграммами. Просто канал посвящен именно мобильной разработке, поэтому я показываю код для людей из мобильной разработки) Плюс архитектура MVP и MVC имеет некоторую специфику для мобильной разработки именно ) Спасибо! )
странные звуки (музыка?) на фоне. мешает смотреть
прошу прощения(не баньте меня) но когда я искал инфу про MVC то там говорилось что вьюха общается с моделью через контролер но никак ни напрямую 5:36 , оговорились или я не праильно понял?
А почему я должен вас банить?)) Все правильно view общается через controller, но конкретно в мобилке с этим случилась путаница, так как непонятно, что считать за view в андроиде? Xml? Activity? Проблема вышла в том, что за вью стали считать xml, а так как контроллер вынужден общаться и с моделью и с xml и есть еще разные операции там жизненного цикла, то активити раздувалась до огромных размеров