Можно поддержать автора и канал 🤝 купив полный курс по MVVM здесь: boosty.to/mr.developer/posts/fe32632b-1f7e-4c82-9a8e-d2a4e2cb2146?share=post_link Список уроков: 1. Создание проекта. 2. Заполнение activity_main.xml. 3. Заполнение fragment_main.xml. Добавление note_item.xml 4. Заполнение макетов. Добавление кнопок на тулбар 5. Инициализация объектов в MainActivity 6. Инициализация StartFragment.kt, создание модели AppNote.kt 7. Создание DatabaseRepository.kt, реализация репозитория Room 8. Создание базы данных AppRoomDatabase.kt 9. Переход с MainFragment.kt на AddNewNoteFragment.kt 10. Создание новой заметки 11. Заполнение RecyclerView. Отображение списка заметок 12. Переход в NoteFragment.kt, удаление заметки из БД 13. Настройка поведения навигационного графа 14. Создание с нуля проекта в Firebase 15. Подключение к Firebase 16. Макет для выбора базы данных 17. Быстрая авторизация в Firebase 18. Создание LiveData для работы с Firebase 19. Создание новой заметки в Firebase 20. Удаление заметки из Firebase 21. Реализация функции выхода из аккаунта Firebase 22. Добавление анимации в навигацию 23. Сохранение настроек в SharedPreference. Где применим стек технологий: -Android SDK; -Kotlin; -MVVM; -LiveData; -ViewModel; -Room (SQLite); -Navigation; -Kotlin Coroutines; -Firebase SDK; -RecyclerView.
Как же вы классно объясняете материал. Вот от вас бы посмотреть про MVI паттерн. Пока буду смотреть этот, но надеяться, что вы снимите серию про MVI. У вас дар. Спасибо.
Bro, ты крутой конечно, долгожданный выпуск, только пожалуйста не останавливайся, я каждый день жду твой курс, архитектура - это супер, удачи во всех делах
Это было лучшее видео с объяснением того как работает MVVM!!! Большое спасибо!!! До этого я смотрел кучу роликов где сразу вываливали кучу кода и говорили как это прекрасно использовать MVVM а теперь я начал понимать как вся эта цепочка работает. Еще раз огромное спасибо!
как раз вообще ничего не понятно без примера кода . бред со стрелочками. поле этого видео вы что-то можете сделать ? вам хоть что-то понятно как это делать ?)) прям посмотрел и готов идти код пробовать ?) мне вот прогеру со стажем вообще не понятно . mvc бы построил и не ипал голову вью моделью ибо не понятно что это и главное зачем она когда есть ендпоинты
ну вот смотришь на эту схему, я где то на 10 минуте остановился, и задаешься вопросом, зачем нам ViewModel ? какая то там LiveData, почему это не может делать модель? почему модель не может уведомлять View ? зачем этот прокси объект все равно так и не понятно.
Как мне повезло, что нашел ваш канал! Без воды, четкая и грамотная речь без слов паразитов, без всяких отсылок к сторонним ресурсам! Пожалуйста, не бросайте канал! Продолжайте! Лайк и подписка!
Нереально полезное видео, подобного даже близко не было на ютубе, всегда с оговрками, всегда с каким-то непонятным языком, тут же все прекрасно, надеюсь будешь продолжать и наберешь намного больше аудитории) Я думаю уже очень в скором времени.
Бизнес логику перенесите во 2 слой и будет клаcсическая SOA архитектура для веб-приложений. в общем, за последние 15 лет изменились на паттерны, а их описания. Серебряной пули не существует. А в целом - гут! Очень понятно и просто рассказано! )
немного не понятно что из модели относится к тому что в самом телефоне будет, что будет относиться к бекенду, которое работает с базой данных. Или тут имеется в виду все это находится в телефоне, а БД это типа Firebase у которой свое API ? тогда причем тут замена базы данных? второе, ну вот есть MVC по сути одной стрелочкой отличается, то что не MV уведомляет V а M точно также уведомляет V о том что есть данные, забери их. В общем тема до конца не раскрыта.
Спасибо. Супер видео. С нетерпением жду продолжения. Очень редко где понятным языком и по полочкам раскладывают. Было бы классно параллельно лекции ещё делать пример что бы все это руками потрогать.
Годно, уже работал с данным паттерном,создавая приложение "Заметки", с помощью паттерна Repositories, в котором прописывается основная бизнес - логика приложения. Спасибо за твоё видео, освежил память)
Я так понимаю что ViewModel должен инкапсулировать не модель, а сервисы бизнес-слоя, а моделил тут это доменные модели но тогда должны быть модели уровня View которые данные для отрисовки предаставляют иначе слои "потекут"?
Простое объяснение, спасибо. Единственное чего я бы хотел увидеть - это немного кода для практики, теория это хорошо, но завтра она вылетит из головы, нужно написать, чтобы запомнить.
Всё хорошо, только БД это DB )) И ещё в конце ты правильный вопрос задал: зачем это надо? Но потом прям радикально решил вьюхой стучаться в БД. А почему вью не может стучаться в модель? Из всего ролика я понял, что VM это какой-то посредник между вью и моделью и он ничего не делает. Вообще, я на Unity разрабатываю, и решил посмотреть, как же там обычные программисты используют паттерны, чтоб попробовать это в геймдеве. И вот в Unity вью это монобех (по сути отдельный класс, в котором можно и всю логику игры написать), который в принципе может и сам хранить данные для отображения. Поэтому у меня и возник такой вопрос насчет VM. Если в андроиде вью это нечто другое, нечто более легкое, чем монобех в юнити, тогда вопрос отпадает. Поясни, если не сложно)
По архитектурам есть курс на Coursera "Архитектура Android-приложений" от МФТИ, там как раз проходятся принципы сначала MVP, а потом MVVM, причём архитектуры внедряются на одно приложение без архитектуры + сначала реализуются свои классы, а потом готовая библиотека (Moxy и Architecture Components)
Здравствуйте.У меня возник вопрос. При таком подходе,когда существуют другие вспомогательные классы, к примеру классы сортировки данных или классы, которые изменяют в зависимости от данных интерфейс экрана ( цвет или размер элементов) нужно также все предоставлять через ViewModel?
Хорошая подача материала, интересный контент Возник вопрос - на реальных проектах действительно такое разграничение ? то есть кто то модель пишет, а кто-то исключительно представление (view)
Приветствую, спасибо за хорошо изложенный материал! У меня вопрос - при MVVM, где реализуется сама бизнес логика приложения? В Model или во ViewVodel? То есть если при каком либо действии пользователя нам не нужно запрашивать данные из БД или из веб сервера, а просто произвести над имеющимися данными какие либо изменения и предоставить пользователю, где размещать логику, которая будет заниматься этими изменениями в VM или в M?
Спасибо за урок. Очень хорошая подача материала. Но вот один момент все же остался непонятным. Когда заходит речь о любой разновидности трехслойной архитектуры, то чаще всего в качестве аргумента "зачем" приводят возможную смену СУБД. Но согласитесь, это ведь совсем не жизненный пример. Чаще всего СУБД остается той же весь жизненный цикл приложения. А если она и меняется, то как правило ради каких-то "фишек", которые есть в новой СУБД.И чтобы использовать эти фишки, нужно еще и логику приложения поменять, а не только поменять драйвер БД. Есть более практичные аргументы в пользу такого разделения? Я знаю только один профит - это изолирование бизнес-логики от инструментального окружения, чтобы можно было писать модульные тесты этой логики. И второй вопрос - в чем преимущество MVVM перед той же MVC или MVP? Как понять в каких случаях что лучше использовать?
Спасибо за отзыв. 1. MVVM несет не только пользу в виде замены БД, это просто явный пример, который можно показать. Так же это масштабируемость, тестирование, поддержка кода, чтение кода, минимизация логических ошибок. 2. MVC и MVP хорошие потерны, но устаревшие. Главное преимущество это то, что ViewModel не имеет ссылок на View, а передает состояние STATE. Это решает много проблем. Так же, у Google есть Android Arch. Components которые отлично ложатся на MVVM.
Согласен, замена БД - почти нереальный случай. Во всех этих архитектурах UI-слоя хотят вынести обращение к БД/сети из UI-слоя. Это улучшает поддержку кода, позволяет обращаться одними и теми же методами к модели из разных View. Когда все обращения прописаны во View, становится очень жёстко, приходится одно и то же писать в разных View, а любые изменения в модели ведут к рефакторингу сразу в нескольких View. Эти архитектуры направлены на борьбу с ЖЦ Андроида. Когда поворот экрана пересоздаёт View, было бы неправильно снова считывать или посылать данные в модель. Поэтому модель становится независимой от ЖЦ, а View продолжает создаваться и исчезать. ViewModel намного лучше Presenter. Presenter, по сути, не так далеко от View ушёл, его тоже приходится сохранять во время смены конфигурации. Затем снова пробрасывать данные во View. Там есть неконсистентные состояния. Во ViewModel же данные подхватываются во View через Observable.
10:59 в реальности, конечно, поменять бд не получится, хоть с mvvm хоть без него. Так не бывает, и надеяться на это не стоит. Весь код превратится в гавно через полтора года, и все надо будет переписать. Именно так надо проектировать работу, и концентрироваться на текущем моменте и бизнес задачах. P. S: Урок отличный, спасибо, продолжайте
тоже не правда, вы можете менять поведение какого то модуля, но у вас не будет меняться все приложение, во первых так практически никогда не бывает, во вторых если что-то меняешь, меняешь во всех модулях, т.е. добавил поле, ты его и в модели, и в VM и View везде будешь менять и прокидывать. И да, типа можно было View в базу данных :) ну это слишком прямой путь, почему View не может в Model слой ходить за данными?
Такие схемы показывают в каждом видео по паттернам, но ни в одном из них, к сожалению, не раскрывают главную на мой взгляд тему - роль ViewModel (также как роль Controller в MVC, или Presenter в MVP). Да, все говорят, что "они делают то-то и то-то". Но человеку уже дозревшему до изучения паттернов очень сложно уложить в голове идею, что какой-то класс служит ретранслятором для запросов между двумя другими классами - нафиг это нужно?..)) Понять это можно только увидев код, а код никто не показывает. А нужен-то всего лишь утрированный пример - хоть для приложения с одной кнопкой - и все сложится. Я, например, таких примеров не видел, и потому не могу сказать, что понял эти паттерны.
Идея понятна, только я не до конца понял зачем, чтоб удалить элемент списка, нужно опять обращаться к бд и скачивать тот же список только без одного элемента?! За видео спасибо)
@@mr.developer тоже не понятно. Разве не правильнее просто отправить уведомление от View на удаление такого-то элемента? Зачем перечитывать? И зачем нужен ViewModel? Почему бы просто из View не общаться с Model? По-моему, какое-то лишнее нагромождение. Ведь по сути он делает то же самое, что и View, только в виртуальном виде у себя в памяти.
Схема понятна, но роль ViewModel совсем не понятна. Тема не раскрыта. По-моему, этот элемент лишний. Почему бы из View не обращаться напрямую к Model? Зачем городить огород?
прикол в том, что в 99% случаев, базу никто никогда не будет менять))) да, ясно что для огромных проектов это удобно с точки зрения компоновки пакетов, всё в разных файликах, более менее стандартизировано, но для большинства задач - можно просто из вью идти в бд)
@@mr.developer я бы к дуболому который боится сделать шаг влево/вправо от стандарта потому что так написано в книжке, никогда бы сама не пошла. нужно понимать в каких случаях и что актуально. важна целесообразность, Вась. ты бы у меня собеседос скорее всего провалил. ты ж наверно из тех, кто ради одного запроса в сеть будет ставить ретрофит и окхттп, ага? (с мотивацией: "на всякий случай")
![Архитектура. M(VC, VP, VVM) [RU] / Мобильный разработчик](http://i.ytimg.com/vi/rb0lobFwZbg/mqdefault.jpg)
Можно поддержать автора и канал 🤝 купив полный курс по MVVM здесь:
boosty.to/mr.developer/posts/fe32632b-1f7e-4c82-9a8e-d2a4e2cb2146?share=post_link
Список уроков:
1. Создание проекта.
2. Заполнение activity_main.xml.
3. Заполнение fragment_main.xml. Добавление note_item.xml
4. Заполнение макетов. Добавление кнопок на тулбар
5. Инициализация объектов в MainActivity
6. Инициализация StartFragment.kt, создание модели AppNote.kt
7. Создание DatabaseRepository.kt, реализация репозитория Room
8. Создание базы данных AppRoomDatabase.kt
9. Переход с MainFragment.kt на AddNewNoteFragment.kt
10. Создание новой заметки
11. Заполнение RecyclerView. Отображение списка заметок
12. Переход в NoteFragment.kt, удаление заметки из БД
13. Настройка поведения навигационного графа
14. Создание с нуля проекта в Firebase
15. Подключение к Firebase
16. Макет для выбора базы данных
17. Быстрая авторизация в Firebase
18. Создание LiveData для работы с Firebase
19. Создание новой заметки в Firebase
20. Удаление заметки из Firebase
21. Реализация функции выхода из аккаунта Firebase
22. Добавление анимации в навигацию
23. Сохранение настроек в SharedPreference.
Где применим стек технологий:
-Android SDK;
-Kotlin;
-MVVM;
-LiveData;
-ViewModel;
-Room (SQLite);
-Navigation;
-Kotlin Coroutines;
-Firebase SDK;
-RecyclerView.
Подскажите, пожалуйста, как происходит доступ к курсу? Он приходит на эмэил ?
"Детские объяснения" на первых 7ми минутах.... дальше не знаю, не смотрел.... но буду!
Как же вы классно объясняете материал. Вот от вас бы посмотреть про MVI паттерн. Пока буду смотреть этот, но надеяться, что вы снимите серию про MVI. У вас дар. Спасибо.
Продолжай пожалуйста, у тебя очень годный канал
Благодарю за отзыв
Очень хорошо, что наткнулся на ваш канал. Очень все доступно. Спасибо.
Наконец-то хоть кто-то нормально, по-человечески объяснил, спасибо огромное!!!
Благодарю за отзыв 🤝
Наконец хоть одно нормальное объяснение. Респект
Коротко и информативно, без всякой воды. Большое спасибо за видео!
Bro, ты крутой конечно, долгожданный выпуск, только пожалуйста не останавливайся, я каждый день жду твой курс, архитектура - это супер, удачи во всех делах
Благодарю за отзыв)
Очень круто. Спасибо
Очень крутая тема и видео, спасибо большое
Это было лучшее видео с объяснением того как работает MVVM!!! Большое спасибо!!! До этого я смотрел кучу роликов где сразу вываливали кучу кода и говорили как это прекрасно использовать MVVM а теперь я начал понимать как вся эта цепочка работает. Еще раз огромное спасибо!
как раз вообще ничего не понятно без примера кода . бред со стрелочками. поле этого видео вы что-то можете сделать ? вам хоть что-то понятно как это делать ?)) прям посмотрел и готов идти код пробовать ?) мне вот прогеру со стажем вообще не понятно . mvc бы построил и не ипал голову вью моделью ибо не понятно что это и главное зачем она когда есть ендпоинты
Вы выдаёте то что я ищу и никак не могу понять большое спасибо👍👍👍
Как же круто объяснил! Подписываюсь, ставлю лайк и продолжаю просмотр!!!
Красавчик, то что нужно
Благодарю за отзыв, очень приятно ☺️🤝
Только после этого видео, наконец-то, понял разницу между всеми mv.
Огромное спасибо!
Благодарю за отзыв, очень приятно ☺️🤝
"У меня не будет здесь поставленного слога, красивых выражений", а сам очень хорошо рассказал.
Благодарю за отзыв )
Спасибо за ваш труд! Тема очень интересует, с нетерпением ждем продолжения!
Благодарю за отзыв)
ну вот смотришь на эту схему, я где то на 10 минуте остановился, и задаешься вопросом, зачем нам ViewModel ? какая то там LiveData, почему это не может делать модель? почему модель не может уведомлять View ? зачем этот прокси объект все равно так и не понятно.
Спасибо Юрий за прекрасно проделанную работу, обьсняешь просто, доступно и наглядно жаль что не развиваешь канал. Я бы к тебе пошел учиться
Благодарю вас за отзыв 🤝
Как мне повезло, что нашел ваш канал!
Без воды, четкая и грамотная речь без слов паразитов, без всяких отсылок к сторонним ресурсам!
Пожалуйста, не бросайте канал! Продолжайте!
Лайк и подписка!
Гонишь, не понятно
Спасибо за труды ваши..очень интересно!
Благодарю вас за отзыв 🤝
просто и понятно 🤌
Нереально полезное видео, подобного даже близко не было на ютубе, всегда с оговрками, всегда с каким-то непонятным языком, тут же все прекрасно, надеюсь будешь продолжать и наберешь намного больше аудитории) Я думаю уже очень в скором времени.
Благодарю за отзыв
Все четко и понятно. Респект!)
Благодарю за отзыв 🤝
Спасибо за такой контент, очень долго искал нормального объяснения ))
Спасибо тебе, добрый ты человек.
Начинающим прям огонь. Всё наглядно!
Благодарю вас за отзыв 🤝
Отличная подача материала и простое объяснение!
Спасибо большое за видео!
Бизнес логику перенесите во 2 слой и будет клаcсическая SOA архитектура для веб-приложений.
в общем, за последние 15 лет изменились на паттерны, а их описания.
Серебряной пули не существует.
А в целом - гут! Очень понятно и просто рассказано! )
Постарайтесь делать все как на видео, я уже не помню, что и как там сделано.
СПАСИБО ЗА ВИДЕО
немного не понятно что из модели относится к тому что в самом телефоне будет, что будет относиться к бекенду, которое работает с базой данных. Или тут имеется в виду все это находится в телефоне, а БД это типа Firebase у которой свое API ? тогда причем тут замена базы данных? второе, ну вот есть MVC по сути одной стрелочкой отличается, то что не MV уведомляет V а M точно также уведомляет V о том что есть данные, забери их. В общем тема до конца не раскрыта.
Спасибо большое!
Благодарю за отзыв, очень приятно ☺️🤝
прекрасное объяснение большое спасибо
🤝
Большое спасибо мужик, умеешь объяснить сложные вещи простыми словами
Благодарю за отзыв
Спасибо. Супер видео. С нетерпением жду продолжения. Очень редко где понятным языком и по полочкам раскладывают. Было бы классно параллельно лекции ещё делать пример что бы все это руками потрогать.
Супер! Спасибо за инфу!
Спасибо вам большое за столь подробное и внятное разъяснение. Не было ли у вас в планах сделать видео про различия MVC, MVP, MVVM?
Oochen' dohotchivo obyasnili, spasibo Vam bol'shoe! 👍👍
Спасибо за простоту объяснения!
Годно, уже работал с данным паттерном,создавая приложение "Заметки", с помощью паттерна Repositories, в котором прописывается основная бизнес - логика приложения. Спасибо за твоё видео, освежил память)
Спасибо за инфу !! лучший канал !)
Благодарю за отзыв)
Отлично, просто отлично
Очень понятное объяснение, надеюсь дальше будет также понятно.
Постараюсь)
Супер
Спасибо!
Благодарю вас за отзыв, очень приятно ☺️🤝
Отличное видео все емко и понятно
Доходчиво и понятно 👍
Все прекрасно понятно, спасибо!
лайк за отличное объяснение ненужной библиотеки
Ага тоже лайк 👍
Большое человеческое спасибо 🙂🙂🙂 все чётко и ясно
Молодец Юра, просто молодец, продолжай пожалуйста....
Благодарю за отзыв)
Я так понимаю что ViewModel должен инкапсулировать не модель, а сервисы бизнес-слоя, а моделил тут это доменные модели но тогда должны быть модели уровня View которые данные для отрисовки предаставляют иначе слои "потекут"?
Как уведомить ViewModel о том, что надо сделать изменения в БД?
Спасибо за видео!)
Простое объяснение, спасибо. Единственное чего я бы хотел увидеть - это немного кода для практики, теория это хорошо, но завтра она вылетит из головы, нужно написать, чтобы запомнить.
Спасибо за отзыв, практика будет
Друзья я купил курс у Юрия, если кто-то покупал, подскажите плиз, как долго вы ждали когда вам дадут ссылку на полный курс? Не терпится начать )
Добрый вечер, извините за задержку, скинул вам инструкцию в лс)
ЛУЧШИЙ!
Спасибо большое вам😊
Всё хорошо, только БД это DB )) И ещё в конце ты правильный вопрос задал: зачем это надо? Но потом прям радикально решил вьюхой стучаться в БД. А почему вью не может стучаться в модель? Из всего ролика я понял, что VM это какой-то посредник между вью и моделью и он ничего не делает. Вообще, я на Unity разрабатываю, и решил посмотреть, как же там обычные программисты используют паттерны, чтоб попробовать это в геймдеве. И вот в Unity вью это монобех (по сути отдельный класс, в котором можно и всю логику игры написать), который в принципе может и сам хранить данные для отображения. Поэтому у меня и возник такой вопрос насчет VM. Если в андроиде вью это нечто другое, нечто более легкое, чем монобех в юнити, тогда вопрос отпадает. Поясни, если не сложно)
Привет, смысл всего это то, что есть только односторонняя связь. Vm может только уведомить вью об изменении
Я не совсем поняла, если ViewModel ничего не знает о View, то как именно ViewModel уведомляет View об изменениях в LiveData?
По архитектурам есть курс на Coursera "Архитектура Android-приложений" от МФТИ, там как раз проходятся принципы сначала MVP, а потом MVVM, причём архитектуры внедряются на одно приложение без архитектуры + сначала реализуются свои классы, а потом готовая библиотека (Moxy и Architecture Components)
Чем больше курсов, тем легче понять.
у тебя есть этот курс? можешь записи слить ?
Здравствуйте.У меня возник вопрос.
При таком подходе,когда существуют другие вспомогательные классы, к примеру классы сортировки данных или классы, которые изменяют в зависимости от данных интерфейс экрана ( цвет или размер элементов) нужно также все предоставлять через ViewModel?
ну.. типа, лайк... 🦧
Слишком мало просмотров для такого годного контента.
Хорошая подача материала, интересный контент
Возник вопрос - на реальных проектах действительно такое разграничение ? то есть кто то модель пишет, а кто-то исключительно представление (view)
или там как список задач ? и каждый берёт то что сможет сделать
Благодарю за отзыв, очень приятно ☺️🤝
вообще-то view и viewmodel используют domain сущности, так что хорошо они знают о model
👍
Так легко и просто стало понятно за 6 минут и 50 секунд, что/зачем и почему LiveData :) .... смотрим дальше....
Да, и как читал комменты, все эти VM MV MVVM VVVM MMMVV и .т.д. прошу простить за бред..... как новичок, начинаю понимать MVVM.... смотрим дальше )
Благодарю вас за отзыв, очень приятно ☺️🤝
Приветствую, спасибо за хорошо изложенный материал! У меня вопрос - при MVVM, где реализуется сама бизнес логика приложения? В Model или во ViewVodel? То есть если при каком либо действии пользователя нам не нужно запрашивать данные из БД или из веб сервера, а просто произвести над имеющимися данными какие либо изменения и предоставить пользователю, где размещать логику, которая будет заниматься этими изменениями в VM или в M?
Приветствую, если я вас правильно понял, то данные хранятся в vm, модель содержит все необходимые реализации для работы с репозиторием.
Что за музыка играет на фоне?
Стандартная в редакторе))
Очень интересно. Но если мы из вью обращаемся к бд, а потом меняем бд, то соответственно и логику меняем во вью. Зачем тогда модель?
Бля спасибо брать. Всегда искал такую урок. Благодарю.
Спасибо за урок. Очень хорошая подача материала. Но вот один момент все же остался непонятным. Когда заходит речь о любой разновидности трехслойной архитектуры, то чаще всего в качестве аргумента "зачем" приводят возможную смену СУБД. Но согласитесь, это ведь совсем не жизненный пример. Чаще всего СУБД остается той же весь жизненный цикл приложения. А если она и меняется, то как правило ради каких-то "фишек", которые есть в новой СУБД.И чтобы использовать эти фишки, нужно еще и логику приложения поменять, а не только поменять драйвер БД. Есть более практичные аргументы в пользу такого разделения? Я знаю только один профит - это изолирование бизнес-логики от инструментального окружения, чтобы можно было писать модульные тесты этой логики. И второй вопрос - в чем преимущество MVVM перед той же MVC или MVP? Как понять в каких случаях что лучше использовать?
Спасибо за отзыв. 1. MVVM несет не только пользу в виде замены БД, это просто явный пример, который можно показать. Так же это масштабируемость, тестирование, поддержка кода, чтение кода, минимизация логических ошибок. 2. MVC и MVP хорошие потерны, но устаревшие. Главное преимущество это то, что ViewModel не имеет ссылок на View, а передает состояние STATE. Это решает много проблем. Так же, у Google есть Android Arch. Components которые отлично ложатся на MVVM.
Согласен, замена БД - почти нереальный случай. Во всех этих архитектурах UI-слоя хотят вынести обращение к БД/сети из UI-слоя. Это улучшает поддержку кода, позволяет обращаться одними и теми же методами к модели из разных View. Когда все обращения прописаны во View, становится очень жёстко, приходится одно и то же писать в разных View, а любые изменения в модели ведут к рефакторингу сразу в нескольких View.
Эти архитектуры направлены на борьбу с ЖЦ Андроида. Когда поворот экрана пересоздаёт View, было бы неправильно снова считывать или посылать данные в модель. Поэтому модель становится независимой от ЖЦ, а View продолжает создаваться и исчезать.
ViewModel намного лучше Presenter. Presenter, по сути, не так далеко от View ушёл, его тоже приходится сохранять во время смены конфигурации. Затем снова пробрасывать данные во View. Там есть неконсистентные состояния. Во ViewModel же данные подхватываются во View через Observable.
Обсудить можно в чате в Телеграмм.
t.me/mobile_developing_chat
10:59 в реальности, конечно, поменять бд не получится, хоть с mvvm хоть без него. Так не бывает, и надеяться на это не стоит. Весь код превратится в гавно через полтора года, и все надо будет переписать. Именно так надо проектировать работу, и концентрироваться на текущем моменте и бизнес задачах.
P. S: Урок отличный, спасибо, продолжайте
тоже не правда, вы можете менять поведение какого то модуля, но у вас не будет меняться все приложение, во первых так практически никогда не бывает, во вторых если что-то меняешь, меняешь во всех модулях, т.е. добавил поле, ты его и в модели, и в VM и View везде будешь менять и прокидывать. И да, типа можно было View в базу данных :) ну это слишком прямой путь, почему View не может в Model слой ходить за данными?
👍
Так и не понял в чем разница между контроллером в mvc и ViewModel в mvvn.
😔
Clean Architecture это тоже один из шаблонов как и MVVM?
Ага
Такие схемы показывают в каждом видео по паттернам, но ни в одном из них, к сожалению, не раскрывают главную на мой взгляд тему - роль ViewModel (также как роль Controller в MVC, или Presenter в MVP). Да, все говорят, что "они делают то-то и то-то". Но человеку уже дозревшему до изучения паттернов очень сложно уложить в голове идею, что какой-то класс служит ретранслятором для запросов между двумя другими классами - нафиг это нужно?..)) Понять это можно только увидев код, а код никто не показывает. А нужен-то всего лишь утрированный пример - хоть для приложения с одной кнопкой - и все сложится. Я, например, таких примеров не видел, и потому не могу сказать, что понял эти паттерны.
т.е. на практике viewmodel это какой-нибудь редакс или мобх?
🤷♂️
Идея понятна, только я не до конца понял зачем, чтоб удалить элемент списка, нужно опять обращаться к бд и скачивать тот же список только без одного элемента?! За видео спасибо)
Здравствуйте, что бы сохранить целостность данных.
@@mr.developer тоже не понятно. Разве не правильнее просто отправить уведомление от View на удаление такого-то элемента? Зачем перечитывать? И зачем нужен ViewModel? Почему бы просто из View не общаться с Model? По-моему, какое-то лишнее нагромождение. Ведь по сути он делает то же самое, что и View, только в виртуальном виде у себя в памяти.
View создаёт ViewModel??
Ага
Схема понятна, но роль ViewModel совсем не понятна. Тема не раскрыта. По-моему, этот элемент лишний. Почему бы из View не обращаться напрямую к Model? Зачем городить огород?
Судя по этому вопросу на момент написания комментария вам не знакомы даже принципы ООП, соответвенно заниматься андроидом ещё рановато.
Подписался
все очень просто и что такое вью модель не понятно вообще. класс. это логика на ангуляре ?
и главное зачем вообще эта кенгуру нужна если есть mvc
🤷♂️
ViewModel ничего не знает о View... ViewModel уведомляет View о том, что изменилась LiveData...
прикол в том, что в 99% случаев, базу никто никогда не будет менять))) да, ясно что для огромных проектов это удобно с точки зрения компоновки пакетов, всё в разных файликах, более менее стандартизировано, но для большинства задач - можно просто из вью идти в бд)
Из вью ходить в сеть, это самый большой треш который может быть в приложении. Я бы такого в команде у себя не потерпел.
@@mr.developer я бы к дуболому который боится сделать шаг влево/вправо от стандарта потому что так написано в книжке, никогда бы сама не пошла.
нужно понимать в каких случаях и что актуально. важна целесообразность, Вась. ты бы у меня собеседос скорее всего провалил. ты ж наверно из тех, кто ради одного запроса в сеть будет ставить ретрофит и окхттп, ага? (с мотивацией: "на всякий случай")
), в полемику вступать с вами не буду. Хотите делайте так, это ваше право.
Орнул с BD). Db - database, БД - база данных)
🙈
Закоренелый бэкендщик )))
чет очень на mvc смахивает
+
BD != DB
🙈
Чушь, никакой ясности, в чем суть, зато кружочки квадратики и стрелочки нарисовал
😔
какая нифиг алина аахаха 99% разрабов это мужчины) Бабам проще ногти пойти красить, чем голову напрягать
На самом деле много разрабов и девочек)