Телеграмм чат группы android

Как я понял стандартного подхода нету чисто на мвп?

Я думаю им сперва стандартный MVVM до ума довести надо без костылей, прежде чем для MVP создать пакет.

22:05пожаловаться #1

V

Переслано от Vitaly Peryatin

Можно просто использовать PresenterStorage в виде object класса
В onCreate у Fragment/Activity генерировать viewId в виде UUID, если в Buтdle его не получается найти
Профит

22:05пожаловаться #2

V

В другом чатике написали

22:05пожаловаться #3

V

Хз норм подход или нет

22:05пожаловаться #4

SS

Suyun S in Android KZ

А вызывать должен из onStop view, это если хочешь без применения ViewModel и других либ

22:05пожаловаться #5

BG

Переслано от Vitaly Peryatin

Можно просто использовать PresenterStorage в виде object класса
В onCreate у Fragment/Activity генерировать viewId в виде UUID, если в Buтdle его не получается найти
Профит

Тогда уж лучше от ViewModel наследоваться.

22:05пожаловаться #6

BG

Из всех костылей, наследование от ViewModel не влечет за собой шума и нежданных последствий.

22:06пожаловаться #7

BG

С классическим презентором, который интерфейс юзает

А в чем проблема от ViewModel наследоваться?

22:07пожаловаться #8

VT

Vladimir Tokarev in Android KZ

Как лучше сохранить Presenter в MVP? Чтобы он переживал поворот. Например если в презентере долгая задача, чтобы при повороте мы её не потеряли

А что за долгая операция в презентере? Если это работа с данными то может есть смысл завести observable репозиторий как синглтон? И пусть презентер на него подписывается отписывается.

22:08пожаловаться #9

V

Я просто щас изучаю mv* и подумал если в презентере будет загрузка чего-то из сети, а в это время поворот произойдет куда данные вернутся

22:10пожаловаться #10

V

Я просто щас изучаю mv* и подумал если в презентере будет загрузка чего-то из сети, а в это время поворот произойдет куда данные вернутся

Ну не в самом презентаре, а через презентер в модели

22:10пожаловаться #11

IQ

Я просто щас изучаю mv* и подумал если в презентере будет загрузка чего-то из сети, а в это время поворот произойдет куда данные вернутся

Меня больше интересует когда это г**вно гугл починит.. уже 10 лет это позор с поворотом висит

22:28пожаловаться #12

IQ

Ну и куча других проблем в ос..

22:29пожаловаться #13

BG

Isaya Qerey

Меня больше интересует когда это г**вно гугл починит.. уже 10 лет это позор с поворотом висит

Прикольно, что на собесах спрашивают про каждый костыль к этой дыре, и нужно рассказать самый безболезненный и лаконичный костыль.

22:41пожаловаться #14

BG

И разработчик обязан знать решение ввиде именно костылей, так как безкостыльное решение попросту пока не существует. Уже столько лет о проблеме знают, но каждый раз такой вопрос приводит к бурным обсуждениям.

22:44пожаловаться #15

BG

Но если посмотреть с другой стороны, то такие дыры стимулируют быть гибкими в разработке и держать себя в тонусе.

22:52пожаловаться #16

IQ

Bauyrzhan Galmzhansson

Прикольно, что на собесах спрашивают про каждый костыль к этой дыре, и нужно рассказать самый безболезненный и лаконичный костыль.

Жирно плюсую))

22:52пожаловаться #17

IQ

То есть разрабы насколько привыкли к огромнлй куче костылей что с умным видом спрашивают про них на собеседовании или рассказывают. И это не только с поворотами экранов

22:53пожаловаться #18

BG

Isaya Qerey

То есть разрабы насколько привыкли к огромнлй куче костылей что с умным видом спрашивают про них на собеседовании или рассказывают. И это не только с поворотами экранов

Так или иначе эти преграды нужно преодолевать. Они существуют и с этим нужно работать.

Я замечаю, как разрабы скептично относятся к нововведениям от Гугла и стараются быть более самостоятельными.

22:55пожаловаться #19

IQ

Проблема в том что большинство нововведения гугла это как раз таки латание старых дыр.. каких то серьёзных шагов в перед я не вижу. Я сейчас говорю про развитие самого android sdk