Android MVP: безопасное использование контекста в Presenter

Добавлять контекст в Presenter нехорошо, так как Presenter отвечает за бизнес-логику. Чтобы иметь дело с контекстом, вам нужно, чтобы фрагмент/действия использовали обратные вызовы с помощью интерфейсов, которые будут указывать, какие действия должны выполняться действием/фрагментом при работе с представлениями. Фрагмент/действия отвечают за предоставление контекста.

Пример:

interface BaseContract {
        interface BaseView {
            //Methods for View
            void onDoSomething();
        }

        interface BasePresenter {
            void doSomething();

        }
    }

    class BaseMainPresenter implements BaseContract.BasePresenter {
        BaseContract.BaseView view;

        BaseMainPresenter(BaseContract.BaseView view) {
            this.view = view;
        }

        @Override
        public void doSomething() {
            if (view != null)
                view.onDoSomething();
        }
    }

    class DemoClass implements BaseContract.BaseView {

        //Create object of Presenter 

        /****
         * Example :
         * BaseMainPresenter baseMainPresenter = new BaseMainPresenter(this);
         */
        @Override
        public void onDoSomething() {
            //Deal with Context here.
        }
    }

Просто не регистрируйте докладчика в качестве цели обратного вызова для Android (например, BroadcastReceiver, LoaderManager.LoaderCallbacks и т. д.). Обрабатывайте методы обратного вызова в своем представлении (фрагмент или действие) и передайте все связанные данные докладчику.

Если вам нужно Context для создания объекта, пусть ваше представление создаст этот объект (поскольку оно имеет ссылку на Context). В вашем случае вызов

Loader loader = new ArticleCatalogLoader(context, categoryId)

должен быть рефакторинг для

view.createLoaderForCategory(categoryId)

Такой код

Loader loader = new ArticleCatalogLoader(context, categoryId);

приводит к непроверяемому коду. Вы должны избегать создания «бизнес-объектов» в своем коде и позволять кому-то другому делать это за вас (любая структура DI, такая как Кинжал 2 был бы лучшим вариантом, чем обращаться с ним самостоятельно)

Сказав это, ваша проблема - это то, что DI решил давным-давно. Вам нужен свежий новый экземпляр любого объекта? Используйте Provider

Provider — это объект, который «предоставляет» экземпляры объектов. Поэтому вместо того, чтобы иметь

Loader loader = new ArticleCatalogLoader(context, categoryId);

у тебя будет

Loader loader = loaderProvider.get(categoryId);

Итак, единственное, что вам нужно, это что-то вроде этого:

public class ArticleCatalogPresenter ... {
    ...
    private final Provider<Loader> loaderProvider;

    public ArticleCatalogPresenter(Provider<Loader> loaderProvider, ...) {
        this.loaderProvider = loaderProvider;
        ...
    }

    private Loader onCreateArticleCatalogLoader(Bundle args) {    
        int categoryId = args.getInt(CATEGORY_ID);
        Loader loader = loaderProvider.get(categoryId); // no context needed anymore!
        return loader;
    }

}

public class ArticleCatalogPresenter extends BasePresenter
        implements LoaderManager.LoaderCallbacks<Cursor> {

    View view;             
    ...
    private Loader onCreateArticleCatalogLoader(Bundle args) {    
            int categoryId = args.getInt(CATEGORY_ID);
            Loader loader = new ArticleCatalogLoader(context, categoryId); // need Context
            return loader;
    }
}

Итак, вы хотите, чтобы context в вашем Presenter создал новый экземпляр ArticleCatalogLoader. Верно?

Если это так, передайте экземпляр Presenter через конструктор. Итак, в контейнере Activity или DI, когда вы хотите создать объект Presenter, сделайте что-то вроде:

ArticleCatalogPresenter articleCatalogPresenter=new ArticleCatalogPresenter(articleCatalogView,new ArticleCatalogLoader(context,categoryId));

Таким образом, ваш Presenter не будет зависеть от context и его можно будет полностью протестировать.

Что касается вашего беспокойства по поводу утечки памяти, вы можете легко избежать этого, прослушав onStop() в своем View, а затем вызвав соответствующий метод в вашем Presenter, чтобы отменить любой сетевой запрос или context зависимый задача.

Я написал библиотеку MVP, которая очень помогает сэкономить количество шаблонов, необходимых для MVP, а также предотвращение утечек памяти.