Friday, December 14, 2007

MVC and Swing

The Model-View-Controller (MVC) architecture factors function code from the GUI design using a controller module. The controller module ties event listeners in the view module to their actions in the model module. Good programming practice implies private properties with public accessor methods for those needing access from outside their container object. These three object modules can be designed at different times by different programmers.

The well-known MVC paradigm is generally recommended as the fundamental architecture for GUI development. Many variations of the pattern are available, like MVC++, HMVC (Hierarchical MVC), MVC Model 2, MVC Push, and MVC Pull, with each emphasizing slightly different issues.

The model object should have methods for run(), about(), help(), and exit() as these are common to most utilities. The view object constructor should accept a string that incorporates the utility title. The view object also requires methods to build the listeners. buttonActionListeners() includes addActionListener() and a setActionCommand(string) which is used to pass a reference of the pressed button. The controller module uses getActionCommand() to call the correct action method in the model. An example of MVC architecture using the MyGUI example is:



/**

* @author Deepak Singhvi

* @version v7.4

*/



import java.awt.*;

import java.awt.event.*;

import javax.swing.*;

/* myGUI demonstrates separation of functionality

from GUI design by using MVC architecture */



// first comes the root class that builds the architecture

public class MyGUI {



public static void main(String args[]) {

MyGUIModel model = new MyGUIModel();

MyGUIView view = new MyGUIView("myGUI MVC Demo");

MyGUIController controller = new MyGUIController(model, view);

}

}



// the model is where functionality (ie properties & methods) goes

class MyGUIModel {



public void exit() {

System.exit(0);

}



public void run() {

JOptionPane.showMessageDialog(null, "Deepak hear you!",

"Message Dialog", JOptionPane.PLAIN_MESSAGE);

}

}



// the view is where the GUI is built

class MyGUIView extends JFrame {



JButton run = new JButton("Run the Utility");

JButton exit = new JButton("Exit After Save");

JPanel buttons = new JPanel(new GridLayout(4, 1, 2, 2));



MyGUIView(String title) // the constructor

{

super(title);

setBounds(100, 100, 250, 150);

setDefaultCloseOperation(DO_NOTHING_ON_CLOSE);

buttons.add(run);

buttons.add(exit);

this.getContentPane().add("Center", buttons);

setVisible(true);

}



//method to add ActionListener passed by Controller to buttons

public void buttonActionListeners(ActionListener al) {

run.setActionCommand("run");

run.addActionListener(al);

exit.setActionCommand("exit");

exit.addActionListener(al);

}

}



// the controller listens for actions and reacts

class MyGUIController implements ActionListener {



MyGUIModel model;

MyGUIView view;



public MyGUIController(MyGUIModel model, MyGUIView view) {

  // create the model and the GUI view

  this.model = model;

  this.view = view;

  // Add action listener from this class to buttons of the view

  view.buttonActionListeners(this);

}



// Provide interactions for actions performed in the view.

public void actionPerformed(ActionEvent ae) {

  String action_com = ae.getActionCommand();

  char c = action_com.charAt(0);

  switch (c) {

    case'r':

      model.run();

      break;
 
    case'e':

      model.exit();

      break;

    }

  }

}





Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine

Hi Friends,

I found this white paper on Garbage collection in Sun's website intersting. It discusses on options of choosing the GC.

In the J2SE platform version 1.4.2 there were four garbage collectors from which to choose but without an explicit choice by the user the serial garbage collector was always chosen. In version 5.0 the choice of the collector is based on the class of the machine on which the application is started.

This “smarter choice” of the garbage collector is generally better but is not always the best. For the user who wants to make their own choice of garbage collectors, this document will provide information on which to base that choice. This will first include the general features of the garbage collections and tuning options to take the best advantage of those features. The examples are given in the context of the serial, stop-the-world collector. Then specific features of the other collectors will be discussed along with factors that should considered when choosing one of the other collectors.

When does the choice of a garbage collector matter to the user? For many applications it doesn't. That is, the application can perform within its specifications in the presence of garbage collection with pauses of modest frequency and duration. An example where this is not the case (when the serial collector is used) would be a large application that scales well to large number of threads, processors, sockets, and a large amount of memory.





http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

I hope it will help in optimizing the GC related problems

Heroku Custom Trust Store for SSL Handshake

  Working with Heroku for deploying apps (java, nodejs, etc..) is made very easy but while integrating one of the service ho...