I've run into an organizational problem with an application I am working on, on the Android platform. The application uses sensors as input and OpenGL as output.
- The traditional method is something like organizing the project into an MVC where I have the main activity class load an OpenGL view and a sensor handling class and will then probably register some callbacks or possibly do it on a clock.
- The开发者_运维知识库 sloppy alternative is having a single class that implements GLSurfaceView and SensorEventListener and then offload the logic into other classes.
Assume very simple drawing code and somewhat complex control system code that will attempt to refresh at 60ish Hz. I am looking for performance, maintainability and easy of development implications, so any and all input is valuable. Also I am a complete novice when it comes to Android or mobile development so if you can show me the light with a third alternative that'd be great too.
Sometimes, over-planning things can be a waste of time.
Different games use different approaches, you'll want to take a look at the replica island's dev blog and code for various hints on how to organize your code using a GLSurfaceView. http://replicaisland.net/
I use your latter approach, but it's not as sloppy as you make it seem. You don't really need any logic code in your GLSurfaceView, just calls to your classes when certain events happen. (onDraw, onTouch, onKey, etc)
Not sure what's sloppy about this, I maintain my logic in their proper classes. For example, in my onDrawFrame() I simply do MyAreaManager.draw(gl)
The MyAreaManager class would maintain it's own logic and know what to draw.
As for the clock, you'll most likely want two threads. One for rendering (the GLSurfaceView thread) and one for game logic that runs at a certain logic frame rate.
The logic frame, would simply change the state of the canvas objects and the draw frame would simply draw them as fast as possible.
This way you render as fast as possible and still maintain a steady logic frame rate.
精彩评论