Multitasking and cleaning up after myself o_O

Posts: 2
Joined: 2010.10
Post: #1
Heya, long-time-lurker-first-time-poster here Wink I would've liked my first post to be showing off a completed project - but that's not to be CryWink

So - as part of a college class I'm modifying the GLSprite example, transforming it into a shoot 'em up; I've completed _that_ part of the class without any problem Wow but now I have a couple of questions:

1. Could anybody point me to documentation describing what I have to do to make my game "multitasking aware"? I don't want the game to perform any processing in the background, I just want the user to be able to switch to another app and then back to my game, with the game not needing to load everything again Bored and with the enemies etc in the same place as when the player left the game.

2. I put my clean-up code into EAGLView's "dealloc" method, but it looks like that method is never invoked - I've sprinkled that method with "NSLog" and "fprintf( stderr", but nothing is ever printed to the console; where should I put my clean-up code so that it is invoked when my game exits? Should it be in the "dealloc" method of GLSpriteAppDelegate?

Sorry for the n00b questions - I'm good at C++ but I feel like I'm stumbling around in the dark when it comes to Objective-C Blush
Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #2
1) It's multi-tasking aware by default on >= iOS 4. See: Help->Developer Documentation->iOS 4.x Library->Required Reading->iOS Application Programming Guide

Then, in the iOS Programming Guide, see: The Core Application Design->Multitasking.

That explains everything pretty well right there.

2) Don't bother. At app exit, the app gets kicked out of memory and all associated stuff is disposed of for you.

The only things you should ever care about are views that might move into a state of not being visible, in which case the OS might remove that view after a memory warning and you need to know about it. Generally speaking though, if you're just doing one OpenGL view for a game and that's the main view the whole time, you have nothing to worry about. You can make sure things work as you might expect by simulating a memory warning in the iPhone Simulator.
Quote this message in a reply
Posts: 27
Joined: 2009.07
Post: #3
Don't bother? That's a horrible suggestion, Jake. While it may kick everything out of memory and clean things up for you, relying on that mechanism is bad form and an especially poor habit to get into. Who is to say that apps will always exit the same way in future iterations of iOS and, more pressingly, how do you learn to properly manage memory? If you leave such habits in place, it's going to be harder to learn to clean up when you begin to develop on other platforms, not to mention the difficulties it creates in tracking down memory leaks. When it comes to games, managing memory and manually freeing memory that you've allocated is incredibly important, particularly in a system like Objective-C that uses, primarily, the heap in place of the stack for storing application data. Whether you're using C, Obj-C, or C++ (or by extension, Obj-C++), pointers are messy things to leave around without ensuring that they are freed.

As far as your question goes, Shyguy, I'm sorry, but I have no real answer for you. I'm kind of in the same boat, trying to work with Objective-C after coming on ten years of using C++.

Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #4
(Oct 24, 2010 09:19 AM)Minalien Wrote:  Don't bother? That's a horrible suggestion, Jake.

Not really. The OS cleans up OS resources and reclaims all memory from your app when you quit. In fact, I could argue that it is a better user experience because it is quicker to let the OS dump you out rather than you meticulously iterating over all your fancy objects and data structures. There simply is no need, unless you have network connections that need to be closed first.

In all fairness to your point of view though, it's not like everybody agrees on this:

I used to really pay attention to cleanup details back in the day, but after I realized it was programming for no purpose whatsoever, other than being "proper", I stopped wasting my time on it. Suit yourself. Wink

[adding] "and, more pressingly, how do you learn to properly manage memory?"

On the contrary, if you know when you don't need to clean something up, then you probably have a better grasp on memory management than someone who doesn't know whether they should clean up or not.

As far as leaks, I have very strict procedures that I use for managing memory. We're talking about what has to be done for cleanup on app exit, not normal execution. Outside of memory management techniques, there are also tools to help you detect and track down memory leaks, but that, I do not believe is particularly germane to the topic, since there is no such thing as a leak when the app is terminated.
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #5
You SHOULD let the OS clean up after you (at least on iOS, MacOSX, Windows, Linux -- I have no experience with PS3, Wii, XBox 360, but I assume they also clean up for you).

a) it will do at least as good a job as you
b) it will do it vastly faster than you
c) it runs no risk of crashing and annoying the user while doing so. Cleanup code is *hard*.

User says quit? Call exit() and GTHO as fast as possible.

You should also avoid using C++ objects with static destructors for similar reasons.

Don't believe me? look:!/ID_AA_Carmack/status/27156685816 Rasp
Quote this message in a reply
Posts: 1,487
Joined: 2002.09
Post: #6
I'd agree with Another Jake. It's a waste of valuable development time to clean up things that you are going to need until the app exits anyway. A modern OS really has to be able to clean up after and recover from a crashed process. Given that it does it, you might as well just use it to your advantage. It's the pragmatic thing to do. If you are going out of your way writing code that effectively does nothing, then it's just a waste of time, yours the user's, and the CPU's.

For our game Twilight Golf, we took pragmatism a bit farther. There are always a few objects in each level that we ended up just leaking (on purpose) because the effort of releasing them properly would have been a bunch of tedious work creating ivars to hold the references until we wanted to dump them. If you play the game for an hour, you will probably leak ~100KB of RAM. This saved hours and hours of work, and no user will ever notice or care that the game leaks less than 0.1% of their RAM. I'm not going to claim that this was clever, but it was pragmatic.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Posts: 337
Joined: 2002.04
Post: #7
For multitasking awareness, one thing you can add if you want is to respond to applicationWillResignActive and aplicationDidBecomeActive in your app delegate. If an app does any OpenGL calls when it's sent to the background it will automatically be closed by the OS, so next time your player tries to launch it, it will have to go through its entire loading sequence from scratch.

If you have the applicationWillResignActive:(UIApplication *)application method in place and use it to switch off your rendering (essentially stick your game in pause mode, doing as little as possible) it won't be killed by the OS when it's switched to the background and re-enabling itself on the applicationDidBecomeActive:(UIApplication *)application will let it instantly carry on where it left off.

It's also worth saving the game settings on resigning active just in case the device gets fully powered down or reset while you're in the background.

Also, what OneSadCookie said as far as cleanup code Smile
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  iPod Touch not multitasking not working??? Toontingy 1 5,404 Jun 24, 2010 04:13 PM
Last Post: sealfin