For every argument you make to extending application just to insert your own VR bits… some other library developer can make for their own library. Then the USER is left having to choose one or the other.
Or for every argument you make to extending application just to insert your own VR bits, some app developer has the same reasons that they extended application just to insert their own bits… and now that is incompatible with extending your VR application.
Subclassing is more limiting because all things must be resolved at compile time. App states is just like subclassing except some things can be resolved at runtime. One has limits the other doesn’t, basically. Else every problem with one is the same problem with the other.
Every argument about “but what about app state ordering, etc.” is the same with subclassing “but what if my override needs to call the original method and not the vrapp overridden one” Well, you’re stuck.
It seemed like at the beginning of this conversation that we might have reached some way that your VRApplication code could be useful for JME users going forward. Now it seems like you don’t have the time to maintain it really and so those users will have to wait until the JME contributors can support VR properly. It’s understandable, you have a lot on your plate and so on.
Just for clarification, we are talking about implementing Application here, not extending (since Application is now an interface). Also, you do even say yourself you will be creating your own set of base classes:
Why is VRApplication being its own application base class such a problem? You make the freedom to do so sound like a good thing here.
It seems the only way you’d consider jMonkeyVR useful is if it was an AppState, which is rather boxing me in. As you said, I don’t have the time to do so, and I’m skeptical it would be a benefit for the common developer interested in VR application development (and may possibly be a detriment due to adding complexity by having to fit the library into an AppState philosophy).
Yes, there will be a new BaseApplication class that is effectively just a wrapper around AppStateManager with some JME context setup that is required as part of the lifecycle around app state manager.
We may create a DemoApplication to bridge the gaps that all of the examples and tests require.
Any other additional application base classes will just be passing a preconfigured set of appstates to BaseApplication. For example, a HeadlessApplication would pass almost nothing (maybe even nothing) except any context setup necessary to support running headless. (I’m not convinced there is any yet so it may simply be extending BaseApplication is fine for headless.)
There will likely be some convenience static methods for common sets of app states… and it’s likely that a default BaseApplication constructor will call one of these.
… which is what VRApplication would be considered in jMonkeyVR, which is a separate library designed to make common VR application development simple. I’d consider that useful for jME users.
No, not yet. If you use SimpleApplication you’ll just have to “CLEAN BUILD YOUR STUFF” as paul so elegantly put it This is mainly an issue for people who despite all the warnings decided to extend Application directly. SimpleApplication will probably live on for a while even after the change is complete and be deprecated at some point but until then you can make your mind up on what switching will mean for you - probably not much, most of your application code shouldn’t be dependent on the Application class anyway. Its more like taking a different bus to work, you’ll get in somewhere else, the doors might be in a different place but as soon as you’re at work theres not much different
LegacyApplication replaces Application so that I could make Application an interface. SimpleApplication extends LegacyApplication.
As normen says, SimpleApplication will live on for a while… possibly a little longer than LegacyApplication… but either way it should remain unchanged until at least JME 3.3.
@pspeed Ok so I totally understand where you guys are going with this. Makes much sense and should make things much more flexible. Now for someone like me who has not yet started my project (hopefully soon) is there a specific way I can get away from say SimpleApplication like the tutorial uses? Maybe better phrased is there something I should go read that will give me the direction I should look at? My guess would be a custom object built around AppStates which may be the way I should go anyway considering the flexibility my application may need even though I have no clue what appstates are yet lol.
It’s my understanding that for now you should continue to use SimpleApplication and that you will not notice any changes to SimpleApplication or your classes, now or in the immediate future, it is only for people that are extending Application that there becomes a problem. Eventually something is happening to SimpleApplication but this is used by so many people that the transition should be smooth or at least documented enough at the time…
Yes, you should learn about and use app states. The less you rely on SimpleApplication-specific features the better but there is no way around it for a while.
But putting your code in app states is a good idea in general. My own SimpleApplication extending classes are generally very empty. Mostly a constructor that calls super() with a bunch of app states. My simpleInitApp() usually has a line for initializing Lemur but that’s only because a) Lemur doesn’t (yet) have an app state for that, and b) I like it initialized as early as possible… and simpleInitApp() runs before everything else.
I’m a bit late to the party but I somehow agree with @phr00t that it’s not nice to force people to make their games AppStates only. Especially new users might have a hard time following that concept. And even I have problems to put everything into AppStates. And the lack of fine control about which AppState runs first or before an other AppState is kind of problematic. My initialization routine and especially my frozen game feature will probably never be able to put into AppState. Though I see some advantages that @pspeed mentioned. But it kind of breaks the mantra of “make your game how you like it” and replaces it by “make your game how pspeed likes it”.
This is mainly an issue for people who despite all the warnings decided to extend Application directly. SimpleApplication will probably live on for a while even after the change is complete and be deprecated at some point but until then you can make your mind up on what switching will mean for you - probably not much, most of your application code shouldn’t be dependent on the Application class anyway. Its more like taking a different bus to work, you’ll get in somewhere else, the doors might be in a different place but as soon as you’re at work theres not much different 
