AppState interface usage poll

Development
1

I’m curious how folks use AppStates… so I made a poll:

  • I use one of the AppState base classes like I’m supposed to.
  • I’m a rebel and just implement the AppState interface directly.
  • What’s an AppState?

0 voters

Reasoning: I would like to add a getId():String method to the AppState interface and then default implementations to the base classes. This would “harm” only those who implement AppState directly.

Adding the method is WAY easier and cleaner than having an interim IdentifiableAppState interface or somesuch.

The idea here is to be able to lookup AppStates by ID instead of just class. Useful when you have something like a ViewPortState and want to get the “rootNode” viewport versus the “guiNode” viewport, for example.

3 Likes
2

well im not sure why someone would want expand AppState interace since there is AbstractAppState/BaseAppState to make own AppState. (that is anyway low level)

since for example “public class BulletAppState implements AppState” this do not extend Abstract layer, just interface, so you would need add it to multiple Classes. (just dont forget about AbstractAppState/BaseAppState :slight_smile: )

3

I’m sure there are no rebels <clicks show results>

…Hey! Kill that frog already! :slight_smile:

1 Like
4

By the way, this means we can now have 2 instances of the same AppState class?

I’ve believed that AppStates and Controls are the same thing, except for you can have only 1 instance of AppState, instead you can have multiple Controls (but must be attached to some Spatial). Am I wrong?

5

this jedi rebels…

6

You already can. You just can’t look up anything but the first one.

Using composition over inheritance: AppStates extend Application’s functionality. Controls extend Spatial’s functionality. That’s the only difference.

I frequently have multiples of the same app state class… viewports being a good example.

1 Like
7

How about a relatively sane default implementation in the interface like
default String getId() { return getClass().getName(); }

(needs Java 8)

8

Wouldn’t this also require to change the API in the AppStateManager? To return a collection, array or else of AppStates then? And/Or adding a parameter to specify the id.

Is the id then meant to be unique or unique among the same app state class?

9

That’s still an issue, I guess.

10

Yes, but AppStateManager is a class and so adding a method won’t break anyone.

I would add methods for getting a state by ID (probably by ID and class for nice type parameterization).

IDs are meant to be unique.

11

I think is going to be really good for adding instances of the same class, but maybe it can be done with something like the ElementId, that way it can be added as a child, and then you can get an array of states of a parent as well as an indivial state.
This is what i imagine how it could be used

        this.stateManager.attach(new ElementId("viewport").child("gui").child("minimap"),new ViewPortState());
        this.stateManager.attach(new ElementId("viewport").child("gui").child("buttons"),new ViewPortState());
        this.stateManager.attach(new ElementId("viewport").child("camera"),new ViewPortState());

        for(AppState state : this.stateManager.getStates("viewport.gui")){
            if(state instanceof ViewPortState){
                if( ((ViewPortState)state).isClosing() ){
                    this.stateManager.detach(state);
                }
            }
        }

        ViewPortState minimap = this.stateManager.getState(ViewPortState.class, "viewport.gui.minimap");
12

I think that’s overly complicated for this. If you want your app state to be ID=“viewport.gui.minimap” then that’s up to you.

Also, because of the way AppStateManager supports multithreaded access, you will likely never see a getStates() method since it would have to copy the data.

13

didnt knew about that, lol, just thought it would be cool

14

Wait! It does?!
Mind is blown, I have always queued all of my appstatemanager calls on the render thread.

15

Yes, AppStateManager is thread safe. Probably could be more explicitly documented.

The AppState javadoc could have been a lot simpler otherwise:
https://javadoc.jmonkeyengine.org/com/jme3/app/state/AppState.html

Though I guess it could be a little clearer about why it calls out specific threads so many times.

2 Likes
16

Most of my app states are derived from a custom base class NamedAppState, written in 2017. As you might imagine, it includes a per-instance String (for debugging purposes).

Adding a method to the AppState interface will impact me. However, I don’t mind modifying my libraries. So go ahead.

1 Like
17

I do the same as sgold, but I also don’t mind if that changes.

1 Like
18

I was soooo tempted to click on “What’s an AppState” because that option looks so lonely

9 Likes
19

Isn’t JME 3.0 that’s tied to java 7, while 3.1+ requires java 8? (Or maybe it was just the SDK…)

20

People still use Java 7 with JME 3.2.x.