Дима
Друзья, зачем нужен Moxy, только для сохранения состояния? Но для этого же есть ViewModel
Дима
В MVP ?
Moxy это MVP, но и самому это Mvp легко написать, основной посыл этой библиотеки такой, что сохранять состояние при повороте чере ViewState
Spadar
Да я знаю что это, работал. Но зачем тебе Moxy в MVVM ?
Spadar
Или так: зачем тебе ViewModel в MVP ?
max
Или так: зачем тебе ViewModel в MVP ?
Ну если взять не за тот хвост viewmodel, то можно использовать её вместо презентера.
Spadar
Это уже будет не аналог presenter из MVP )
Spadar
Да и хранить ссылку на view в viewmodel, которая может пережить эту самую view...
Vitaly
Друзья, зачем нужен Moxy, только для сохранения состояния? Но для этого же есть ViewModel
Нет, это немножко разный подход В MVP Presenter знает о View и сам уведомляет View о каких-то действиях, а View знает о Presenter В MVVM ViewModel не знает о View, а просто устанавливает значения в свои поля, а View подписывается на изменения во ViewModel (только View знает о ViewModel) В чистом MVP и MVVM нет сохранения состояний, но Android требует это сохранение Так сложилось, что для MVP нет устоявшейся методологии как Presenter сохраняет состояние, поэтму придумали Moxy, Mosby или свой вариант сохранения состояния, то есть это всее лишь надстрйка над Presenter ViewModel тоже надо сохранять, но мы можем написать как свой ViewModel с нуля и думать над сохранением состояния, так и расшириться от гугловского ViewModel, который просто за нас реализовал логику сохранения состояния
Granderbird
То, что ты прямо не высказал её, не значит, что она не читается между строк. Ладно, забей уже
Granderbird
Да
Granderbird
Правильно
Granderbird
Всё что ты говоришь) Ты молодец, взрослый, опытный мальчик)
Spadar
Какой-то срач начался...с переходом на личности...
Granderbird
Ух бля, улица воспитает, у тебя молодостьв 90х прошла, дай угадаю?
Granderbird
Если дальше срачь разводить хочешь, то пиши уже в лс, а то забанят тут ещё, лол
Granderbird
Я и так постарался максимально тупо тебе отвечать, что бы не выводить на дальнейший разговор, но ты продолжаешь писать ¯\_(ツ)_/¯
Spadar
Взрослый человек, а ведешься на провокации )
Дима
Нет, это немножко разный подход В MVP Presenter знает о View и сам уведомляет View о каких-то действиях, а View знает о Presenter В MVVM ViewModel не знает о View, а просто устанавливает значения в свои поля, а View подписывается на изменения во ViewModel (только View знает о ViewModel) В чистом MVP и MVVM нет сохранения состояний, но Android требует это сохранение Так сложилось, что для MVP нет устоявшейся методологии как Presenter сохраняет состояние, поэтму придумали Moxy, Mosby или свой вариант сохранения состояния, то есть это всее лишь надстрйка над Presenter ViewModel тоже надо сохранять, но мы можем написать как свой ViewModel с нуля и думать над сохранением состояния, так и расшириться от гугловского ViewModel, который просто за нас реализовал логику сохранения состояния
Если подитожить, вообщем то понятно, а смысл использовать Moxy, если есть гугловский родной сохранитель состояния?
Spadar
Если подитожить, вообщем то понятно, а смысл использовать Moxy, если есть гугловский родной сохранитель состояния?
Потому что раньше был популярен MVP. Сегодня реалии таковы, что новые проекты строят с MVVM, MVI и т.д.
Vitaly
Если подитожить, вообщем то понятно, а смысл использовать Moxy, если есть гугловский родной сохранитель состояния?
В подходе Кому-то нравится MVP, а кому-то MVVM Кому-то нравится уведомляться View, а кому-то нравится подписываться на изменения
Spadar
MVP исчерпал себя в Android...
Vitaly
MVP исчерпал себя в Android...
Но реалии таковы, что многие старые разработчики (с опытом 5+ лет) продолжают строить проекты на MVP
Евгений
MVP исчерпал себя в Android...
добрый день! а какой пример архитектуры Вы бы посоветовали для приложения на текущий день? для банковского например.
Spadar
Но старые переписывать с MVP на что-то другое долго и очень затратно. Вот для тех, кто на поддержке таких проектов и актуален MVP
Дима
Спасибо ребятки, без лишних понтов, все по чесноку, решил узнать что такое Moxy и почему его на вакансиях ставят в "список знаний"
Евгений
ну я глубже имею в виду, с примером)
Евгений
использовать например dagger injection
Евгений
и прочие тонкости, которые сэкономят нервы
Vitaly
использовать например dagger injection
В MVVM это можно делать через ViewModel Factory, а дабы неписать ViewModel Factory отдельно для каждой ViewModel в интернете есть Kotlin Extension для этого
Spadar
нужно переписать старый, написаный невесть на чем)
до MVP писали на самом модном "всё в активити"
Евгений
не, тут глючный фрагмент контроллер
Евгений
хотя да, все фрагменты в god обжекте) в одном единственном активити
Vitaly
Ты про SingleActivity?
Нет, он про God Activity
Spadar
Ты про SingleActivity?
нет, я про псевдо MVC
Granderbird
Нет, он про God Activity
Даже не слышал о таком, лол
Евгений
просто хотелось бы услышать совет опытныго человека) какие реалии заложить в проект, чтобы в дальнейшем это было выгодно @qmanqman
Spadar
Даже не слышал о таком, лол
это и есть "всё в активити", никакого разделения, если простым языком
Spadar
У тебя вью (контроллер) отвечал за всё
Granderbird
У тебя вью (контроллер) отвечал за всё
А, лол, писал так, когда только начинал изучать андройд, дошло
Стас 🍕🍕🍕
а у MVI фишка в чем?
Евгений
но основы есть же)
Стас 🍕🍕🍕
и где вообще можно посмотреть семплы
Spadar
Каждый сам выбирает, я прикипел к MVVM + Clean
Granderbird
а у MVI фишка в чем?
Если не ошибаюсь, то всё на состояниях работает и в зависимости от состояния что то происходит. Ну и одновременно 2 состояния не могут быть, что облегчает поиск ошибок и тестирования. Но я мог спиздеть, ибо читал года полтара назад, прежде чем верить на слово, послушай что другие скажут
Spadar
Да, писанины много
Spadar
Но в долгосрочной поддержке очень выручает. На любое изменение не приходиться приседать
Spadar
А в MVP писанины тоже было не меньше, а это, на минуточку, всего лишь часть архитектуры проекта (его представление), но не весь проект
Vitaly
Всё очень четко расписано по слоям и в каждом слое достаточно много кода получается на самом деле в долгосрочной поддержке При расширении код остаётся столь же понятен каждому разработчику
Spadar
Clean уже тоже изживает себя...
Spadar
У Badoo есть очень интересный доклад про их архитектуру
Spadar
Я вот полностью слез с Dagger и перешел на Koin. Не аукнется ли оно мне потом...
Spadar
Сейчас гугл добавили тесную интеграцию Dagger в Android Studio
Стас 🍕🍕🍕
Spadar
Ого, не знал)
Посмотри в чендже, кажется в Canary. Забыл уже. Думаю через 6-12 месяцев, а то и раньше, доберется до стабильных версий
Spadar
А в чем проблема?
Пальцы стираются, много бойлера
Spadar
Хотя, там и бойлер-то, не совсем и бойлер, просто иначе обратную зависимость не реализовать... Да и без мапперов тоже никак
Spadar
Вот и я о "рояле"... Но мне пока очень нравится отсутствие кодогенерации и быстрая сборка
Spadar
Я просто еще к databinding прикипел... Две тяжелых кодогенерации на проект это дюже много...
Spadar
Я до сих пор не понимаю почему сами же владельцы Dagger (Google) до сих пор не реализовали подобной обертки фабрики для ViewModel....
Spadar
Смотрел я ktor client, я пока не готов)
Spadar
Как бэк я с Ktor уже работал, даже провел нагрузочное тестирование, ddos-ил его как положено
Spadar
Он отлично держит нагрузку. Мне понравился.
Spadar
Бесконечно 1000 одновременных параллельных запросов от "пользователей", при каждом запросе было обращение к бд, выборка, и возврат результата. Через 20 минут макс продолжительность обработки одного запроса увеличилась до 8 секунд и больше не росло. Колебалось от 2 до 8.
Spadar
Но это так, детский тест был, Ktor (Netty) работал на 4-х потоках
Spadar
в hilt реализовали поддержку вм, будут генериться фабрики вроде или чет такое
Незнаю, не слышал. DaggerActivity, DaggerFragment, но до ViewModel так пока и не дошло дело...
Flogiston
как управлять wi-fi сетями на устройстве, если у меня есть device owner?
F
посоветуйте инфы для вката в андроид с другого языка? заранее спс :3
Mike
посоветуйте инфы для вката в андроид с другого языка? заранее спс :3
с «другого языка» вкатываться нужно в джаву или котлин