StateDetached is not the same as cleanup, no. Its called when the state is detached and not guaranteed to run on the update thread. Its only for very special things really. Otherwise yes, its a matter of preference.
Where does this class come from? I don’t see it in JME.
Most app states will be easier to write if they extend (JME’s) BaseAppState (which is a direct copy of Lemur’s). It provides a nicer enable/disable life cycle and makes it incredibly easy to look up other app states.
And yeah, almost always if you are putting code in stateAttached() or stateDetached() then you are doing something wrong.
The anti-pattern is all of the protected fields. Let’s say we wanted to move management of the root node and guiNode into app states like they probably should have been (hindsight being 20/20)… well, the class says a big f*ck you to that. This is why this class will be deprecated soon. I already had to do “very bad things” ™ to move fly cam to an app state… and don’t get me started on the stats crap.
I think one day I will print this class out and set the print out on fire just to get some closure.
I certainly would… it’s bound to have bugs that haven’t been fixed yet. And for the moment BitmapText is working as long as one treads lightly in the code.
Someday, I will rewrite the whole thing to centralize more of the functionality on BitmapFont where it belongs instead of having it implemented two or three times… but I need to be in the proper frame of mind.
The new BaseAppState is even better. It helps manage the setEnabled() life cycle which can be tricky to get right on your own… plus it provides easy access to other states, the application, etc…