Is this package structure correct?

[Muddz]

In my attempt to understand MVP I have structured the classes in their own package, where each packaged is named as: model, view, presentor, in respect to the classes role. Is it correctly done?

[Muddz]

What about if you have som cloud storage/networking for Amazon S3 and EC2 or Google App engine/FIrebase. Where should the classes for these operations be?

[antoniolg]

Nothing is black or white in software development. So your packages are good, but you'll probably find issues in a big App. But you can refactor during the process, so I wouldn't worry too much about it.

The thing is that interactors can be easily reused, so you'll probably want to have them in a separate package (or even module).

The second question you ask is closely related to the first one. As those are components that will be reused (for instance) by many interactors, they are a separate entity, so should live in a separate package.

You could have something like this:

• interactors
  • LoginInteractor.java
• model
  • AmazonClient.java
  • FirebaseClient.java
• ui
  • login
    • LoginView.java
    • LoginActivity.java
    • LoginPresenter.java
  • home
  • detail

The experience has taught me since I wrote this code almost 4 years ago (and you'll probably feel the same at some point) that the interfaces for presenters and interactors are not of much use, so you can get rid of them.

This is one of the many possibilites, it's more a matter of taste that something written into stone. So try different things and extract your own conclusions.

[erikswed]

Thanks for grate work
Can you clarify what you mean by "interfaces for presenters and interactors are not of much use, so you can get rid of them."

As I understand in your androidmvp code, every view have a presenter that has a view interface to dispatch messages back to that view, and same for interactors that has the presenter interface to dispatch messages back up to presenter

[antoniolg]

Yup, it's the other way round. You don't need a presenter interface, something like:

interface MainPresenter

class MainPresenterImpl : MainPresenter

Because you will usually only have one implementation of the presenter, so it's redundant. As there's no dependency inversion here (I'll talk about this in an article soon), it's extra work without much benefit.

[erikswed]

Thanks I stil have much to learn thanks for the lessen.
I see in the MainActivity the private MainPresenter presenter; interface that you say is not needed, is used to hide implementation details in the MainPresenterImpl.
I though that was a good thing!

Do you mean I should look at the MainPresenterImpl like it was larger Singleton ok i understand maybe.
Must learn more on the dependency inversion SOLID

In your androidmvp code it looks really ok with the interfaces but it´s just a small small demo and the interfaces makes sense there, ok get it thanks for the lesson

[antoniolg]

In a large App, you would see that you create interfaces that are not used for anything else in this case. If you could have several presenters implementing the same interface, that would be useful. But normally not the case.

In any case, using them won't hurt either, and can have some benefits for testing purposes.