Design considerations for multiple forms.

[Nathaniel Johnson]

I am laying out the basic elements of an app and I want to be certain that I understand some things correctly.

If I use a singleton as a controller that has methods like

public void showMainForm() {
    if(mainForm==null) mainForm = new MainForm();
    mainForm.show();
}
public void showListOfThingsForm() {
    ...
    listOfThingsForm.show();
}
public void showEditThingForm() {
    ...
    editThingForm.show();
}

I intend to lazily instantiate the forms as needed but retain single instances to be reused. 

My questions are:

Are using multiple forms the correct way to manage multiple related pages?

Would it be better to have a single page and swap out the content with different Component derived classes.

Is this pattern already built in and I haven't run across it yet?

-Nathaniel

[Shai Almog]

Multiple forms are how we usually work, we consider that approach superior although we support any approach you want.

The GUI builder uses a state machine architecture which is very common in mobile development. All forms are created/discarded dynamically (one form in RAM) and the state machine navigates between them.
This is very efficient in terms of RAM which is usually far more constrained than CPU on a mobile device.

The kitchen sink demo has effectively 2 forms, one is the main form which is always in RAM and the second is the one for the demo which is created dynamically.

[Klaus]

My StateMachine is full of generated UI-Code and has become unreadable , specially for TeamWork.

The problem is that the Designer injects all UI-Code into the StateMachine-class.

Is there a reasonable possibility to force the Designer to inject generated Code into other classes of my choice?

I tried that manually and it worked but I ran into many problems. That makes the Designer completely useless for me.

I can solve this problem by hand-coding all UI-Code into classes of my choice .

But sometimes it'd desirably  to work with quick&dirty generated UI-code to save time .

e.g. in Swing I simply extend the JInternalFrame.

but to extend the StateMachineBase in more than 1 class means many many  problems because of the theme.res-constructor in main-class.

Any suggestions?

thanks

[Eric Coolman]

Personally I break down the StateMachine into multiple controllers.  I maintain a map of controllers for each form, something like:

Map<Form, Controller> controllers;

Then for actions within the StateMachine, I use something like:

Controller controller = controllers.get(myform);

((MyController)controller).onMain_ComboBoxAction(component, event);

That will reduce your state machine significantly and move the controller logic to more manageable pieces.

Eric

[Eric Coolman]

Correction, 

Map<String, Controller>

and 

controllers.get(myForm.getName());

Can't hold a strong reference to a form as it is destroyed and created as needed.

Eric

[Klaus]

thanks a lot, Eric ! 

I 'm pleased to try your workaround