My iPhone Adventure

Orignal File Size: 24,085 bytes

pngout: 21,709 (9.8% reduction)

PNGOUTwin: 22,110   (8.2% reduction) 21,970 (8.8% reduction)

pngcrush: 23,392 (2.8% reduction)

deflopt: 24,051 (0.1 % reduction)

iPhone SDK Tutorial: Drawing a Dynamic Pie Chart, part 2 of 2
This is the second of a two part basic xcode iPhone SDK tutorial in which I demonstrate the use of the quartz2d api to draw a pie chart which is dynamically drawn based on the weight of two sliders’ values.

If you find this video helpful please return the favor by checking out my new app in the app store: Robodamus – Robotic Fortune Teller.  It’s only .99 right now!  Ok, enough self promotion….

iPhone SDK Tutorial: Drawing a Dynamic Pie Chart, part 1 of 2
This is the first of a two part basic xcode iPhone SDK tutorial in which I demonstrate the use of the quartz2d api to draw a pie chart which is dynamically drawn based on the weight of two sliders’ values.

This video is the second (and final) part of a video tutorial which demonstrates my method for playing caf files with the iPhone SDK’s AVAudioPlayer. Part 2 of 2.

This video demonstrates my method for playing caf files with the iPhone SDK’s AVAudioPlayer. Part 1 of 2.

This is a video tutorial version of an earlier post. This video demonstrates my method for creating caf files for use with the iPhone SDK’s AVAudioPlayer.

After updating my iPhone to OS 3.0.1 I discovered that I could not run code on it.  Apple’s advisory PDF instructs people to use the following command in the terminal (assuming xcode is installed to the typical location).

ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0\ \(7A341\) /Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1

It worked for me

I’m probably not the only one to learn this the hard way, but simply changing the extension of a file from “aiff” to “caf” does not actually produce a proper “caf” file.  You’ll find numerous posts claiming that you can do such a thing, but trust me, you’ll leak like a sieve. Sure, it’ll play just fine, but it’ll create a memory leak when playing said file with the AVAudioPlayer in your iPhone project on both the hardware and the simulator.

My new leak-free process for creating sounds is as such:

1. I typically record through garageband (because it is free), and then edit the sound in audacity (also free).  I export the sound as a wav file from each app.

2. Convert the wav to a caf by opening the terminal and typing:

afconvert -f caff -d LEI16@11025 infile.wav outfile.caf

and adjusting the value after LEI16@ up or down to balance sound quality and file size.

3. I then drag the “caf” files produced from the step above to the appropriate group/folder in my xcode project with the “Copy items into destination group’s folder” option checked (just my personal preference on copying the files).

Really, only step 2 is worth noting.

A simple class whose purpose was to play sounds might be defined in the following manner:

@interface AVSoundPlayer : NSObject <AVAudioPlayerDelegate> {
  AVAudioPlayer *msoundPlayer;
}
@property (nonatomic, retain) AVAudioPlayer *msoundPlayer;
-(id)initWithCafFile: (NSString *)inString;
-(void) playNum:(int)num;
@end

Code to implement the class defined above would look like the following:

@implementation AVSoundPlayer
@synthesize msoundPlayer;

-(id)initWithCafFile: (NSString *)fileName{
  if (self = [super init]){
    NSBundle *mainBundle = [NSBundle mainBundle];
    NSError *error;
    NSURL *sURL = [NSURL fileURLWithPath:[mainBundle
                       pathForResource:fileName ofType:@"caf"]];
    self.msoundPlayer = [[AVAudioPlayer alloc]
                        initWithContentsOfURL:sURL error:&error];
    if (!self.msoundPlayer) {
      NSLog(@"Sound player problem: %@", [error localizedDescription]);
    }
  }
  return self;
}

-(void) playNum:(int)num{
  self.msoundPlayer.numberOfLoops = num;
  [self.msoundPlayer prepareToPlay];
  AVAudioPlayer *tmpPlayer = self.msoundPlayer;
  [tmpPlayer play];
}

- (void)dealloc {
  [self.msoundPlayer release];
  [super dealloc];
}
@end

So, I have come to the (obvious) realization that there are memory limiations of the iphone.  I know; shocking!  I first noticed that the art resources for my first stab at integrating animation with user actions were adding up quick…really quick.  When I had finished rendering all of my images, I had a total of over 40 MB worth of images!  I guess I hadn’t really put much thought into what sizes and color depths I needed, as I was not really at that stage where I was planning that part of the project. However, it has become apparent that I need to be aware of the device’s limitations as I get ready to design and render the actual artwork.

So anyways, here is what I found by reading around the internet:

1) There is no guarantee of how much memory you will have available for use.  This could be a major headache.  I’m not sure how to approach this issue yet, but I will have to keep this in mind.  Less than 12 MB is supposedly a safe place to be, and under 20 MB is fairly safe.  I, of course, don’t know how accurate those numbers are, but they seem relatively reasonable.

2) If an app is over 10mb it’ll force potential customers to be connected to a wifi network before they can download it.  I’m not confident I can stay under that, due to the graphical nature of my app, but we’ll see as I get farther along.

From my own quick experiments I’ve found that cutting the color depth from 64bit to 32bit can reduce the size of the png files by over 43% (though, strangely not 50%).  Reducing the size, obviously, helps as well.

Another thing I’ll probably end up doing is running my animations at 15 fps versus 30. That’ll cut my size in half.  I haven’t yet experimented much with frame rates, so hopefully 15 will look acceptable.

BTW, http://gamesfromwithin.com/?p=428 has a great blog post/discussion about memory concerns with regard to iphone development; much more educational that this one