@toolforger said:
Ah. I guess that would be a point for keeping the initialization code in a start() override anyway.
Not that I plan on using Applets (not popular anymore, because, eww security holes) or Android (not on my radar yet), but it's something to keep in mind for writing tutorial code and best practices texts.
But all of the initialization code you’ve provided so far has been desktop specific. So that would point to keeping the initialization code “out of” start() not in it. It’s a “bad practice” in general because of this.
@toolforger said:
Well, why is putting stuff into start() a bad practice?
Considering I would need to do that for Android anyway, in particular?
Well, you haven’t shown an example of anything you would need to do for android. Everything you had in start so far was pretty much desktop specific, really. So I guess I would have to see a valid example first that couldn’t be done in simpleInitApp().
@toolforger said:
Well, the example would be "what if I need to port this to Android?"
And "what if I wrote tutorial code that people might want to use in Android"?
But the “things you’ve shown that you included in start() so far” have been “completely useless on android”.
We appear to be talking past each other. The idea is that you would show me an example of what to put in start() that is not desktop specific. It does no good to write a tutorial for Android and override start just to put desktop specific stuff there.
main() - setup desktop specific stuff.
start() - do not do desktop specific stuff… which I can’t think of what to put here because I’ve never had a use-case for putting things in start(). And apparently you can’t think of any either or I think it would be answered five posts ago.
Ah okay, now I understand.
Agreed - desktop-specific stuff shouldn’t go to start().
Is Android stuff always fullscreen? Does Android even have Swing?
Dunno whether anything really belongs to start(). It’s certainly needed by JME so it wouldn’t be there, and there might be a use case where that’s the right slot to initialize other stuff as well.
Personally, I have a dislike for putting anything but a constructor inside main(), because stuff in main() tends to be harder to refactor because of the oh-so-easy accessibility of globals from there. It’s not a big deal from my perspective though, JME has a tendency to use globals anyway (is it even possible to have more than one Display at a time? DesktopSystem is so singleton-heavy… not that I currently need multiple Displays right now, just wondering.)
@toolforger said:
Ah okay, now I understand.
Agreed - desktop-specific stuff shouldn't go to start().
Is Android stuff always fullscreen? Does Android even have Swing?
Dunno whether anything really belongs to start(). It’s certainly needed by JME so it wouldn’t be there, and there might be a use case where that’s the right slot to initialize other stuff as well.
Personally, I have a dislike for putting anything but a constructor inside main(), because stuff in main() tends to be harder to refactor because of the oh-so-easy accessibility of globals from there. It’s not a big deal from my perspective though, JME has a tendency to use globals anyway (is it even possible to have more than one Display at a time? DesktopSystem is so singleton-heavy… not that I currently need multiple Displays right now, just wondering.)
Android doesn’t even have AWT.
It makes total sense to me to setup the desktop-related settings in main()… they are “stack variables”, after all.
Just like it makes total sense to me to setup the android-specific stuff in the android harness… and so on.
jME3 provides entry points for all platforms. main() for desktop, onCreate() for Android, and Applet.start() for applets. There’s no need to override Application.start().
