Command, Singleton, JMenuItem, JButton, AbstractButton – One Listener for the app

Here I would like to demonstrate a simple use of JMenuItems being used with Single Listener for the entire system.
A simple sample of use would probably be SingleInstance Desktop Application.

Lets see how that is done here.

1. First lets create a OneListener class that should be able to listen to ActionEvents and also be able to add Commands to itself. Please refer to my previous post on Command,Singleton if you would like to see more about this patterns and there usage.

  1. package com.shaafshah.jmenus;
  2.  
  3. import java.awt.event.ActionEvent;
  4. import java.awt.event.ActionListener;
  5. import java.util.ArrayList;
  6.  
  7. import javax.swing.AbstractButton;
  8.  
  9. // Implements the ActionListener and is a Singleton also.
  10.  
  11. public class OneListener implements ActionListener{
  12.  
  13. 	private static OneListener oneListener = null;
  14.  
  15. 	// Holds the list of all commands registered to this listener
  16. 	private ArrayList<Command> commandList = null;
  17.  
  18. 	// A private constructor
  19. 	private OneListener(){
  20. 		commandList = new ArrayList<Command>();
  21. 	}
  22.  
  23. 	// Ensuring one instance.
  24. 	public static OneListener getInstance(){
  25. 		if(oneListener != null)	
  26. 			return oneListener;
  27. 		else return oneListener = new OneListener();
  28. 	}
  29.  
  30. 	// Add the command and add myself as the listener
  31. 	public void addCommand(Command command){
  32. 			commandList.add(command);
  33. 		    ((AbstractButton)command).addActionListener(this);
  34. 	}
  35.  
  36.  
  37. 	// All Events hit here.
  38. 	@Override
  39. 	public void actionPerformed(ActionEvent e) {
  40. 		((Command)e.getSource()).execute();
  41. 	}
  42.  
  43. }

In the above code, the addCommand method adds the command Object and adds a listener to it.
Now how is that possible.
Basically because I am categorizing my UI objects as Commands with in the system having some UI. And I am also assuming that these commands are Currently AbstractButton i.e. JMenuItem, JButton. Lets have a look at the Command Interface and its Implementation.

  1. public interface Command {
  2. 	public void execute();	
  3. }

And the implementation, note that the Command is an interface where as the class is still extending a UI object.

  1. import javax.swing.JMenuItem;
  2.  
  3. public class TestCmd extends JMenuItem implements Command{
  4.  
  5. 	public TestCmd() {
  6. 		super("Test");
  7. 		OneListener.getInstance().addCommand(this);
  8. 	}
  9.  
  10. 	@Override
  11. 	public void execute() {
  12. 		System.out.println("HelloWorld");
  13. 	}
  14. }

Personally don’t like calling the OneListener in the constructor of the class but just for the sake of simplicity of this post I have left it that way. There are many different ways to omit it.

So the TestCmd is a JMenuItem but is also a Command and thats what the OneListener understands.
As this commads Listener is also OneListener all ActionEvents are thrown there and from there only the Command.execute is called on.

So now you dont have to worry about what listeners are you in. The only thing you know is that when execute is called you need to do your stuff.

You can download the code from Here.

Hope this helps.

Continous Integration – A blast from the past

Although this didn’t happen a decade ago but still has been a good case for me to learn and realize how Continuous Integration brings value addition to our work.

As I recall it was like this when they were teenagers 😀
Few teams working on different modules of same application, deployed together.
No build process formalized
No builds except for the ones that need major milestone deployments.
No feedback, reports, reviews etc.

So virtually there was no build eco system.

Which meant hideous amounts of communication, tons of trouble shooting, last minute show stoppers, And extermely unhappy end users/stake holders.

So what exactly was going wrong.

There was no Configuration Control i.e. No way to figure out the changes that will be part of the release and no controls to include or exclude them.
No Status accounting i.e. No feedback or status of anything as a whole product.
No management of Environment meant no one knew what hardware/software they were using and sometimes why?
No team work whatsoever meant no guided processes, reviews or tracebility of issues and pitfalls.

So virtually a release day was the doomsday!

It took some time for developers to realize that how important the following were.
* Configuration identification – What code are we working with?
* Configuration control – Controlling the release of a product and its changes.
* Status accounting – Recording and reporting the status of components.
* Review – Ensuring completeness and consistency among components.
* Build management – Managing the process and tools used for builds.
* Process management – Ensuring adherence to the organization’s development process.
* Environment management – Managing the software and hardware that host our system.
* Teamwork – Facilitate team interactions related to the process.
* Defect tracking – Making sure every defect has traceability back to the source

And after all it takes some time but the day to day flow looked like the figure below.

Build Management
Build Management

Importantly
Developers are distributed on different locations in different teams.
There is an SCM team that takes care of the SCM activities i.e. Configuration Identification, Control, Build Management etc.
There is one single repository for all developers.
A process is defined for Product integration and its checked whenever some one checks in.
And hourly build is dont to check the sanity of the system with the unit tests.
A Nightly build is done with all full blown unit tests, coverage reports, Automated tests and installers and upgrades.
More over all of the above is shown on an FTP/HTTP site. FTP for installer/binary/archive pickup and HTTP for detailed view of builds/feedbacks etc.

All of the above meant strength and health of the build eco system. And more trust in the system that it will report failures along the way.

Doing the Locale – Danmark

The following illustrates how to get the Number format working with a danish locale.

  1. import java.text.NumberFormat;
  2. import java.util.Currency;
  3. import java.util.Locale;
  4.  
  5.  
  6. public class TestLocale {
  7.  
  8.  public static void main(String args[]){
  9.  // Create a Locale for Danmark
  10.  Locale DANMARK = new Locale("da","DK");
  11.  
  12.  // get the currency instance for this locale.
  13.  Currency krone = Currency.getInstance(DANMARK);
  14.  
  15.  // Get a Number format for the locale.
  16.  NumberFormat krFormat = NumberFormat.getCurrencyInstance(DANMARK);
  17.  // A symbol for the currency
  18.  String symbol = krFormat.getCurrency().getSymbol();
  19.  // A double amount
  20.  double amount = 10000.25;
  21. // print it out after formatting.
  22.  System.out.println(krFormat.format(amount));
  23.  }
  24. }

That thing about CI – Continous Integration

Challenging Business requirements and the need for software development teams to remain agile and competitive while managing parallel development and releases requires a system which is adaptive to these demands.

Our approach to SCM enables unlimited and adaptable process models, which are ideally suited for parallel, distributed, and agile software development. Using state of the Art technologies from various vendors to automate processes such as branching, merging, build, and release keeps you a click away from software delivery.

The real matter then is the sanity of your application and that’s the challenge we all need to address. We can have cute products right of the shelf to get it up and going but the whole challenge lies in the statement “up and going”. It takes a ton of energy and effort to come up with the right process and the right tool. I have not seen alot of CI projects failing strictly. But I do have seen extra efforts into things that should not be really there. failure would then mean the amounts of efforts spent on doing not so trivial stuff and on the other end if you are spending alot of time doing the major flows then definately something is wrong.

Automation does solve most parts of the problems but things that really need to be taken care of to get it right in the sweet spot are the ones Martin Fowler described in one of his articles.

* Maintain a Single Source Repository
Keep everyone together, at the end of the day we all work together dont we?

* Automate the Build
Automation of the build helps you.

* Make Your Build Self-Testing
Self testing build tells you exactly what you did and what you broke. So I can come up with this statement to my Lead. “If I commit this, it might break alot of stuff”. Well Sir, try running the Unit Test, You will know for sure! But then again honesty on the test cases really doest matter!

* Everyone Commits Every Day
Typically in a Agile environment helps alot, and forces you not to break the build. Better organization I must say.

* Every Commit Should Build the Mainline on an Integration Machine
Sanity checking of your commits. So often we commit without realiazing that we break something else.

* Keep the Build Fast
I usually commit before leaving for home. It helps great deal when you get the feedback within 5 mins. kind of a benchmark but depends.

* Make it Easy for Anyone to Get the Latest Executable
Keep all the build results and one sharable place. We did that on one of the http servers some time back

* Everyone can see what’s happening
Importantly that all results are published for all of us to know.

* Automate Deployment
Deployment automation means that my buddy X on the other side doesnt screw up the server for even a 1 min. Only deploys when build successfull.

Hope this helps.

Resources:

http://martinfowler.com/articles/continuousIntegration.html