Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Change the custom class in a storyboard using code when instantiating

I have a tab bar controller and a bunch of the same tabs. Each tab only differs in functionality, but the UI's are all the same. In the storyboard I designed the flow and UI of one tab and set it base class. Then when I create the tabs I tried typecasting them before adding them to the tab bar but it didn't work.

In the storyboard the View Controller indentified "TabView" has the custom class "TabColor"

TabRed *red = (TabRed *)[storyboard instantiateViewControllerWithIdentifier:@"TabView"];
TabBlue *blue = (TabBlue *)[storyboard instantiateViewControllerWithIdentifier:@"TabView"];

However the loadView method in TabColor gets called, not the TabRed/TabBlue.

Also if I nslog it the result is a TabColor object:

NSLog(@"%@", red)

Expected: TabRed

Actual: TabColor

like image 324
Michael Ozeryansky Avatar asked Aug 30 '12 01:08

Michael Ozeryansky


2 Answers

tl;dr:

Storyboards and xibs contain collections of serialized objects. Specifying a class in a storyboard means you will get an instance of that class when you load the storyboard. A way to get the behavior you're looking for would be to use the delegation pattern common in cocoa/cocoa-touch.

Long Version

Storyboards, and similarly xib/nib files, are actually sets of encoded objects when you get down to it. When you specify a certain view is a UICustomColorViewController in the storyboard, that object is represented as a serialized copy of that an instance of that class. When the storyboard is then loaded and instantiateViewControllerWithIdentifier: gets called, an instance of the class specified in the storyboard will be created and returned to you. At this point you're stuck with the object you were given, but you're not out of luck.

Since it looks like you're wanting to do different things you could architect your view controller such that that functionality is handled by a different class using delegation.

Create a protocol to specify the functionality you'd like to be different between the two view controllers.

@protocol ThingDoerProtocol <NSObject>
    -(void) doThing;
@end

Add a delegate property to your viewcontroller:

@interface TabColor
...
@property (strong, nonatomic) thingDoerDelegate;

And then have your new objects implement the protocol and do the thing you want them to.

@implementation RedTabDoer
    -(void) doThing {
         NSLog(@"RedTab");
    }
@end

@implementation BlueTabDoer
    -(void) doThing {
         NSLog(@"BlueTab");
    }
@end

Then create and hook up those objects when you load the storyboard.

TabColor *red = [storyboard instantiateViewControllerWithIdentifier:@"TabView"];
red.thingDoerDelegate = [[RedTabDoer new] autorelease];

TabColor *blue = [storyboard instantiateViewControllerWithIdentifier:@"TabView"];
blue.thingDoerDelegate = [[BlueTabDoer new] autorelease];

This should then allow you to customize the functionality of the view controller by changing the type of object that is assigned to the controllers delegate slot.

like image 123
waltflanagan Avatar answered Nov 05 '22 22:11

waltflanagan


TabRed *red = (TabRed *)[storyboard instantiateViewControllerWithIdentifier:@"TabView"];
TabBlue *blue = (TabBlue *)[storyboard instantiateViewControllerWithIdentifier:@"TabView"];

Casting doesn't change values, it only changes the way the compiler interprets those values (and stops it from complaining when you use type in place of another). So casting a TabColor* to a TabRed* tells the compiler to pretend that your first pointer points to a TabRed instance, but it doesn't transmogrify the object that the pointer refers to into an instance of TabRed.

As waltflanagan explains, storyboards and .xib files contain actual objects, and the type of each object is determined when you create the file; you can't change it at run time. What you can do, though, is to have each of your several view controllers load the same view hierarchy. You don't even have to write any code to do this. Just create a .xib file containing your tab controller and the view controllers for each tab:

IB tab controller

Be sure to set the type for each view controller appropriately in the .xib so that the right kind of view controller will be created for each tab:

IB custom class field

Set the "NIB Name" field for each view controller to specify a .xib file that contains the view hierarchy that these controllers will use. If you specify the same .xib file for each controller, each controller will instantiate its own copies of those views:

IB NIB Name setting

Specify any IBOutlets in the common superclass of your view controllers so that all your view controllers have the same outlets. You can specify that superclass as the type of "File's Owner" in the common .xib file so that IB knows what outlets are available. File's owner is really a proxy for the object that's loading the .xib, so when one of your view controllers (TabRed for example) loads the common view .xib, that controller will be the one that the views in the .xib are connected to. When TabBlue loads the .xib, that object will be the one that those views are connected to.

This might seem confusing at first, but play with it. Understanding this will really help you understand .xib files (and therefore storyboards). They're a lot less magical than they seem when you're a beginner, but once you get it they'll seem even cooler.

like image 44
Caleb Avatar answered Nov 05 '22 22:11

Caleb