Рефакторинг на архитектуру MVP

[yuhnin-m]

Рефакторинг проекта по паттерну MVP

Произвел рефакторинг и изменение архитектуры на MVP с использованием библиотеки Moxy.

Удалил существующий сервис загрузки контактов

Всю работу по загрузке контактов перенс в репозиторий

Проблемы

Очень долго провозился с проблемой дублирования библиотек Moxy от com.arellomobile и tech.schoolhelper. Перепробовал кучу всего. Нашел только такое решение.

Столкнулся с проблемой, что getViewState() в презенторе возвращает null. Вполне возможно, я что-то забыл добавить, а может быть как раз виновато то, что я сделал для решения конфликта библиотек.

Поискал в инете, у людей тоже была такая проблема

Вопросы

• Скорее всего глупый вопрос: нужно ли в onDestroy уничтожать ссылку на презентер?

• Как предпочтительнее решать ситуацию с тем, что из репозитория из асинхронной функции callback вызывается не в главном потоке:

  • Использовать AsyncTask (но я вроде в лекциях слышал, что он уже устаревает) и вызывать callback в onPostExecute;

  • Использовать такую конструкцию

    getActivity().runOnUiThread(new Runnable() {
        @Override
        public void run() {
            // ...
        }
    });
    

• Использовать Handler

[goblinr]

Столкнулся с проблемой, что getViewState() в презенторе возвращает null

Нужно пользоваться аннотацией @InjectViewState у презентера

Скорее всего глупый вопрос: нужно ли в onDestroy уничтожать ссылку на презентер?

Не нужно. Lifecycle презнтера Moxy - дольше чем lifecycle фрагмента. Поэтому утечек памяти не должно произойти. Но вот обратная ситуация - если у тебя будет жесткая ссылка на фрагмент внутри презентера - это уже гарантированная утечка памяти

Как предпочтительнее решать ситуацию с тем, что из репозитория из асинхронной функции callback вызывается не в главном потоке

На самом деле, ты можешь уже начать использовать RxJava - это будет лучше тех вариантов перечисленных тобою. Но если ты хочешь идти последовательно, то Handler.post в презентере.