SG
Давайте я создам вьюху которая будет лезть в сеть, уметь читать бд
Size: a a a
2020 June 26
SG
И выкину ее на гит. И добавлю в проект
АЕ
ну и классно, в чём проблема?
SG
ну и классно, в чём проблема?
Ни в чем, она же вью, добавил ее в хмл и используй
SG
И не надо мвп
AD
Давайте я создам вьюху которая будет лезть в сеть, уметь читать бд
давайте) если она будет очень полезной (например, Google Maps, Yandex MapKit, MapBox), то я буду ее использовать
D
Даёшь ViewFramework ! ))))
AD
И не надо мвп
может, там внутри свой MVP используется, какие в этом проблемы?)
ЕХ
эх такой батл пропустил )
ЕХ
И не надо мвп
скажу от себя
многие могут не согласиться
единственное для чего нужен MVP - это для того чтобы сделать андроид приложение тестируемым (на хостовой машине unit тестами)
всё остальное идет бонусами
если у вас есть возможность тестировать андроид приложение по другому это очень хорошо и вам не нужен MVP
если у вас нет необходимости тестировать с кем не бывает и вам опять же не нужен MVP
многие могут не согласиться
единственное для чего нужен MVP - это для того чтобы сделать андроид приложение тестируемым (на хостовой машине unit тестами)
всё остальное идет бонусами
если у вас есть возможность тестировать андроид приложение по другому это очень хорошо и вам не нужен MVP
если у вас нет необходимости тестировать с кем не бывает и вам опять же не нужен MVP
AD
скажу от себя
многие могут не согласиться
единственное для чего нужен MVP - это для того чтобы сделать андроид приложение тестируемым (на хостовой машине unit тестами)
всё остальное идет бонусами
если у вас есть возможность тестировать андроид приложение по другому это очень хорошо и вам не нужен MVP
если у вас нет необходимости тестировать с кем не бывает и вам опять же не нужен MVP
многие могут не согласиться
единственное для чего нужен MVP - это для того чтобы сделать андроид приложение тестируемым (на хостовой машине unit тестами)
всё остальное идет бонусами
если у вас есть возможность тестировать андроид приложение по другому это очень хорошо и вам не нужен MVP
если у вас нет необходимости тестировать с кем не бывает и вам опять же не нужен MVP
как и любая другая MV-архитектура)
АЕ
Если обобщить, то если нет тестов, то всё приложение можно писать в одном классе. Очевидно, это не так, и тесты не единственная цель.
ЕХ
Если обобщить, то если нет тестов, то всё приложение можно писать в одном классе. Очевидно, это не так, и тесты не единственная цель.
можно примеры зачем ещё нужен MVP?
АЕ
Код становится более поддерживаемым и простым. Обычно MV* привносит свои новые фичи, как мокси и вьюмодели: упрощение ЖЦ экрана, восстановление стейта при смене конфигурации. Отделение логики реализации отображения UI от логики его поведения даёт больше гибкости.
ЕХ
Код становится более поддерживаемым и простым. Обычно MV* привносит свои новые фичи, как мокси и вьюмодели: упрощение ЖЦ экрана, восстановление стейта при смене конфигурации. Отделение логики реализации отображения UI от логики его поведения даёт больше гибкости.
> Код становится более поддерживаемым и простым.
был 1 класс стало 3, общее количество функций увеличивается в разы, а еще эти классы надо правильно связать между собой не понял где тут простота
> упрощение ЖЦ экрана
не относится к MVP
> восстановление стейта при смене конфигурации
не относится к MVP
> Отделение логики реализации отображения UI от логики его поведения даёт больше гибкости
в чем гибкость?
был 1 класс стало 3, общее количество функций увеличивается в разы, а еще эти классы надо правильно связать между собой не понял где тут простота
> упрощение ЖЦ экрана
не относится к MVP
> восстановление стейта при смене конфигурации
не относится к MVP
> Отделение логики реализации отображения UI от логики его поведения даёт больше гибкости
в чем гибкость?
AD
> Код становится более поддерживаемым и простым.
был 1 класс стало 3, общее количество функций увеличивается в разы, а еще эти классы надо правильно связать между собой не понял где тут простота
> упрощение ЖЦ экрана
не относится к MVP
> восстановление стейта при смене конфигурации
не относится к MVP
> Отделение логики реализации отображения UI от логики его поведения даёт больше гибкости
в чем гибкость?
был 1 класс стало 3, общее количество функций увеличивается в разы, а еще эти классы надо правильно связать между собой не понял где тут простота
> упрощение ЖЦ экрана
не относится к MVP
> восстановление стейта при смене конфигурации
не относится к MVP
> Отделение логики реализации отображения UI от логики его поведения даёт больше гибкости
в чем гибкость?
> в чем гибкость?
в том, что можно менять визуальную часть, не меняя логики. например, в моем MVP будет view.showFailureState(Throwable) и нам не важно, как это обработается на View. наверное, называть это «гибксотью» не верно, но я это так вижу
то же касается всяких покажи/спрячь индикатор загрузки - как он будет прятаться/показываться - нам вообще пофиг
в том, что можно менять визуальную часть, не меняя логики. например, в моем MVP будет view.showFailureState(Throwable) и нам не важно, как это обработается на View. наверное, называть это «гибксотью» не верно, но я это так вижу
то же касается всяких покажи/спрячь индикатор загрузки - как он будет прятаться/показываться - нам вообще пофиг
ЕХ
> в чем гибкость?
в том, что можно менять визуальную часть, не меняя логики. например, в моем MVP будет view.showFailureState(Throwable) и нам не важно, как это обработается на View. наверное, называть это «гибксотью» не верно, но я это так вижу
то же касается всяких покажи/спрячь индикатор загрузки - как он будет прятаться/показываться - нам вообще пофиг
в том, что можно менять визуальную часть, не меняя логики. например, в моем MVP будет view.showFailureState(Throwable) и нам не важно, как это обработается на View. наверное, называть это «гибксотью» не верно, но я это так вижу
то же касается всяких покажи/спрячь индикатор загрузки - как он будет прятаться/показываться - нам вообще пофиг
ну и причем тут MVP?
кто мешает сделать это во фрагменте/активити
вынести в одну функцию логику в другую отображение )
только они будут в одном классе а в MVP в 2-х классах
не понял как MVP тут помогает
кто мешает сделать это во фрагменте/активити
вынести в одну функцию логику в другую отображение )
только они будут в одном классе а в MVP в 2-х классах
не понял как MVP тут помогает
AD
ну и причем тут MVP?
кто мешает сделать это во фрагменте/активити
вынести в одну функцию логику в другую отображение )
только они будут в одном классе а в MVP в 2-х классах
не понял как MVP тут помогает
кто мешает сделать это во фрагменте/активити
вынести в одну функцию логику в другую отображение )
только они будут в одном классе а в MVP в 2-х классах
не понял как MVP тут помогает
какая-то полемика уже) действительно, этому не только MVP способствует, но и любой MV-паттерн
помогает тем, что (как же это банально) соблюдается хоть какое-то SRP и читаеющий точно представляет, в каком месте искать тот или иной код)
думаю, нет смысла продолжать - формулировки слишком скользкие, код действительно можно писать в одном файле и это будет ок 👌 (без сарказма)
помогает тем, что (как же это банально) соблюдается хоть какое-то SRP и читаеющий точно представляет, в каком месте искать тот или иной код)
думаю, нет смысла продолжать - формулировки слишком скользкие, код действительно можно писать в одном файле и это будет ок 👌 (без сарказма)
ЕХ
какая-то полемика уже) действительно, этому не только MVP способствует, но и любой MV-паттерн
помогает тем, что (как же это банально) соблюдается хоть какое-то SRP и читаеющий точно представляет, в каком месте искать тот или иной код)
думаю, нет смысла продолжать - формулировки слишком скользкие, код действительно можно писать в одном файле и это будет ок 👌 (без сарказма)
помогает тем, что (как же это банально) соблюдается хоть какое-то SRP и читаеющий точно представляет, в каком месте искать тот или иной код)
думаю, нет смысла продолжать - формулировки слишком скользкие, код действительно можно писать в одном файле и это будет ок 👌 (без сарказма)
ну вот (
еще никто не рассказал мне хоть один плюс использования MVP кроме как возможность тестировать
что же на самом деле дает MVP:
точка вхождения становится выше
код становится сложней, его тяжелей поддерживать так как разбит по разным файлам
читабельность кода ухудшается так как разбит по разным файлам
количество файлов вырастает
количество функций умножается
количество строк кода вырастает
еще никто не рассказал мне хоть один плюс использования MVP кроме как возможность тестировать
что же на самом деле дает MVP:
точка вхождения становится выше
код становится сложней, его тяжелей поддерживать так как разбит по разным файлам
читабельность кода ухудшается так как разбит по разным файлам
количество файлов вырастает
количество функций умножается
количество строк кода вырастает
AD
ну вот (
еще никто не рассказал мне хоть один плюс использования MVP кроме как возможность тестировать
что же на самом деле дает MVP:
точка вхождения становится выше
код становится сложней, его тяжелей поддерживать так как разбит по разным файлам
читабельность кода ухудшается так как разбит по разным файлам
количество файлов вырастает
количество функций умножается
количество строк кода вырастает
еще никто не рассказал мне хоть один плюс использования MVP кроме как возможность тестировать
что же на самом деле дает MVP:
точка вхождения становится выше
код становится сложней, его тяжелей поддерживать так как разбит по разным файлам
читабельность кода ухудшается так как разбит по разным файлам
количество файлов вырастает
количество функций умножается
количество строк кода вырастает
> еще никто не рассказал мне хоть один плюс использования
это очень удобная позиция, когда умышленно игнорируешь аргументы оппонента
это очень удобная позиция, когда умышленно игнорируешь аргументы оппонента