Apps Prevent App From Being Destroyed

[Scottmc]

I am porting a complex BREW application (which was in turn ported from J2ME) and I ran into a problem as soon as I went from emulator to device (as is always the case right?). My issue is that when the user changes orientation of the phone it will cause my activity to be destroyed, and my onCreate function to be called. This is a game so the state information is fairly complex with multiple collections of objects. My first naive approach was to create a state object to include the entire game state. I then return that object via onRetainNonConfigurationInstance. I grab it again in onCreate. While this works, it's non-optimal that I have to be shuttling around my entire game state. Is there any way to avoid that? Do any other game developers have techniques to work around that? It really seems like the Android was more geared toward RIA mobile applications then game development, unlike J2ME and BREW which basically caters to the game developers.

 

[jonbonazza]

That is how the activity life cycle works an thus why in most games the orientation is locked. if your application isn't too complex, you can store the important data in a file or shared preferences and then load it in the onCreate() method, thus filling all of the data everytime the orientation is changed.

 

[Scottmc]

That is how the activity life cycle works an thus why in most games the orientation is locked. if your application isn't too complex, you can store the important data in a file or shared preferences and then load it in the onCreate() method, thus filling all of the data everytime the orientation is changed.

Hmm, maybe I'll look into locking the orientation then. That actually fits the game model better and would simplify my development greatly. I was just dreading writing the code to support switching of orientation The problem with the application is that it connects to a game server for lobby and game match up functionality. I would have to save the server object at the very least as that holds the socket connection and state information for the remote connection. That's all before even starting the game. Once the game is in progress the state becomes even more complex.

I think the orientation locking is the way to go.

 

[id0001]

Whenever your phone goes to sleep mode or when the screen orientation changes, you activity gets destroyed and recreated. The only thing that always remains active during your app's lifecycle is the app's Application class.
So if you want to preserve some objects you created in your activity you would have to move those objects to a custom Application class (which inherits from Application). Of course you have to re

 

[jonbonazza]

Whenever your phone goes to sleep mode or when the screen orientation changes, you activity gets destroyed and recreated. The only thing that always remains active during your app's lifecycle is the app's Application class.
So if you want to preserve some objects you created in your activity you would have to move those objects to a custom Application class (which inherits from Application). Of course you have to re

 

[id0001]

only locking your orientation won't solve the problem because when the player presses the power button to make the phone go in sleep mode, it destroys your activity.

 

[jonbonazza]

only locking your orientation won't solve the problem because when the player presses the power button to make the phone go in sleep mode, it destroys your activity.

This is true. I have been thinking for some reason this is a game and people wouldn't really have any need to shut the screen off while the game was i progress, however now that you made me re-realize that this is an app, not a game, I can see your point. A new subclass of the Application class would be your best bet.

 

[Scottmc]

This is true. I have been thinking for some reason this is a game and people wouldn't really have any need to shut the screen off while the game was i progress, however now that you made me re-realize that this is an app, not a game, I can see your point. A new subclass of the Application class would be your best bet.

Well this is a game, but I think I know what you mean about it being an App. Since everything in android is an application and they really limit your sandbox to that application (as opossed to BREW which let's you almost brick your phone - and bad implementations of BREW did brick many early kx-12s ).

I was able to get the orientation locking in place. I do realize I still have to be aware of the application lifecycle but I can change game states when that happens. I can go to a pause state which will force the user to unpause when she decides to reactivate the phone. I will still have to save state in that case but I can utilize the pause code I would write anyway for saving game state. My biggest worry was the aspect change. This is a 2D tile based game and my maps are laid out assuming a particular orientation. Now that I know how to force the orientation in the activity manifest file I can force the game to always run in landscape mode and do the normal state saving when the game is paused. That way the phone being turned off, memory being freed by the OS, or any of the other ways your app can be destroyed outside of it's control will all just be handled by the generic pause and unpause code.

Thanks everyone for all the great ideas

 

[cp1]

You can also avoid the destruction and recreation of your activity by adding keyboardHidden to configChanges in your manifest. Then instead of destroying and creating your activity it will call onConfigurationCHanged instead.

 

[Scottmc]

You can also avoid the destruction and recreation of your activity by adding keyboardHidden to configChanges in your manifest. Then instead of destroying and creating your activity it will call onConfigurationCHanged instead.

Got that too - thanks!

I also read somewhere that you can force your application no never die. What I read said you do this unless absolutely necessary since the os can't recycle your application if memory get's low or the device want's to go to standby. I'm trying to find some precedent with games right now to see if that is a viable approach. Otherwise I'll just stick with my implementation of onRetainNonConfigurationInstance and the subsequent state restoration code I have.