The simplest is to subclass of UIActivityIndicatorView so you can use it like any activity indicator.

The interface file:

//  ActivityHUD.h
#import <UIKit/UIKit.h>

@interface ActivityHUD : UIActivityIndicatorView
- (ActivityHUD *)initInView:(UIView *)view;
@end

And the implementation file:

//  ActivityHUD.m
#import "ActivityHUD.h"
#import <QuartzCore/QuartzCore.h>

@implementation ActivityHUD

- (ActivityHUD *)initInView:(UIView *)view
{
    self = [super initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
    if (self) {
        // add background view
        CGFloat border = self.bounds.size.height / 2;
        CGRect hudFrame = CGRectInset(self.bounds, -border, -border);
        UIView *hud = [[UIView alloc] initWithFrame:hudFrame];
        hud.backgroundColor = [UIColor colorWithRed:0 green:0 blue:0 alpha:0.67];
        hud.layer.cornerRadius = border;
        [self addSubview:hud];
        [self sendSubviewToBack:hud];

        // center in parent view
        [view addSubview:self];
        self.center = [self convertPoint:view.center fromView:view];
    }
    return self;
}

@end

To use, init the ActivityHUD in a view, and later call startAnimating to show it, and stopAnimating to hide.

This is something I learned on my first programming job (eons ago…) and found useful but underused.

Useful for what? To solve the persistent tension between the robustness of single-exit point and the complexity of using extra state variables and state checking code.

Let me show you what I mean.

Say you write a function that needs to return an element matching some spec or create a new one. There are two ways to code this.

The simple yet multi-exit way:

Element *matchingElement()
{
    for (Element *e  in collection) {
        if ( isMatching(e) ) {
            // some important code
            return e; // first exit point
        }
    }
    return newElement(); // second exit point
}

The single-exit way:

Element *matchingElement()
{
    bool foundMatch = false;
    Element *e = getFirstElement();
    while (e != nil && !foundMatch)
        if ( isMatching(e) ) {
            // some important code
            foundMatch = true; // setting state variable
        }
        e = nextElement();
    }
    return foundMatch ? e : newElement(); // single exit point from function
}

Now some of you are wondering why bother with foundMatch; you need to go read Tom Dalling’s Coding Tip explaining the problems with multiple exit points.
Others shudder to see a return statement in the middle of the function; you should remember that more variables mean more code mean more bugs.

So how does the three underscores idiom solve this conundrum? It goes hand in hand with the common convention of 4-space indentation. Together, they allow you to write this:

Element *matchingElement()
{
    for (Element *e  in collection) {
        if (isMatching(e) ) {
            // some important code
___ ___ ___ return e;
        }
    }
___ return newElement();
}

And suddenly both exit points become clear and visible and not so prone to bugs.

The three underscores idiom should be used not only for return statements, but for any jump in the flow of control, like break or continue in a loop:

Element *matchingElement()
{
    for (Element *e  in collection) {
        if ( notEvenClose(e) ) {
    ___ ___ continue;
        }
        if ( isMatching(e) ) {
            // some important code
___ ___ ___ return e;
        }
    } while ( e = nextElement() );
___ return newElement();
}

For example: Calling a contact. If the contact has just one phone number, you openURL with it and you’re done. But if she has several numbers, you want to open a UIActionSheet to let the user choose which number to call.

Or picking an image. If you’re running on a camera-less iPod, you just show a UIImagePickerController to pick from the photo library. But with a camera, and maybe an existing image to delete, you’ll want to show an action sheet to choose the actual action that your “Photo” button performs.

So you need to do two things:

1. Decide whether to show an action sheet at all or just do the one possible action.
2. If you need an action sheet, fill it dynamically with the possible targets for action.

The code to do that doesn’t have to be complicated. It can actually be as simple as this:

@interface MyViewController() : <UIActionSheetDelegate> {
	NSArray *possibleTargets; // action sheet buttons go here
}
@end

@implementation MyViewControllerMyViewController

- (IBAction)selectTargetForAction:(id)sender
{
    possibleTargets = SomeWayToFindPossibleTargets();

    if ([possibleTargets count] == 1) {
        // just call the one number, or show the one image picker
        [self doAction:[possibleTargets lastObject]];
    }
    else if ([possibleTargets count] > 1) {
        // show a dynamically filled action sheet
        UIActionSheet *targetsSheet =
            [[UIActionSheet alloc] initWithTitle:__(@"Select")
                delegate:self
                cancelButtonTitle:nil // since we want it last
                destructiveButtonTitle:nil
                otherButtonTitles:nil]; // since we can't hard-code them
        for (NSString *target in possibleTargets) {
            [targetsSheet addButtonWithTitle:__(target.title)];
        }
        targetsSheet.cancelButtonIndex = [targetsSheet addButtonWithTitle:__(@"Cancel")];
        [targetsSheet showInView:self.view];
    }
}

- (void)actionSheet:(UIActionSheet *)actionSheet clickedButtonAtIndex:(NSInteger)buttonIndex
{
    if (buttonIndex != actionSheet.cancelButtonIndex) {
        [self doAction:[possibleTargets objectAtIndex:buttonIndex]];
    }
}

@end

Notes:

1. The @interface code above is part of the .m file, as described in my earlier post How to Keep Your Protocols Private.
2. If you’re puzzled by the meaning of __(@"String") then see my earlier post on How To Make NSLocalizedString Fun To Use.
3. The objects in possibleTargets can hold a selector (SEL) of the actual method to be executed, or they can hold just relevant data for the action (like a phone number to call).

Coding reordering requires implementing methods from both of the two entangled protocols UITableViewDataSource and UITableViewDelegate.

In UITableViewDataSource we have the methods:
tableView:commitEditingStyle:forRowAtIndexPath: (for insert and delete)
tableView:canMoveRowAtIndexPath: (for reorder)
tableView:moveRowAtIndexPath:toIndexPath: (for reorder)

And in UITableViewDelegate:
tableView:editingStyleForRowAtIndexPath: (for insert and delete)
tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath: (for reorder)

The UITableViewDelegate methods are not strictly necessary in the simplest case where all rows are deletable, no row is insertable, and all rows are reorderable. In fact, in this simplest case you don’t need canMoveRowAtIndexPath either, only this:

- (void)tableView:(UITableView *)tableView
    moveRowAtIndexPath:(NSIndexPath *)fromIndexPath
    toIndexPath:(NSIndexPath *)toIndexPath
{
    // Update the model with the change.
    // The view updates are already handled by UIKit.
}

But of course, if the last row (or the row past last) is an insert row, and is not reorderable, than you need to implement the other methods as well. You can get the code for that (along with the inline editable UITextField-s) at GitHub: http://github.com/yonat/EditableList.

Thankfully, you can do that in your .m implementation file instead. (Even though Apple sample code doesn’t.) All you need to do is use the empty category:

// MyViewController.m
#import "MyViewController.h"
#import <MessageUI/MessageUI.h>

@interface MyViewController ()
    <MFMailComposeViewControllerDelegate> // privately conform to protocol
@property (nonatomic, strong) UIView *somePrivateSubview;
@end

@implementation MyViewController
// synthesize and methods implementations
@end

The empty category MyViewController () allows you to define private ivars, properties, methods, and even protocols – all in the privacy of your .m file, transparent to your clients.

The basic badge is a UILabel whose underlying CALayer has a backgroundColor and cornerRadius:

#import <QuartzCore/QuartzCore.h> // don't forget!
// ...
UILabel *badge = [[UILabel alloc] init];
badge.layer.backgroundColor = [UIColor blueColor].CGColor;
badge.layer.cornerRadius = badge.bounds.size.height / 2;

Basically, that’s it. There are some adjustments needed to make sure the label leaves enough space around the text for the rounded corners, but that’s easily done with short overrides of textRectForBounds and drawTextInRect.

The nice thing is how easy it is to make app-icon style badges, with border, shadow and gloss:

• For border simply set the layer’s borderColor and borderWidth.
• For shadow set the layer’s shadowOpacity, shadowColor and shadowOffset.
• For gloss add a CAGradientLayer sublayer.

It’s that simple. And even better: animatable!

You can get the code, along with a Mail.app style BadgeTableViewCell and a demo app, at GitHub: http://github.com/yonat/BadgeLabel

#import "UIView+RenderUIImage.h"
#import <QuartzCore/QuartzCore.h>

@implementation UIView (RenderUIImage)

- (UIImage *)renderAsImage
{
    // setup context
    UIGraphicsBeginImageContextWithOptions(self.bounds.size, NO, 0.0f); // use same scale factor as device
    CGContextRef c = UIGraphicsGetCurrentContext();

    // render view
    [self.layer renderInContext:c];

    // get reslting image
    UIImage *result = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
    return result;
}

@end

Just remember to link the QuartzCore.framework and you’re good to go.

I mean, any sane programmer will get a headache from replacing a simple @"Great!" with this:

NSLocalizedStringFromTable(@"Great!", @"Messages", nil)

So I took a leaf from WordPress, and shortened the calls:

#define __(str) NSLocalizedStringFromTable(str, @"Messages", nil)
#define __d(str, description) NSLocalizedStringFromTable(str, @"Messages", description)

Now localization is easy and fun: I simply type

__(@"Great!")

and the localization code is taken care of by the C pre-processor. Mission accomplished.

What you need to do is set the attribute type to Transformable, and the the transformable name to NSUnarchiveFromDataTransformerName.

That’s it!

Now can set UIImage objects directly into your NSManagedObject objects:

person.thumbnailImage = [UIImage imageNamed:@"defaultPortrait"];
anImageView.image = person.thumbnailImage;