Question about abstractAppStates

I’m going to be reworking a user interface class but before I started I wanted to ask a question about AbstractAppStates.

Is there such a thing as too many appStates ?

The reason I ask is I plan on making a base control that is an abstractAppState then each new control type extends the base control. Each GUI element will be a new abstractAppState. I want to know if there are any downsides to having lots of appStates running like a performance impact , etc.

Practically no.
But there are almost certainly better ways. What is the reason for which you can’t use spatials and controls?

I am using spatials. Each UI element consist of a quad. The quad needs to be update each loop.

Thank you , you just gave me a great idea. I could use custom controls to make each individual UI element type. Then create a manager to handle them.

Now the question is how do I access the GUI node via a control ?

Hmm… Try by calling getParent() on the spatial which has the control. If that is not guiNode, keep bubbling up until name of the node is guiNode or whatever is the actual name.

Trust me… for a UI library, you shouldn’t need to to this:

Or this:

So maybe something about your design is strange.

For ideas, you could look at Lemur… which uses regular JME spatials and controls. Or just reuse pieces of it… or all of it.

Either way, if you make app states then you probably want to extend BaseAppState is it provides better life cycle management. AbstractAppState is really bare bones and then you sill have to carefully manage all of the setEnabled()/initialize()/cleanup() stuff yourself.

I actually just went back and used all abstract states. I already had the code for drawing all of the controls. It was just a matter of implementing it. I’ll look into BaseAppState later and apply it as needed.

Basically I created a very simplified version of Lemurs. I only created the most standard controls. Label , button , textfield , scroll bar and frame.

lol… that’s pretty much the only controls lemur has.

Having each GUI element be an app state is a little silly, though. I mean, design-wise that’s VERY strange.

At their core, appstates and controls are basically the same thing… the rule of thumb I follow to discriminate is this:

How many concurrent instance of the thing do I need?
One: use an appstate
Two or more: use a control

Ultimately I went with my old design which is one app state per Group. A group is defined as a group of controls that makes up an interface. The I added a manager for managing each group.

Which I hope is


Everything else is pure and unneeded bloat.

I use attach and detach. In my clean up and initialize code I add and remove the elements from the GUI. No reason to disable the menu. Once it’s closed it should go off screen. Plus I have to remove the listeners.

I usually don’t want to initialize the appstate every time I need it, so I just attach component to a “state Node” and attach and remove that instead (on the setEnabled).

It depends on what you are trying to achieve. I have multiple listeners so I need to remove those as well.