iPhone in Action

Problems: Can't Build > Clean

This one has bugged me a few times. I go to "Build > Clean" (usually, because my copy of a program on the iPhone isn't updating its pictures) and I find that the options are both grayed out.

The answer to the problem is simple: you're running the program in question either on your simulator or on a connected iPhone. Just close down the program and you should be able to "Build > Clean" immediately thereafter.

Creating a Splash Screen: splashView 1.1

In March I created a splashView class which makes it easy to create a splash screen in your iPhone program. Since then, it's achieved a lot of attention,causing me to put together a slightly revised version of the class, along with some hopefully more straightforward instructions on how to use the class.

They follow, below.

The Code

You can download the new splashView class here: Download SplashView 1.1.

I've also put together a sample project with the splashView already in place. You can find that here: Download NavSample. It builds the splashView into the navigation template. That was chosen pretty arbitrarily; you could put the splashView into any other template, as you see fit.

Below is what you need to know about the class. Most of this, I've copied straight from my earlier article, but updated to correctly describe the usage for the current version of splashView. I'll talk about the changes a bit later.

The Methods

There are just two methods intended for external use.

initWithImage:

- (id)initWithImage:(UIImage *)screenImage;

Give the SplashView a 320x460 image that will be used to fill the screen.

startSplash

- (void)startSplash;

Once you've set all your properties, run this to start the timer of the SplashView going.

The Properties

I filled SplashView with properties, so that you can use it in whatever manner you see fit. Here's a run-down of all of the ones intended to be user accessible:

animation (enum). What sort of animation to show when the SplashView disappears. Options are SplashViewAnimationNone, SplashViewAnimationSlideLeft, and SplashViewAnimationFade. Default is SplashViewAnimationNone (no animation).

animationDelay (NSTimeInterval). How long the animation should run. Default is 1s.

delay (NSTimeInterval). How long the SplashView displays before it disappears. Default is 2s.

delegate (id). What object will listen for splashView's optional delegate protocol.

touchAllowed (BOOL). Whether a user can touch the splash screen to immediately make it disappear (or start animating away). Default is NO.

The Protocol

Sometimes you'll want to know when your splashView closes down. That's what the protocol allows. You just need to set your responding object as the splashView's delegate and have it respond to the splashViewDelegate protocol. This will give you access to one protocol method:

splashIsDone

- (void)splashIsDone;

If you want a reminder on how protocols are used, you should consult iPhone in Action p.179. If you want a reminder on how new protocols are created, you should read Create Delegate Protocols for the iPhone, an earlier article.

Using the Class

If you want to use this class in your program, you can do so under a simple Creative Commons license, which basically says that you'll leave our credits in the comments of the class. Other than that, it's free for your use.

Here's the steps to get it running:

1. Copy the splashView.h and splashView.m files into your program using "Add > Existing Files". When you do so, be sure to check the box that says to physically copy them.
2. Add the QuartzCore framework to your project.
3. Decide which file you're going to activate the splashView from. I suggest the app delegate as the most obvious location for this sort of big-picture content, but I think the splashView is now set up correctly so that you can run it from anywhere.
4. #import "splashView.h" into the appropriate file.
5. Create your 320x460 PNG. I suggest naming it Default.png. Copy it into your program using "Add > Existing Files", again being sure to check the box so that it gets physically copied.
6. Code the splashView startup.

Coding the splashView startup just requires the use of the init and startSplash methods previously noted. Here's a minimalist example:

splashView *mySplash = [[splashView alloc] initWithImage:
        [UIImage imageNamed:@"Default.png"]];
[mySplash startSplash];
[mySplash release];

For a less minimalist example, you'd set some of the properties before running startSplash. If anything isn't clear about how to put these pieces together, you should take a look at the navSample class, linked above.

About Default.png: So why did I suggest using Default.png for the filename? It's because the iPhone will automatically show a file by that name while a program is being loaded. It doesn't do any of the fancy transitions that this class does, nor does it offer any guarantees about how long it'll stay up, but other than that it could be used as a low-budget splash screen (though the purpose was actually to imply that the program was loading faster than it really was).

If you name your image Default.png, then you get the best of both worlds. The PNG will show while the program loads, then the splashView will simultaneously start with your same image, which will eventually transition out via whatever animation method you defined. If you do this, you probably want to tune down the delay once you test it out on a real iPhone, so that users don't feel like they're looking at your splash screen for tool long.

The Changes

I'm going to talk a little bit about the code here, and you might want to first read part two of my original article series, which covers the header file and part three, which covers the source code file. Not only will this give you better context for this update, but it'll also show you the techniques that were used to create the splashView, building on the information from iPhone in Action.

There were two notable changes in this version of splashView.

The first thing I did was improve how the splashView got displayed. In the original version of the program, you had to add the splashView by hand as a subview of the main window. It restricted where you could run splashView, and it also required you to do the right thing or the class wouldn't work.

You'll notice that now you don't add the splashView as a subview at all(!). Somehow, the splashView is magically added to the main window.

It's actually down in the startSplash method, right at the start:

[[[[UIApplication sharedApplication] windows] objectAtIndex:0] addSubview:self];

This takes advantage of the fact that UIApplication has a listing of all the windows, and automatically places splashView atop the first one.

The second thing I did was add the protocol. This methodology is all covered in the creating delegate protocols article I already referenced. After setting up the protocol, I referenced it from dismissSplashFinish:

if (self.delegate != NULL
  && [self.delegate respondsToSelector:@selector(splashIsDone)]) {
    [delegate splashIsDone];
}

As before, if you have questions, comments, or suggestions for improvements, please include them in the comments.

I can't at this time guarantee that the splashView works in iPhone OS 3.0, as I'm currently doing live development on 2.2.1.

Table Tricks & Tips, Part Four: Editing Tables

In some of the iPhone's default apps, you may find that you can "edit" a table, then have little red minus signs appear to the left of the table, giving you the option to delete those rows. So, how do you do that in your own programs?

The answers, it turns out, is a very simple one:

[self.tableView setEditing:YES animated:YES];

That's literally all you need to do to set up those deletion marks. Then you just need to respond to tableView:commitEditingStyle: forRowAtIndexPath:.

However, there are some nuances, particularly the questions of how you start up a table's editing and how you end it, and I'm going to show some real-world examples of those methods over the course of this article ...

An Actual Example

The program that I've showed off elsewhere in this series makes uses of a tableView's editing functionality by allowing the user to delete characters from the app, each of whom are represented by a table row

First, you need to set up some way to activate the functionality:

- (void)editCharacters {
    [self.tableView setEditing:YES animated:YES];
    UIBarButtonItem *doneButton = [[UIBarButtonItem alloc]
        initWithBarButtonSystemItem:UIBarButtonSystemItemDone
                                           target:self
                                           action:@selector(endTableEditing)];
    self.navigationItem.leftBarButtonItem = doneButton;
    [doneButton release];

    self.navigationItem.rightBarButtonItem = nil;
}

This method is triggered when a user selects an "Edit" button. You'll note that besides starting the editing, I also change around the button in my navbar. That's because when a user is editing I no longer need an "Edit" button, but instead require a "Done" button. You might alternatively set buttons' enabled properties to NO ... but in any case, you always need to give users a way to get out of editing mode.

Your tableView: method will probably delete the table item from your table and/or the data store that it originates from:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {

    if (editingStyle == UITableViewCellEditingStyleDelete) {
        [self recordWasDeleted:indexPath.row];
    }
}

For completeness state, I'll also include the method call generated when the "Done" button is clicked:

- (void)endTableEditing {
    [self.tableView setEditing:NO animated:YES];
    [self updateButtons];
}

This is pretty much the opposite of my editCharacters method: the editing is turned back off, then the buttons are returned to their original state.

And that's really all you need to do to edit a table: turn editing on, respond to the deletion message, and turn it back off at the end.

Doing More with Table Edits

You do have some other editing possibilities that I'm not going to cover in depth in this article. Most notably, you can adjust the editingStyle property of any individual cell. Apple claims it's set to UITableViewCellEditingStyleNone by default, but it sure looks to me like it's set to UITableViewCellEditingStyleDelete, which is what shows those handsome red minus marks. If you instead want to insert rows, you can set it to UITableViewCellEditingStyleInsert, and then do the appropriate thing when tableView:commitEditingStyle:forRowAtIndexPath: receives input of type insert.

That's it for me and tables for the nonce. If there's any other topics that you'd like covered regarding them, let me know in the comments. In the meantime, I'm planning to next return to my splashView topic, as some folks have requested in comments.

Table Tricks & Tips, Part 3B: ContentView & Cell Images Done Right

The advantage of writing a book is that you can go back and revamp and revise what you've already written as you go forward and learn more. I did that as I wrote iPhone in Action (which is why you'll find many handy forward and backward references throughout the book) and I've done it in most of my other major works.

When you're publishing live on the internet you don't have that same opportunity. (Or, rather you do, but if you take advantage of it by editing old pieces, you might leave people who read those pieces and moved on with the wrong impression.) So in this article I'd like to polish up some of my earlier discussions of contentView.

In Part One of this series, I offered a very simplified look at contentView, but there was the caveat that it wouldn't work if the table was refreshed (because the contentViews would get created again).

In Part Three of this series, I offered a somewhat clumsy way to keep your contentViews clean, by removing old contentViews whenever you redrew the table. It worked, but I'm certain it lacked something in efficiency.

The ContentView Done Right

So, let me offer an adjunct to those two articles by showing a clean and correct way to work with contentView:

#define topTag 1
#define botTag 2

 static NSString *CellIdentifier = @"Cell";

UILabel *topLabel;
UILabel *botLabel;

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {
    cell = [[[UITableViewCell alloc] initWithFrame:CGRectZero
        reuseIdentifier:CellIdentifier] autorelease];

    topLabel = [[UILabel alloc] initWithFrame:CGRectMake(65,0,205,35)];
    topLabel.tag = topTag;
// Other standard setup like fonts and colors
    [cell.contentView addSubview:topLabel];
    [topLabel release];

    botLabel = [[UILabel alloc] initWithFrame:CGRectMake(65,30,205,20)];
    botLabel.tag = botTag;
// Other standard setup like fonts and colors
    [cell.contentView addSubview:botLabel];
    [botLabel release];        
} else {
    topLabel = (UILabel *)[cell viewWithTag:topTag];
    botLabel = (UILabel *)[cell viewWithTag:botTag];   
}

topLabel.text = [NSString stringWithFormat:@"%@",thisName];
botLabel.text = [NSString stringWithFormat:@"%@",thisText];

cell.image = thisImage;

return cell;

Similar to my earlier methodology, this differentiates between a draw and a redraw by seeing if the cell exists. However now, instead of the inefficient destroying and recreating of subviews, this method just reuses the existing subviews by changing their text. You could similarly change images in UIImageViews, which are the other element you're likely to use in a table cell (but more on a better way to implement some of those momentarily).

The trick is finding your old subviews a second time through. This is done by tagging each subview with an integer that describes it, then running the viewWithTag: method on the cell when you return, which will identify the subview which have the tag in question.

Do not ever use or look for a "0" tag as that will identify everything that's untagged.

The Cell Image Done Right

There's one other bit of magic here: the cell's image property. This property will take the image it's passed and place it to the left of the cell. It's the easiest way to drop an image to the left of a table cell, as you often see in Apple's programs. It doesn't save a lot of effort, but it does save you the work of creating an individual subview for the image yourself.