Creating Dynamic Swing Views with Reflection by Extending MVC

On a historical note, model–view–controller architectural pattern was conceived in the mid–1980's by developers of the Smalltalk-80 GUI library. It has since then been extensively used in most object oriented user interfaces, it has also been extensively covered in numerous books and publications. According to the MVC pattern, the model should be separated from the actual implementation of its view. The reason being, that there could be many representations of the same data and closely coupling views with the model would complicate project’s development, modifications and create maintenance nightmares.

In other words, you do not want to change your business logic every time you change your view.

When working on a large Swing GUI project, one way to represent views is to use Tabs or JTabbedPane as an underling class. Development of different modules should be assigned to different programmer groups and at the end and each Tab (view) has to be added to the main application. And before any coding is done, project architects usually come up with object relationship diagrams, use-case diagrams, object flow diagrams and hand out coding responsibilities. At the same time, GUI programmers or designers create appropriate screen prototypes for all sections.

Sample Project

In an enterprise level application properties are usually read as java.util.Properties and include data-store locations, connection pool information, environment variables, debug levels and other global information. For our purposes only views info in a text file will suffice. Additional services managed by controller like persistence, distribution or security, are also beyond the scope of this article.

Main Controller

ConcreteView1
ConcreteView2
ConcreteView3

MainController also has three fields: a main JTabbedPane to add new Views too, an array of Tabs and a HashMap of to store Model objects.

In the init method I call the loadProperties("smvc.properties") to fill the array with tab names from the property file. As each view’s class name is read from the properties file, I use Java Reflection API to instantiate actual objects and add them to the main JTabbedPane. See listing 1 at the end of this article.

{
Class newClass = Class.forName((String) tabs.get(i));
//try to make an object – extending AbstractView
AbstractView anyTab = (AbstractView) newClass.newInstance();
//add our new view tab here, and set its name
mainPane.addTab(anyTab.getName(), anyTab);

// I also set a reference back to the Controller
// let each tab know who is its controller
anyTab.setParent(this);
}

As soon as I add all dynamic Tabs, we can see them:

Swing Views

// get the name of the class - for tab name
String name = this.getClass().getName();
// get rig of all package info just leave class name
setViewName(name.substring(name.lastIndexOf('.') + 1));

I created several concrete view classes; each concrete View class calls an init method of its super class to set its name and adds a button to invoke a simple action from a corresponding Model, via MainConntoller object. Usually a view layer implements a rendering of the model, but in our case I will only call an action. The view is responsible for getting and showing information from the corresponding model that is appropriate based the model state. The view also gathers information to pass on to the model via controller. If I wanted too, I could’ve added some fields in the each Model and got their data when a matching action was requested from my Tab.
When the button on concrete View 1 is pressed, it will call MainController execute method (via its reference to parent we set earlier) and pass a String key or Model name to let the Controller know to which model it should delegate the request. Code below demonstrated this.