Regardless of issues with SurfaceView, you really should pause your game when it is paused and/or loses focus, and don't resume again until the user deliberately does so. They may have put their device to sleep, gone to bed, got up the next morning, unlocked the phone, and there is your game. It is really best at this point to be paused AND SILENT, to avoid them getting a big unpleasant surprise. (Imagine unlocking your device in a meeting and you last left it playing some game... oops!)
On Wed, Nov 25, 2009 at 9:36 PM, String <[email protected]>wrote: > On Nov 25, 12:55 pm, David Given <[email protected]> wrote: > > > Press HANGUP to turn screen off -> > > onPause() > > surfaceDestroyed() > > > > Press HANGUP again to screen on, going to the screen lock page -> > > onResume() > > > > Deactivate screen lock, switch back to game -> > > nothing! > > > > Not only am I not informed that my application has become visible again, > > In doing a bit of testing, I'm seeing exactly the same thing in this > regard - my onResume handler gets called when the screen turns back > on, NOT when the lock screen goes away. That's completely at odds with > all other circumstances I've ever seen, where onPause gets called when > ANYTHING comes in front of my activity, and onResume doesn't get > called until my activity comes back to the top of the stack. It's like > the lock screen isn't on the usual activity stack. > > And yeah, that's kind of rough for a highly interactive app like a > game. Most apps (including mine) will wait patiently until the user > interacts with them, so it's no problem that onResume gets called well > before the user can actually see the activity. But for a game, where > often the whole idea is that it's doing stuff on its own initiative, > that is a problem. What I've seen other games do (but never understood > until now) is to create your own "pause mode", activated in onPause, > and not deactivated until the user hits an on-screen "Resume" button. > > > but I'm never informed that my surface has been created so I can start > > drawing on it again! > > Now, that is different from what I'm seeing, although I don't have > exactly the same situation. My OpenGL app doesn't use a SurfaceHolder, > but instead subclasses GLSurfaceView.Renderer like this: > > public class MyRenderer implements GLSurfaceView.Renderer { > MyRenderer (Bitmap initMapImage, int initOrientation, Context > context) { > // constructor code > } > > public void onSurfaceCreated(GL10 gl, EGLConfig config) { > // startup code > } > > // more code > } > > With this architecture, I do indeed get the onSurfaceCreated call when > the phone wakes up from sleep. Might you be able to rearchitect your > OpenGL code like this? > > Interestingly, what I don't get with my approach is an > onSurfaceDestroyed when the phone is going into sleep. It's not a > problem for me, but it is something to be aware of. > > String > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
