本文介绍了如何在没有Dagger的MVP中使用共享首选项,而不会使Presenter与上下文相关?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试实现没有Dagger的MVP(用于学习目的)。但是我遇到了问题 - 我使用Repository模式从缓存(共享首选项)或网络获取原始数据:

I'm trying to implement MVP without Dagger (for learning purposes). But I got to the problem - I use Repository patter to get raw data either from cache (Shared Preferences) or network:

Shared Prefs| 
            |<->Repository<->Model<->Presenter<->View
     Network|

但是要把我的手放在共享首选项上,我必须把它放在像

But to put my hands on Shared Preferences I have to put somewhere line like

presenter = new Presenter(getApplicationContext());

我使用 onRetainCustomNonConfigurationInstance / getLastCustomNonConfigurationInstance 对保持Presenter保留。

I use onRetainCustomNonConfigurationInstance/getLastCustomNonConfigurationInstance pair to keep Presenter "retained".

public class MyActivity extends AppCompatActivity implements MvpView {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        //...
        presenter = (MvpPresenter) getLastCustomNonConfigurationInstance();

        if(null == presenter){
            presenter = new Presenter(getApplicationContext());
        }

        presenter.attachView(this);
    }

    @Override
    public Object onRetainCustomNonConfigurationInstance() {
        return presenter;
    }

    //...
}

那么如何在没有Dagger的MVP中使用共享首选项,而不会使Presenter与上下文相关?

推荐答案

您的演示者不应该位于上下文中。如果您的演示者需要 SharedPreferences ,那么您应该在构造函数传递

如果您的演示者需要一个 Repository ,再次将其放在构造函数中。我非常建议您查看,因为他们在解释为什么你应该使用适当的API。

Your Presenter should not be Context dependent in the first place. If your presenter needs SharedPreferences you should pass them in in the constructor.
If your presenter needs a Repository, again, put that in the constructor. I highly suggest watching Google clean code talks since they do a really good job on explaining why you should use a proper API.

这是适当的依赖关系管理,这将有助于您编写干净,可维护和可测试的代码。
无论你使用匕首,其他一些DI工具,还是自己提供的对象都是无关紧要的。

This is proper dependency management, which will help you write clean, maintainable, and testable code.And whether you use dagger, some other DI tool, or supply the objects yourself is irrelevant.

public class MyActivity extends AppCompatActivity implements MvpView {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        SharedPreferences preferences = // get your preferences
        ApiClient apiClient = // get your network handling object
        Repository repository = new Repository(apiClient, preferences);
        presenter = new Presenter(repository);
    }
}

可以通过使用工厂模式简化此对象创建或者一些DI框架像匕首,但是正如你可以看到的,存储库也不是你的演示者取决于一个上下文。如果您想提供实际的 SharedPreferences ,那么他们的创建将取决于上下文。

This object creation can be simplified by using a factory pattern, or some DI framework like dagger, but as you can see above neither Repository nor your presenter depends on a Context. If you want to supply your actual SharedPreferences only their creation of them will depend on the context.

您的存储库取决于一些api客户端和 SharedPreferences ,您的演示者取决于存储库。只要向他们提供嘲弄对象,这两个类就可以很容易地进行测试。

Your repository depends on some api client and SharedPreferences, your presenter depends on the Repository. Both classes can easily be tested by just supplying mocked objects to them.

没有任何静态代码。没有任何副作用。

Without any static code. Without any side effects.

这篇关于如何在没有Dagger的MVP中使用共享首选项,而不会使Presenter与上下文相关?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-16 17:08