RC
собственно там в статье так и сказано и вот эта ссылка дана
Size: a a a
2016 November 22
RC
вообще боб прикольный мужик в любом случае, видео достойно просмотра =)
2016 November 23
G
К okhttp можно кеш ответов приделать и база не нужна.
Презентеру чтоб вьюха выдавала свое состояние в бандлах - странно
Презентеру чтоб вьюха выдавала свое состояние в бандлах - странно
RC
К okhttp можно кеш ответов приделать и база не нужна.
Презентеру чтоб вьюха выдавала свое состояние в бандлах - странно
Презентеру чтоб вьюха выдавала свое состояние в бандлах - странно
что за кеш ответов? in-memory?
G
Http cache
G
В файлах
RC
К okhttp можно кеш ответов приделать и база не нужна.
Презентеру чтоб вьюха выдавала свое состояние в бандлах - странно
Презентеру чтоб вьюха выдавала свое состояние в бандлах - странно
если это так коробит, никто не мешает сделать отдельный бандл для презентера и положить его внутрь основного бандла. тогда презентер не получит ничего кроме своей инфы
RC
В файлах
ну в некоторых случаях мб и вариант. но базу это не заменяет
AB
В MVP для Android есть два подхода по хранению стейта view:
1) Вы храните стейт Android-ными механизмами (Bundle, RetainInstance..)
2) Стейт хранится в презентере/моделе
Оба из них по-своему хороши. Moxy использует второй.
1) Вы храните стейт Android-ными механизмами (Bundle, RetainInstance..)
2) Стейт хранится в презентере/моделе
Оба из них по-своему хороши. Moxy использует второй.
AB
Http cache отличный механизм. Круто, если он решает вашу задачу персистентности данных. Для более широкого круга задач его может быть недостаточно
А
Как я понял, классы InAppPurchases относятся к presentation слою в viper?
RC
В MVP для Android есть два подхода по хранению стейта view:
1) Вы храните стейт Android-ными механизмами (Bundle, RetainInstance..)
2) Стейт хранится в презентере/моделе
Оба из них по-своему хороши. Moxy использует второй.
1) Вы храните стейт Android-ными механизмами (Bundle, RetainInstance..)
2) Стейт хранится в презентере/моделе
Оба из них по-своему хороши. Moxy использует второй.
мне кажется, что эти подходы не полностью взаимоисключают друг друга. первый способ покрывает немного отличное множество кейзов. например он позволяет стейту выживать при убийстве приложения системой. но ведь ничего не мешает для этого кейза использовать сочетание 1 и 2, сохраняя стейт хранимый в презентере в бандл
AP
ребят, а moxy спасет меня от известной наболевшей проблемы с коммитом фрагмента: java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState ?
AP
ну, я как понимаю, если я делаю коммит фрагмента в onActivityResult, т.е. через viewstate отправляю команду в onActivityResult, то ведь эта команда будет применена на вьюху не ранее onResume или onStart ?
YS
На половину. Нужно только делать commitAllowStateLoss, а при применении команды смотреть: если такого фрагмента нет, то значит state loss при предыдущем коммите и нужно commit опять. Только тогда надо делать так, чтобы команда сохранялась в очередь команд
AP
onActivityResult(....){
getViewState().changeFragment(); // применится не ранее onResume или даже onStart ?
}
getViewState().changeFragment(); // применится не ранее onResume или даже onStart ?
}
AP
разве не ?
YS
Ну в вашем случае да. А вот если вы делаете changeFragment в результате выполнения асинхронного запроса, то не факт 😉
YS
А, я в вопросе не заметил про onActivityCreate. Ну, я бы не рассчитывал на него и что он вызывается точно перед onSaveInstanceState