I would not let the presenter call a FeedbackMessage method in the view. The easiest is to let the presenter handle data and pass data on to the view. It is the views’ responsibility to decide what to do with the data from the presenter.

One solution could be to add one more parameter to the LoginValidated method for example LoginValidated(bool successful, string message)
This way you can also pass on the error message from the presenter if any and display this in your view.

I often tend to do simple not null or empty test in the view without calling the presenter with those data.

I hope this answered your question.

I enjoyed reading your post. great read. very clear with regards to MVP implementation.

I need some feedback with regards to the LoginValidated method in the LoginScreen class.

it says

if (loginSuccessful)
{
// Go to next screen…
}else
{
// Display feedback to user…
}

My initial thoughts was to code the following in the else block

MessageBox.Show(“Incorrect login”);

Should I do this? or should i be activating the messagebox from the presenter? I am concern that I am not following the MVP principles. or maybe I should create another method in the ILoginView interface with the following

void FeebbackMessage(string message);

and in my LoginPresenter class, I have the following

public void ValidateLogin(string username, string password)
{
if (username.Equals(“”) || password.Equals(“”))
{
_currentView.FeedbackMessage(“Please enter Username/Password”);
}
else
{
// Validate user name and password
bool loginSuccessful = Login(username, password);

// send response to view
_currentView.LoginValidated(loginSuccessful);
}
}

What should be the best practice here? thanks again for your post.

I have not had to handle different devices and screen sizes, the project are running on rugged devices with a fixed screen size. As I see it the ILoginView is implemented by your Screen and used by your Presenter. So the LoginScreen and the WideScreenLoginScreen will implement the same ILoginView and use the same Presenter. The functionality and data are similar for your two screens, only the layout differs. The layout should be handled in your Screen and not in the view or the presenter.

If you have several similar Views then I think you should use inheritance were you find that natural. As in all other patterns you do not want to duplicate your code. I also often create one or several “super” screens containing buttons, headers and common functionality and then all other screens in my project inherit from these.

Also, if you had a few similar views like IEmployeeView, IEmployerView, IContractorView… would you create an IPersonView from which the former views inherited? Just curious.

I will for sure consider using this framework in my pet project.
Thanx