I have a Presenter ( RoomPresenter) and a Model ( RoomModel). My RoomModel have some methods like:void createRoom(RoomData roomData, List<User> users)void addUsersToRoom(int roomId, List<User> users)void joinRoom(int roomId)This is the createRoom() implementation:void createRoom(RoomData roomData, List<User> users) {    addUsersToRoom(roomData.getId(),users);    joinRoom(roomData.getId());}So, when the user wants to create a room, ( abstracting the View -> Presenter methods call) the presenter will call  the createRoom() method of the RoomModel.My question is: Would be a good practice make the presenter, and not the model,implement the createRoom method? (i.e. the presenter will have the createRoom() and the model will have just the addUsersToRoom() and joinRoom() methods). Because in that way, I'll be able to call some View methods (e.g. show  a toast or a loading status) before or after calling the addUsersToRoom() and joinRoom() methods.
In the MVP pattern, the Presenter must control the call flow of Model methods?
architecture;mvp
The method could be part of the presenter, it could stay in the model, or it could be moved to a separate helper or controller class. None of these placements is always better or best practice. Which to choose depends on factors like how complex is that operation, does it only make sense in conjunction with those view/presenter operations, do you want it to be unit testable, or how do you organize responsibilities between the layers in your program? For example, the method could look like this: void createRoom(RoomData roomData, List<User> users)  {     sendEventBeforeCreateRoom();     addUsersToRoom(roomData.getId(),users);     sendEventUsersAdded();     joinRoom(roomData.getId());     sendEventRoomCreated(); }The catch here is what those sendEvent methods are:If the method is in the model, you need them to be event firing methods, and so you need an event mechanism in your model layer. If you do not want the latter, or if the method in reality is so complex it justifies a class of its own, you could put it into separate controller, and classes like the presenter have to subscribe to those events first. This makes the code more complex, but the benefit is you can now test it easier in isolation.If you place the method in the presenter, the sendEvent methods could be replaced by direct calls to corresponding methods of the  presenter. That is the simplest approach, but it gives you less flexibility for testing or reusing the method in a different contextSo pick your choice on what kind of flexibility you need (but do not add any flexibility just in case). If it turns out you do not really need that sendEvent methods, keeping the method in the model would have been probably the most simple and therefore best choice.