Best practice for package structure in an MVP project

Viewed 9541

I have an Android Studio project that is using an MVP architecture. What is the advised packages structure for a project this style we can do:

app:
  screen_name
    activityA
    presenterA
    interfaceA

or:
   activities
     activityA
     activityB
   preentors
     presentorA
     presentorB
etc
3 Answers

Your problem is just only UI part of MVP architectural pattern. Which is View classes along with their corresponding Presenters. And the better solution is the first approach.

enter image description here

App should have package according to features, NOT by the common functionality. We should group together the classes which are getting changed/modify together.

Some developers group source code by layer - like the second approach - because they want to keep the same package structure for ALL the projects they work on. But that is bad decision because it's always HARD to find classes when they are grouped only because they share same parent classes!

Ex: For activities, some developers put them in activity package because all activities extends Activity class. It makes sense because this is activity-ONLY package, BUT it is hard to go through those packages.

For more information, see: android-mvp-architecture and this S.O answer

MVP is good choice. You can follow following pattern:

app: 1. activities: + interface to represent view (i.e activity) + actual activity java class 2. Presenter: + interface to represents presenter + java class to represent presenter implementation 3. Model: + interface to represents model + java class to represent model implementation (do network calls here, pass callback to presenter which then gives data to activity)

Related