CODEWITHSUNDEEP
androidsingleton
tp0w3rn
tp0w3rn

Reputation: 68

Android Game Singleton or Application or neither

I'm attempting to learn the ropes of Game Development and Android and it's been a great learning experience so far, but the Android Activity Lifecycle stuff has me a little stuck.

Let's say I have three Activities -

I would think I need to load all Bitmaps and Sounds outside the Actual Game Activity to prevent from having to unload and reload them everytime onDestroy and onCreate is called, for example, like when the phone goes to sleep, or everytime a new level is chose from the level select screen.

This led me to the Singleton approach which makes sense and seems to be what I'm after, but I don't fully understand where I would need to unload the Singleton to make sure it gets GC'd, for example, could I release it in the Game Menu onDestroy, if so, how do I know if the Game Menu Activity will hang around indefinately. I've also seen mention of Android being able to kill the singleton on its own. I have also read some about using the Application Context that would give me lifecycle.

What would be the best way to approach this? Do I really want to unload and reload all the resources in the Game Activity? Am I going in the right direction with the Singleton or Application idea?

Upvotes: 0

Views: 1267

Answers (4)

methodin
methodin

Reputation: 6712

Always assume your activity will be destroyed. Assuming otherwise will always give you headaches.

Personally I've taken the approach of having my Loading and Main Game activity one in the same in the sense that while the surfaceview is being created I can overlay a loading graphic/screen on top of the surfaceview and preload all the bitmaps/sounds in onCreate.

The level select and other activities are then spawned from the main activity, typically through a startActivityForResult. This allows you to 1) Create a loading screen while preloading/instantiation takes place 2) Present a main screen with Start Game etc... 3) Have the surfaceView already created but being hidden or behind the main game activity.

Obviously you shouldn't be starting threads or anything until they start the game but the surfaceview itself can be ready to go. In that way Start Game is seamless and quick. You just hide all the other Views and bring your SurfaceView to the top.

But again, always assume your activity will be destroyed. Meaning saving game state etc...

With regards to the Main Game you should split your game into 2 threads - one for game logic and one for the actual drawing on the canvas. In your Game Activity you should override:

  • onCreate: Preload bitmaps, sounds, instantiate main game class and start game thread (UI/Canvas in addition to the game logic thread) when the Start Game button is pressed
  • onDestroy: Kill all threads
  • onPause: Pause all threads (canvas thread should be killed on surfaceDestroy)
  • onResume: resume thread

Always profile your app using the tools available. Have your application update threads and track it using the resource tracker to make sure you aren't using temporary objects. Always create such objects in your main activity/class and reference them. My app never runs GC unless I tell it to and it runs smoothly using the aforementioned design.

Hope this helps. I've written some posts with regards to Android Game development at methodin.tumblr.com.

Upvotes: 1

Bryan Denny
Bryan Denny

Reputation: 27596

You shouldn't have to worry about GC yourself. When a user leaves your app (and doesn't return for a while), the OS itself will take care of disposing the app for you.

If you're wanting to use a singleton, you can declare it at the Application level. For example an "AssetManager" is available here:

public class YourGameApplication extends Application {

    public AssetManager assetManager = new AssetManager();

    @Override
    public void onCreate() 
    {
        super.onCreate();
    }
}

You can then call it from another activity:

 YourGameApplication application = ((YourGameApplication ) this.getApplication());
 application.assetManager.someFunction();

Upvotes: 0

Cheryl Simon
Cheryl Simon

Reputation: 46844

The Application class is a place to store information that will be available for the Application lifecycle. This is a good place to put things that are used by multiple activies (global application state). This is essentially the same as using a singleton.

However, if the user leaves the application by pressing home, there is no guarantee that the Application will live on forever. If they come back 20 minutes later the app may need to get recreated.

I don't think you need to worry about things being GCed, Android will take back memory if it needs it. Otherwise, things will be released when the Application exists.

Make sure that you read the information on the Activity lifecycle closely though. If you go from GameActivity -> Level Select -> GameActivity, most likely the GameActivity will not be destroyed and recreated. Instead, it will just be stopped and restarted. This is not a guarantee, but will be true in most cases.

Upvotes: 0

xandy
xandy

Reputation: 27411

Activity's onDestroy method is not guaranteed to be called (e.g. Task killer), so don't depend on it.

If you need to presist some class across your application cycle, Singleton or reference them in Application Class is also applicable, indeed, Singleton seems makes more sense to cleaner design.

I don't think you need to explictly remove your stuff, since GC will release everything once it is not needed (at least it will once your application is killed by android). Furthermore, attaching those objects to Game Menu's lifecycle is a bad idea. I guess your activities would like:

Game Menu Activity -> Level Selection Activity -> Main Game Activity

It is sometimes possible that, while you are in "Main Game Activity", the "Game Menu" is actually destroyed. (Yeah and if you press 'back', it will switch to a newly created game menu)

Upvotes: 1

Related Questions