A detailed guide on developing Android apps using the Clean Architecture pattern
Dario Miličić
2.5K61

Hi Dario,

I’m considering what if we have to pass Android’s argument(s) from PresenterImpl to Interactor, while Interactor must be POJO?

For eg, as you said, “ If you need simple key-value storage then you can useSharedPreferences”, so for something like AppSettings, I’m using SharedPreferences, with the evolution suggested by Fernando Cejas:

  • In PresenterImpl:
@Override
public void loadSettings(Context context){
this.mSettingsInteractor.execute(new LoadSettingsSubscriber(), context);
}
  • In abstract Interactor:
protected abstract Observable buildInteractorObservable(R params);

public void execute(Subscriber interactorSubcriber, R params){
this.subscription = this.buildInteractorObservable(params)
.subscribeOn(Schedulers.from(threadExecutor))
.observeOn(postExecutionThread.getScheduler())
.subscribe(interactorSubcriber);
}
  • and LoadSettingsInteractor, which implement Interactor for loading SharedPreferences, I override buildInteractorObservable:
@Override
protected Observable buildInteractorObservable(Context context) {
return mSettingsRepository.loadPrefs(context);
  • Then in SettingsRepository of Data layer, I can using SharedPreferences as normal:
private loadPrefs(Context context){
mPrefs = PreferenceManager.getDefaultSharedPreferences(context);
}

as above way, in LoadSettingsInteractor, I have to import and using Android Context, so this class will not be POJO. Could you please help me find out the solution? Best regards.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.