There is one aspect of this that can be troublesome - by default, playing an Audio Session sound will ~not~ respect the setting of the mute switch on the iPhone. In other words, if you make a call to play a sound and the silent (hardware) switch on the iPhone is set to silent, you’ll still hear the sound.

To respect the setting of the silent switch, add this code above any calls to play a sound:

// Choose a category identifier for audio sessions
UInt32 sessionCategory = kAudioSessionCategory_SoloAmbientSound;
 
// Set the session property
AudioSessionSetProperty(kAudioSessionProperty_AudioCategory,
    sizeof(sessionCategory), &sessionCategory);

There are a number of pre-defined session categories, many will have the same end result as the kAudioSessionCategory_SoloAmbientSound that I opted to use.

Here is how I came about this in my most recent app. I have a subclass of UITableViewCell that looks as follows:

@interface WeaponCell : UITableViewCell 
{
  UIImageView *image; 
  ...
}
 
...
 
// An instance of WeaponCell
WeaponCell *cell;

Prior to installing the 3.0 SDK, I would set the image as follows:

  cell.image = [UIImage imageNamed:@"weapon.png"];

However, with 3.0, the image method for UITableViewCell now states this: “Deprecated. Instead use the imageView property to get UIImageView object and then get or set the encapsulated image.”

Trouble is, you can’t simply make the appropriate code change if there’s any chance you need to build for a device that is running 2.x (or earlier). For example, I had to create an adhoc release today for someone who is running a device that has not been upgraded, and rolling back the code to pre-3.0 was not on the agenda. Here’s a much better solution:

// That's two underscores before IPHONE
#if __IPHONE_3_0
  cell.imageView.image = [UIImage imageNamed:@"weapon.png"];
#else
  cell.image = [UIImage imageNamed:@"weapon.png"];
#endif

Likewise, the font property of UIButton has been deprecated and you now are directed to use titleLabel property instead.

UIButton *backButton = [[UIButton alloc] initWithFrame:frame];
 
#if __IPHONE_3_0
  backButton.titleLabel.font = [UIFont systemFontOfSize:15.0];
#else
  backButton.font = [UIFont systemFontOfSize:15];
#endif

Deprecated methods, one of those things that you get to live with as a software developer. Good news is, there are reasonable work-arounds that make for managing this issue pretty painless.

If you interested to learn more about the app, or have an idea for something similar you would like developed, drop me a note. You can also visit 3 Sixty Software, the business end of my iPhone development.

SystemSoundID soundID;
NSString *path = [[NSBundle mainBundle]
   pathForResource:@"RapidFire" ofType:@"wav"];    
 
AudioServicesCreateSystemSoundID((CFURLRef)[NSURL fileURLWithPath:path],&soundID);
AudioServicesPlaySystemSound (soundID);

For this to work, you will need to import <AudioToolbox/AudioToolbox.h> header file, and also add the AudioToolbox.framework to your project.

For those interested in a little background information, Audio Session Services is a set of functions written in C. There are a few subtleties that give this away. Here is the definition for the AudioServicesCreateSystemSoundID function:

OSStatus AudioServicesCreateSystemSoundID (
   CFURLRef       inFileURL, 
   SystemSoundID  *outSystemSoundID);
);

The giveaway is how we call this function:

AudioServicesCreateSystemSoundID((CFURLRef)[NSURL fileURLWithPath:path],&soundID);

Notice the parameter outSystemSoundID, which is a pointer to SystemSoundID, a 32 bit unsigned integer. To pass this value as a pointer in C, you pass the address of the variable, which is done using &soundID.

More tips on Audio Session Services in the works…

In this post I will show you two ways to access the imported resources, one by specifying a path, one using an application bundle, both examples will focus on working with images. The code below is an example of building a path to a resource, avoiding a hardcoded path by using index values maintained within the application.

int modelIndex = 2, imageIndex = 5;
...
NSString *imageName = 
  [NSString stringWithFormat:@"/Model-%02d/coverflow/CoverFlow-%02d.jpg", 
   modelIndex, imageIndex];
NSLog(@"image: %@", imageName);

The output in the debug console looks as follows, notice the full path to the image:

2009-06-09 08:20:30.732 AppName[25154:20b] image: /Model-02/coverflow/CoverFlow-05.jpg

You can create a UIImageView referencing the file using the code shown below. The method imageNamed: looks for the image in the application’s main bundle if this is the first request for the image. If the image has been loaded previously, the image is retrieved from the system maintained internal cache.

UIImageView *wallpaper = 
  [[UIImageView alloc] initWithImage:[UIImage imageNamed:imageName]];

There are times when you will need to reference resources by working with the main application bundle. Following on the same theme of working with images, caching of images is not always a good idea (see the post Images and Caching for more information). In this case, using the method imageWithContentsOfFile: is a better option. However, there is one difference we need to account for when using this method, namely, imageWithContentsOfFile: loads image data from a specified path, however, it will not look in the application bundle by default.

Creating the proper path can be as simple as:

NSString *path = 
  [[NSBundle mainBundle] pathForResource:@"Splash" ofType:@"jpg" inDirectory:@""]; 
UIImageView *background = 
[[UIImageView alloc] initWithImage:[UIImage imageWithContentsOfFile:path]];

In order for imageWithContentsOfFile: to work with images imported from the file system as I demonstrated in Part 1, we need to specify the full path to the resource, here’s how that code might look:

NSString *dir = [NSString stringWithFormat:@"Model-%02d/coverflow", modelIndex];
NSString *file = [NSString stringWithFormat:@"CoverFlow-%02d", imageIndex]; 
NSString *path = [[NSBundle mainBundle] pathForResource:file
   ofType:@"jpg" inDirectory:dir];
UIImageView *wallpaper = [[UIImageView alloc] 
  initWithImage:[UIImage imageWithContentsOfFile:path]];

Working with files directly imported from the file system can be quite useful, even more so when there are many files to manage within an application. However, you will need to keep in mind how to access the resources, either through a full path or by working with an application bundle.

Although this is nice, for the most part the file structure as stored on the system is still flat. In other words, Xcode manages this information internally, it does not create corresponding folders on the file system.

In a recent application I was working with large sets of images. The question was, how to best manage all the images within Xcode such that I could leverage the inherent nature of folders and sub-folders on the file system. Let me explain a little further.

From the figure above you can get an idea of how I chose to break down the content. There was a total of 12 models, for each model there were up to 40 images in the folder /coverflow (see the image on the right), a separate folder for wallpaper images, with an image that corresponds to each coverflow image, as well as a handful of other images such a headshot, MenuButton, etc.

On the file system this is a logical breakdown of content, and if I were to use this same structure within the application I could build a path to the appropriate folder in the resource bundle using an index value to specify which folder I am after (/Model-01, /Model-02, etc). This would allow for code that can access the same files, regardless of which model the user selected, no hard-coding of file names and paths.

There were two tricks to get this to work within Xcode. The first trick is to properly import the file contents into Xcode. Here’s how you do that:

Step #1: In the project, right click (control-click) and choose Add -> Existing Files:

Step #2: Choose the folders on the file system to import:

Step #3: After clicking on Add, you will be prompted with the dialog box below. Chose to copy the files into the project as well as create the folder references in the project:

You’ll know that all is well if the folder references appear as blue folders (shown below).

The second trick was to properly reference resources within the application. This was straightforward for images that I wanted the system to cache, however it required a few extra steps for those images I didn’t want cached. More on this, and the code to make it all work, in Part II.

 #define RGB(r, g, b) 
    [UIColor colorWithRed:r/255.0 green:g/255.0 blue:b/255.0 alpha:1]
 #define RGBA(r, g, b, a) 
    [UIColor colorWithRed:r/255.0 green:g/255.0 blue:b/255.0 alpha:a]

Here’s the code without/with the macro:

 // Code without the macro
  msgLabel.textColor = 
     [UIColor colorWithRed:255/255.0 green:251/255.0 blue:204/255.0 alpha:1];
 
  // Or like this...
  msgLabel.textColor = [UIColor colorWithRed:1.0 green:.98 blue:.8 alpha:1];
 
 // Code with macro
  msgLabel.textColor = RGB(255, 251, 204);

UIColor expects its parameters to be expressed as values in the range of 0.0 to 1.0, so I pass in the color value I’m looking for between 0 and 255, and let the macro do the math for me.

Let me show you how I use the macro with the color picker application. The figure below shows a screenshot of the color picker - at this point I have selected the color I am interested in, so I choose rgb from the dropdown menu.

From here, I copy the value from the field “Hex:”, paste this into my project and finish by changing rgb to RGB.

I’ve been working with some monster projects as it relates to content. What that translates to is really long lists of files inside of Finder. Since I bounce between a handful of projects over the course of the week, more often than not I opt to open a project from by browsing the files within Finder and opening the file with the extension .xcodeproj. With folders having many files, I quickly tired of scrolling down the file list looking for the xcode project file.

To bubble the project file to the top, I simply rename the project file and place an underscore at the front of the project name. For example, SomeProject.xcodeproj becomes _SomeProject.xcodeproj. This has no effect on the project (from Xcode’s perspective), however you may need to update your source code control system with the new (renamed) file.

Trivial as it is, a hand tip none-the-less.

I’ve been working on an application which has images divided into several sub-directories:

/imageSet01/thumbnails/pic01.png
/imageSet01/thumbnails/pic02.png
…
/imageSet10/thumbnails/pic01.png
/imageSet10/thumbnails/pic02.png

In addition, for each set of thumnails there is also an image that is viewable fullscreen, this image can also be saved to the camera roll if the user opts to do so.

/imageSet10/wallpaper/pic01.png
/imageSet10/wallpaper/pic02.png
…
/imageSet10/wallpaper/pic01.png
/imageSet10/wallpaper/pic02.png

All told, there are more 12 images sets, with up to 70 images per set. In addition, I’ve integrated a coverflow viewer that allows users to view a series of thumnails images by swiping left/right. To give you an idea of the space allocated for the coverflow, each image has a texture allocated that consumes 256K. With 70 images, I’m pushing 17MB. That does not include allocating each UIImage resource (from a file) to be shown on the texture.

With all that going for me, when it came to loading images for backgrounds, creating views, data structures, etc, you can see why it was important to keep a tight reign on allocation/releasing of objects.

One concept that wasn’t apparent up front, and the primary reason for this post, is that your choice of how you allocate UIImage can make a significant impact on your memory usage. What follows is a typical line of code, found in many examples and applications, for allocating images:

UIImageView *wallpaper = [[UIImageView alloc] 
  initWithImage:[UIImage imageNamed:@"/imageSet02/wallpaper/pic02.png"]];

The good news is, the iPhone will cache this image, so if you make this same request again, the image will be loaded from an internal cache versus loading from a resource. Bad news is, the iPhone will cache this image. In my application, this subtle caching of images for the coverflow as well as the fullscreen image preview, led to a significant problem, ultimately causing the application to crash.

Here’s another means to allocate an image and avoid the system caching:

UIImageView *wallpaper = [[UIImageView alloc]
  initWithImage:[UIImage imageWithContentsOfFile:@"/imageSet02/wallpaper/pic02.png"]];

So, with that long intro it really comes down to choosing between imageWithContentsOfFile and imageNamed, depending on your whether or not you prefer to have images cached. Now mind you, all of this is documented in the API, which is the segue to the second reason for this post - read the documentation closely! Finally, if you find a code example that looks to fit the bill for your application, again, consult the docs before simply copying/pasting.

Since that time I’ve pulled together a few more macros that I use on a regular basis for printing debug information on rectangles, points and sizes. I’ve also included a means to turn debug information on/off so debug statements are not included in builds targeted as final releases.

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
// Debug
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define DEBUG_ON  // Toggle to DEBUG_OFF to hide all debug code 
 
#ifdef DEBUG_ON
  #define debug(format, ...) CFShow([NSString stringWithFormat:format, ## __VA_ARGS__]);
#else
  #define debug(format, ...) 
#endif
 
#define debugRect(rect) debug(@"%s x:%.4f, y:%.4f, w:%.4f, h%.4f", #rect,
    rect.origin.x, rect.origin.y, rect.size.width, rect.size.height)
#define debugSize(size) debug(@"%s w:%.4f, h:%.4f", #size, size.width, size.height)
#define debugPoint(point) debug(@"%s x:%.4f, y:%.4f", #pt, pt.x, pt.y)