Does this situation warrant using the singleton pattern?

Question

I am creating a mini software application and it uses multiple "menu screens" if you will. For instance; a Main Menu Screen, a Login Screen, and a screen for all the different features the application supports. I'm currently handling this using the following class:

public class ScreenUpdater {

    public static void updateScreen(JPanel screen, JFrame frame) {

        SwingUtilities.invokeLater(new Runnable() {

            @Override
            public void run() {
                frame.remove(frame.getContentPane().getComponent(0));
                frame.getContentPane().add(screen);
                frame.invalidate();
                frame.revalidate();
            }
        });

    }

}

The static method updateScreen() takes the following arguments:

• The new screen to appear in the JFrame (eg new LoginScreen(MainScreen mainScreenRef)) (Note that the LoginScreen takes a reference to the main screen so it itself can reference the original JFrame).
• The JFrame in which the new screen is to appear.

This is working well for me, however I have noticed something which I believe to be a problem. The LoginScreen for instance will call up another screen upon the press of a button, and all this will happen within the button's called method, leading me to believe that even when the LoginScreen is not being displayed, it still exists with active references to it. Furthermore, upon returning to the same screen twice, new instances will pile up with the garbage collector not being able to dispose of previous instances as they are lower on the stack.

To address this problem, I believe the Singleton design pattern could be of use.

My questions to you all are (in order of importance):

• Are my thoughts on the pile up of these instantiations correct?
• If so, is this an ideal situation to use the Singleton pattern or is there a better solution?
• Is this approach in itself just an extremely poor one?

Thank you all very much in advance!

CLARIFICATION - This is what I mean when I refer to the problem of garbage collection. Say we have a class called LoginScreen() with a method called login(). The method login() instantiates the MainMenu() class so that this can now appear in the JFrame. Any methods that are then called from the MainMenu() class are called before the original login() method is completed. This is what leads me to believe that the original LoginScreen() will not be collected by the garbage collector.

Answer 1

The short answer is that no, this doesn't sound like a reason to use a singleton.

You've said that you're afraid you're keeping around instances to these screens even when they aren't being displayed: what makes you believe that? If you don't have any references to them, then they'll be eligible for garbage collection. As soon as the method exits, assuming you don't have any other references to the screen, then the object will be eligible for garbage collection.

However, all of this sounds like a job for CardLayout anyway.

If you want more info, please post an MCVE .