Good practice about AppStates or not?

General Discussion
1

I find myself using AppStates like this:

MenuAppState extends BaseAppState{
 void initialize(){
 //do stuff...
 setEnabled(false);
 }
}

AnotherAppState extends BaseAppState{
 initialize(){
 //do stuff...
  setEnabled(false);
 }
 onDisable(){
  getState(MenuAppState.class).setEnabled(true);
 }
}

Since I want init() to be called only once, I prefer to use setEnable/Disabled rather than attaching/detaching AppStates… is it good practice or not?

2

It’s fine but you should probably setEnabled(false) in your constructor instead of in initialize to avoid strange ordering issues. For example, maybe the thing attaching it wants to enable it too but it can’t because you will revert it right after it’s attached.

3

Uhm… could this be interesting to have in the core jme?

I mean: I have an appstate that loads textures during initialization. If I attach and detach it the Texture will get loaded every time (yes, it is cached by the AssetManager and therefore will not actually be loaded, but still…).

How about adding this method?

AppStateManager.attachDisabled(AppState)

init+setEnabled(false). You call it when you want this behavior.

4

Personally I don’t see the use of this. It would kind of clutter the API and add confusion just to avoid one line of code in very particular cases.

Still not sure why you need this.

5

Not to mention that the StateManager takes the an AppState and does not know it might be a BaseAppState. This would mean having to add methods to the interface or implement a different type of StateManager which takes BaseAppState instead.

6

This is why I created this topic :stuck_out_tongue:

  1. Assuming that the “init” part of an AppState is intended be executed only once (because my logic wants so); if I detach and reattach it I will execute another init cycle, and therefore I need to use setEnable() instead of attach();

  2. I need control on when the “init” is executed (because I want to load all the asset and creating all the controls during startup).

Basically, I show up the loading screen and load everything on background, so that when the loading is finished I have all the appstates paused and ready to be enabled at will.

7

Man, what’s so hard about:

public class MyAppState extends BaseAppState {
    public MyAppState() {
        setEnabled(false); //disabled by default.
    }

    ...the rest of the app state...
}

We shouldn’t be adding 100 odd edge case methods to avoid one line in your own class.

1 Like
8

I 100% agree, but I think this is not the point.
I don’t want to shape jme to my particular needs (which may or may not be useful to others), but instead to add more flexibility to the AppState management.
By comparison, the Android Activity lifecycle is more complex: http://developer.android.com/training/basics/activity-lifecycle/starting.html

But I guess AppStates are kept simple by design, which I cannot argue against :smile:

9

That’s the worst argument ever :)).
Android activity life cycle is a total mess.
And I won’t speak about the media player life cycle that can’t have been made by a sane mind.
I really recommend to not take this as an example in your developments.

1 Like
10

I agree, cant see an point for it.
The initialize should execute for each new object, it suppose to fill the state variables.
If you need init() to be called only once you just have an very particular case, but its not an good practice to be implemented in the engine. Also if implemented, it will bug every game made in the engine before.
But, there is one case I was thinking of and I could not find better solution yet , about the asset loading…
Currently, to prevent loading times in the middle of the gameplay when loading new spaws of enemies in my game, I load static assets vars for each control, for all assets that will be used in the level the player is going to play, and then when I create the controls, I just clone the already loaded spatial, when the level is over, I just free all this assets, and repeat on next level.
There is any bether way to do it ?

11

FYI: The asset manager is already cloning already loaded spatials when you load them.