How to approach a common xib or controls across multiple view controllers?

I have an animated character coexisting with other conventional controls in an xib. All works well. No issues there. The animation is done through UIImageView image flipping. An animation engine (state machine) triggered by a timer runs the show. The character uses six UIImageViews to render the different portions of the character that need to be animated.

Now I am looking at the possibility of the app getting more complex by adding a few more UIViewControllers (and their xib's). As you may have guessed, my character would have to exist in any xib that slides on top of the prior one.

What might be the best approach to implementing this? I suppose I could copy-paste the UIImageView's and instantiate a new animation engine (or pass a pointer) to each new xib.

I many ways what I need is for a new xib to only cover 2/3 of the prior xib and that would do it, but I am not sure that this works. Not sure about events and how they'd work with two overlapping xib's (if it's even possible).

While I experiment I thought I'd ask and see if anyone who has been here before might have an interesting approach or two to share.

Your question seems to be about ownership and not about animation. Try isolating the character into its own xib, (say Character.xib) and creating a CharacterLoader class. The CharacterLoader class would have a property of character and look something like:

CharacterLoader.h

@interface CharacterLoader : NSObject {
}

@property(nonatomic, retain) IBOutlet Character *character;

+ (Character *)loadCharacter;

@end

CharacterLoader.m

...

+ (Character *)loadCharacter {
    CharacterLoader *loader = [[CharacterLoader alloc] init];
    [[NSBundle mainBundle] loadNibNamed:@"Character" owner:loader options:nil];
    Character *character = [loader.character autorelease];
    [loader release];
    return character;
 }

 ...

If you find yourself making a lot of these loader classes, you can roll them into a single class whose role is to basically load nibs programmatically like this. Another alternative would be to just create the Character and all other shared content programmatically, but that's probably not desirable for you since you intentionally are approaching it by using nibs.

In the interest of closing the loop, this is what I ended-up doing:

I created a UIViewController subclass with a nib file. Called it "AnimatedCharacter".

"AnimatedCharacter.xib" consists of all of the elements required to create the character. It has a range of controls connected to IBOutlets and IBActions driven from "AnimatedCharacter.m". In my case "AnimatedCharacter.m" creates an NSTimer that fires-off a state machine at regular intervals to decide what to do with the character. It also implements audio playback through standard means.

Other than that there's nothing special about these files/code. In other words, I did not do anything out of the ordinary to prepare them for insertion into another UIViewController.

In the main view controller .h file:

#import "AnimatedCharacter.h"

...

AnimatedCharacter *character;

...

@property (nonatomic, retain) AnimatedCharacter *character;

Then, in the main view controller's .m file:

@synthesize character;

...

- (void)viewDidLoad 
{
character = [[AnimatedCharacter alloc] init];
character.view.frame = CGRectMake(54.0, 0.0, 150.0, 150.0);
[self.view addSubview:character.view];

...

With that in place I can now do things like:

-(void)FadeOut:(SEL)selector
{
[UIView beginAnimations:@"resize" context:NULL];

    [UIView setAnimationDuration:0.5];
    [UIView setAnimationDelegate:self];
    [UIView setAnimationDidStopSelector:selector];

    character.view.frame    = CGRectMake(0.0, 0.0, 50.0, 50.0);

[UIView commitAnimations];
}

And, generally control the character as I see fit through the various member functions in "AnimatedCharacter.m". This is effectively working as a nib within a nib. Not separate threads, but both nibs are discharging their duties as expected, receiving inputs and running their respective shows.

I'd be interested in comments as to the good/bad/ugly aspects of what I've chosen to do.