AM
Вьюха это же активити, а при перевороте активити уничтожается и пересоздается. Нет?
Size: a a a
2017 February 01
AP
Вьюха это же активити, а при перевороте активити уничтожается и пересоздается. Нет?
Ну мы же делая MVP не тупо пишем в onDestroy - уничтожить презентер.)
S
Есть интерфейс вида:
https://paste.ofcode.org/LhDkPfb2zYdqDa7QXEKSzQ
имплимечу этот интерфейс в классах(и реализую методы по своему ):
RepositoryNetworkImpl , RepositoryDBImpl , RepositoryCacheImpl
А в presenter-е создаю инстанс нужного класса(в зависимости от ситуации):
mRepositoryNetworkImpl = new RepositoryNetworkImpl();
===
я правельно понимаю Repository ?
https://paste.ofcode.org/LhDkPfb2zYdqDa7QXEKSzQ
имплимечу этот интерфейс в классах(и реализую методы по своему ):
RepositoryNetworkImpl , RepositoryDBImpl , RepositoryCacheImpl
А в presenter-е создаю инстанс нужного класса(в зависимости от ситуации):
mRepositoryNetworkImpl = new RepositoryNetworkImpl();
===
я правельно понимаю Repository ?
ES
@pahakorolev
а как Subject помогает решить эту проблему с запросом?
а как Subject помогает решить эту проблему с запросом?
AM
Ну мы же делая MVP не тупо пишем в onDestroy - уничтожить презентер.)
Если через мокси то понятно, а если ваша собственная реализация где живет и уничтожается презентер?
AP
Есть интерфейс вида:
https://paste.ofcode.org/LhDkPfb2zYdqDa7QXEKSzQ
имплимечу этот интерфейс в классах(и реализую методы по своему ):
RepositoryNetworkImpl , RepositoryDBImpl , RepositoryCacheImpl
А в presenter-е создаю инстанс нужного класса(в зависимости от ситуации):
mRepositoryNetworkImpl = new RepositoryNetworkImpl();
===
я правельно понимаю Repository ?
https://paste.ofcode.org/LhDkPfb2zYdqDa7QXEKSzQ
имплимечу этот интерфейс в классах(и реализую методы по своему ):
RepositoryNetworkImpl , RepositoryDBImpl , RepositoryCacheImpl
А в presenter-е создаю инстанс нужного класса(в зависимости от ситуации):
mRepositoryNetworkImpl = new RepositoryNetworkImpl();
===
я правельно понимаю Repository ?
Недавно обсуждали. Нет.
Репозиторий решает откуда загружать данные и загружает их.
Можно загрузку вынести в класссы типа DataSource, которые и будут загружать данные, а репо будет решать откуда.
Репозиторий решает откуда загружать данные и загружает их.
Можно загрузку вынести в класссы типа DataSource, которые и будут загружать данные, а репо будет решать откуда.
AP
Если через мокси то понятно, а если ваша собственная реализация где живет и уничтожается презентер?
Я и не писал свою реализацию, я пытаюсь объяснить людям, которые не используют moxy, что нужно уничтожать презентер только после полного уничтожения вьюхи и тогда отписываться от запроса.
AP
> А отписываться при перевороте - заново запускать запрос.
Именно эта проблема и была решена subject'ами, что бы запросы выполнялись дальше...
Именно эта проблема и была решена subject'ами, что бы запросы выполнялись дальше...
Да, кстати)
Получается, что запросы выполняются всегда, даже если презентер и вьюха были уничтожены.
Получается, что запросы выполняются всегда, даже если презентер и вьюха были уничтожены.
DB
а что делать в случае, когда пользователь загружает видео размером 100мб и уже загрузил 80 мб, и случайно перевернул телефон, то ему придётся всё заного грузить?
Подобного вида запросы в сервис выносят ведь
AD
Подобного вида запросы в сервис выносят ведь
Можно ловить в модели и писать сразу в базу, оттуда как хочешь читай
AP
Можно ловить в модели и писать сразу в базу, оттуда как хочешь читай
Имеется ввиду размер файла. Файлы лучше в сервисах грузить.
AD
А, да, по диагонали читал)
DB
Имеется ввиду размер файла. Файлы лучше в сервисах грузить.
Я правда немного не понял, как в прензетере узнать вьюха пересоздается или окончательно убивается. жизненный цикл то одинаковый)
P
@pahakorolev
а как Subject помогает решить эту проблему с запросом?
а как Subject помогает решить эту проблему с запросом?
Я subject не отписываю от запроса и он проксирует результат для view. Они есть с различным поведением, подробнее в доках http://reactivex.io/documentation/subject.html
Брал пример отсюда https://github.com/grandstaish/hello-mvp-dagger-2
Брал пример отсюда https://github.com/grandstaish/hello-mvp-dagger-2
AP
Я правда немного не понял, как в прензетере узнать вьюха пересоздается или окончательно убивается. жизненный цикл то одинаковый)
Если юзать Moxy, то там есть метод onDestroy().
Если своё, то во вьюхе проверяем, окончательно ли она убивается и посылаем презентеру соответствующий сигнал.
Как правильно проверять, пересоздается ли вью - не знаю.)
Если своё, то во вьюхе проверяем, окончательно ли она убивается и посылаем презентеру соответствующий сигнал.
Как правильно проверять, пересоздается ли вью - не знаю.)
DB
Если юзать Moxy, то там есть метод onDestroy().
Если своё, то во вьюхе проверяем, окончательно ли она убивается и посылаем презентеру соответствующий сигнал.
Как правильно проверять, пересоздается ли вью - не знаю.)
Если своё, то во вьюхе проверяем, окончательно ли она убивается и посылаем презентеру соответствующий сигнал.
Как правильно проверять, пересоздается ли вью - не знаю.)
Видимо надо будет залесть посмотреть в исходники Moxy что там кроется)
AK
@Override
protected void onDestroy() {
super.onDestroy();
if (isFinishing()) {
getMvpDelegate().onDestroy();
}
}
AK
ну приехали
AP
Я subject не отписываю от запроса и он проксирует результат для view. Они есть с различным поведением, подробнее в доках http://reactivex.io/documentation/subject.html
Брал пример отсюда https://github.com/grandstaish/hello-mvp-dagger-2
Брал пример отсюда https://github.com/grandstaish/hello-mvp-dagger-2
Напишу, как делаю я. Может кто поправит.
1. Юзаю Moxy
2. интерактор (или кто угодно) отдает Observable
3. В презентере подписываюсь на этот Observable
4. в onDestroy у презентера отписываюсь от Observable
5. Если нужно завершить запрос, не отписываемся
Таким образом презентер не живет всегда, данные если и хранятся, то удаляются вместе с презентером.
1. Юзаю Moxy
2. интерактор (или кто угодно) отдает Observable
3. В презентере подписываюсь на этот Observable
4. в onDestroy у презентера отписываюсь от Observable
5. Если нужно завершить запрос, не отписываемся
Таким образом презентер не живет всегда, данные если и хранятся, то удаляются вместе с презентером.
AK
/**
* Check to see whether this activity is in the process of finishing,
* either because you called {@link #finish} on it or someone else
* has requested that it finished. This is often used in
* {@link #onPause} to determine whether the activity is simply pausing or
* completely finishing.
*
* @return If the activity is finishing, returns true; else returns false.
*
* @see #finish
*/
* Check to see whether this activity is in the process of finishing,
* either because you called {@link #finish} on it or someone else
* has requested that it finished. This is often used in
* {@link #onPause} to determine whether the activity is simply pausing or
* completely finishing.
*
* @return If the activity is finishing, returns true; else returns false.
*
* @see #finish
*/