Model-View-Presenter passive view: bootstraping - who displays the view initially?

Question

In the Passive View Model View Presenter pattern, who has the responsibility for displaying the view? I have found related answers for other MVP versions, but they don\'t se

Answer 1

Option (3) all the way. It is the presenter's jobs for "controlling" the view, which includes making it visible. Yes, you'll need to add to the view's interface to allow this to happen, but that's not a big deal. Remember, you can make the view is as passive as possible. No logic whatsoever!

Working Example:

I stumbled upon this example of a simple Swing game using an MVC architecture. Since I write my Swing apps using MVP instead of MVC, I can't say with authority if this example is a true and pure example of MVC. It looks okay to me, and the author trashgod has more than proven himself here on SO using Swing, so I'll accept it as reasonable.

As an exercise, I decided to rewrite it using an MVP architecture.

---

The Driver:

As you can see in the code below, this is pretty simple. What should jump out at you are the separation of concerns (by inspecting the constructors):

• The Model class is standalone and has no knowledge of Views or Presenters.

• The View interface is implemented by a standalone GUI class, neither of which have any knowledge of Models or Presenters.

• The Presenter class knows about both Models and Views.

Code:

import java.awt.*;

/**
 * MVP version of https://stackoverflow.com/q/3066590/230513
 */
public class MVPGame implements Runnable
{
  public static void main(String[] args)
  {
    EventQueue.invokeLater(new MVPGame());
  }

  @Override
  public void run()
  {
    Model model = new Model();
    View view = new Gui();
    Presenter presenter = new Presenter(model, view);
    presenter.start();
  }
}

and the GamePiece that we'll be using for the game:

import java.awt.*;

public enum GamePiece
{
  Red(Color.red), Green(Color.green), Blue(Color.blue);
  public Color color;

  private GamePiece(Color color)
  {
    this.color = color;
  }
}

---

The Model: Primarily, the job of the Model is to:

• Provide data for the UI (upon request)
• Validation of data (upon request)
• Long-term storage of data (upon request)

Code:

import java.util.*;

public class Model
{
  private static final Random rnd = new Random();
  private static final GamePiece[] pieces = GamePiece.values();

  private GamePiece selection;

  public Model()
  {
    reset();
  }

  public void reset()
  {
    selection = pieces[randomInt(0, pieces.length)];
  }

  public boolean check(GamePiece guess)
  {
    return selection.equals(guess);
  }

  public List<GamePiece> getAllPieces()
  {
    return Arrays.asList(GamePiece.values());
  }

  private static int randomInt(int min, int max)
  {
    return rnd.nextInt((max - min) + 1) + min;
  }
}

---

The View: The idea here is to make it as "dumb" as possible by stripping out as much application logic as you can (the goal is to have none). Advantages:

• The app now be 100% JUnit testable since no application logic is mixed in with Swing code
• You can launch the GUI without launching the entire app, which makes prototyping much faster

Code:

import java.awt.*;
import java.awt.event.*;
import java.util.List;

public interface View
{
  public void addPieceActionListener(GamePiece piece, ActionListener listener);
  public void addResetActionListener(ActionListener listener);
  public void setGamePieces(List<GamePiece> pieces);
  public void setResult(Color color, String message);
}

and the GUI:

import java.awt.*;
import java.awt.event.*;
import java.util.List;
import javax.swing.*;

/**
 * View is "dumb". It has no reference to Model or Presenter.
 * No application code - Swing code only!
 */
public class Gui implements View
{
  private JFrame frame;
  private ColorIcon icon;
  private JLabel resultLabel;
  private JButton resetButton;
  private JButton[] pieceButtons;
  private List<GamePiece> pieceChoices;

  public Gui()
  {
    frame = new JFrame();
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    icon = new ColorIcon(80, Color.WHITE);
  }

  public void setGamePieces(List<GamePiece> pieces)
  {
    this.pieceChoices = pieces;

    frame.add(getMainPanel());
    frame.pack();
    frame.setLocationRelativeTo(null);
    frame.setVisible(true);
  }

  public void setResult(Color color, String message)
  {
    icon.color = color;
    resultLabel.setText(message);
    resultLabel.repaint();
  }

  private JPanel getMainPanel()
  {
    JPanel panel = new JPanel(new BorderLayout());
    panel.add(getInstructionPanel(), BorderLayout.NORTH);
    panel.add(getGamePanel(), BorderLayout.CENTER);
    panel.add(getResetPanel(), BorderLayout.SOUTH);
    return panel;
  }

  private JPanel getInstructionPanel()
  {
    JPanel panel = new JPanel();
    panel.add(new JLabel("Guess what color!", JLabel.CENTER));
    return panel;
  }

  private JPanel getGamePanel()
  {
    resultLabel = new JLabel("No selection made", icon, JLabel.CENTER);
    resultLabel.setVerticalTextPosition(JLabel.BOTTOM);
    resultLabel.setHorizontalTextPosition(JLabel.CENTER);

    JPanel piecePanel = new JPanel();
    int pieceCount = pieceChoices.size();
    pieceButtons = new JButton[pieceCount];

    for (int i = 0; i < pieceCount; i++)
    {
      pieceButtons[i] = createPiece(pieceChoices.get(i));
      piecePanel.add(pieceButtons[i]);
    }

    JPanel panel = new JPanel(new BorderLayout());
    panel.add(resultLabel, BorderLayout.CENTER);
    panel.add(piecePanel, BorderLayout.SOUTH);

    return panel;
  }

  private JPanel getResetPanel()
  {
    resetButton = new JButton("Reset");

    JPanel panel = new JPanel();
    panel.add(resetButton);
    return panel;
  }

  private JButton createPiece(GamePiece piece)
  {
    JButton btn = new JButton();
    btn.setIcon(new ColorIcon(16, piece.color));
    btn.setActionCommand(piece.name());
    return btn;
  }

  public void addPieceActionListener(GamePiece piece, ActionListener listener)
  {
    for (JButton button : pieceButtons)
    {
      if (button.getActionCommand().equals(piece.name()))
      {
        button.addActionListener(listener);
        break;
      }
    }
  }

  public void addResetActionListener(ActionListener listener)
  {
    resetButton.addActionListener(listener);
  }

  private class ColorIcon implements Icon
  {
    private int size;
    private Color color;

    public ColorIcon(int size, Color color)
    {
      this.size = size;
      this.color = color;
    }

    @Override
    public void paintIcon(Component c, Graphics g, int x, int y)
    {
      Graphics2D g2d = (Graphics2D) g;
      g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
          RenderingHints.VALUE_ANTIALIAS_ON);
      g2d.setColor(color);
      g2d.fillOval(x, y, size, size);
    }

    @Override
    public int getIconWidth()
    {
      return size;
    }

    @Override
    public int getIconHeight()
    {
      return size;
    }
  }
}

What might not be so obvious right away is how large the View interface can get. For each Swing component on the GUI, you may want to:

• Add/Remove a listener to the component, of which there are many types (ActionListener, FocusListener, MouseListener, etc.)
• Get/Set the data on the component
• Set the "usability" state of the component (enabled, visible, editable, focusable, etc.)

This can get unwieldy really fast. As a solution (not shown in this example), a key is created for each field, and the GUI registers each component with it's key (a HashMap is used). Then, instead of the View defining methods such as:

public void addResetActionListener(ActionListener listener);
// and then repeat for every field that needs an ActionListener

you would have a single method:

public void addActionListener(SomeEnum someField, ActionListener listener);

where "SomeEnum" is an enum that defines all fields on a given UI. Then, when the GUI receives that call, it looks up the appropriate component to call that method on. All of this heavy lifting would get done in an abstract super class that implements View.

---

The Presenter: The responsibilities are:

• Initialize the View with it's starting values
• Respond to all user interactions on the View by attaching the appropriate listeners
• Update the state of the View whenever necessary
• Fetch all data from the View and pass to Model for saving (if necessary)

Code (note that there's no Swing in here):

import java.awt.*;
import java.awt.event.*;

public class Presenter
{
  private Model model;
  private View view;

  public Presenter()
  {
    System.out.println("ctor");
  }

  public Presenter(Model model, View view)
  {
    this.model = model;
    this.view = view;
  }

  public void start()
  {
    view.setGamePieces(model.getAllPieces());
    reset();

    view.addResetActionListener(new ActionListener()
    {
      public void actionPerformed(ActionEvent e)
      {
        reset();
      }
    });

    for (int i = 0; i < GamePiece.values().length; i++)
    {
      final GamePiece aPiece = GamePiece.values()[i];
      view.addPieceActionListener(aPiece, new ActionListener()
      {
        public void actionPerformed(ActionEvent e)
        {
          pieceSelected(aPiece);
        }
      });
    }
  }

  private void reset()
  {
    model.reset();
    view.setResult(Color.GRAY, "Click a button.");
  }

  private void pieceSelected(GamePiece piece)
  {
    boolean valid = model.check(piece);
    view.setResult(piece.color, valid ? "Win!" : "Keep trying.");
  }
}

---

Keep in mind that each portion of the MVP architecture can/will be delegating to other classes (that are hidden to the other 2 portions) to perform many of its tasks. The Model, View, and Presenter classes are just the upper divisions in your code base heirarchy.