PDA

View Full Version : [Resolved] self.splitViewController... returns NULL?




ArtOfWarfare
Aug 6, 2012, 11:19 PM
This is the first time I've tried writing an iOS app in... 8 months... and the first time I've tried using a SplitViewController ever. Anyways, here's what I want:

A settings menu that goes through a two-pane hierarchy, with minimal coding involved. I figure Storyboards will be great for that.

I have a MasterViewController, which is a UITableView subclass. Here's the significant code for it:

// In the header I make NSArray* categories; an ivar.

- (id)initWithCoder:(NSCoder *)aDecoder {
self = [super initWithCoder:aDecoder];
if (self) {
categories = [NSArray arrayWithObjects:@"General", @"Personalize", @"Data Collection", @"Graph", @"About", nil];
}
return self;
}

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
return 1;
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return [categories count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Category"];
if (cell == nil) cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Category"];
cell.textLabel.text = [categories objectAtIndex:indexPath.row];

return cell;
}

- (NSString*)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section {
return @"Settings";
}

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
UIViewController* newViewController = [self.storyboard instantiateViewControllerWithIdentifier:[categories objectAtIndex:indexPath.row]];
UINavigationController* navController = [self.splitViewController.viewControllers lastObject];
[navController setViewControllers:[NSArray arrayWithObject:newViewController] animated:NO];
}

It all works up until the bolded lines. navController ends up being null. After examining a little more, I found self.splitViewController was also null. Any suggestions as to why that is? I've checked my storyboard and everything is of the proper classes... (that is the Master View Controller is an AESSettingsMasterViewController, and everything else is of standard UIKit classes.)

I've attached a screenshot of my storyboard.

Edit: Also, everything is embedded in a tab bar controller (which is the root / initial view controller for my entire app,) but that wouldn't be causing the issues, would it?



larswik
Aug 7, 2012, 03:26 AM
This is Off topic but thought it was funny, it still has to do with the poster.

Just before bed I logged on and saw this post here. You said you had not written an app in 8 months. Then I clicked over to Macworld and they are reviewing your app there, Battery Status.

http://www.macworld.com/article/1167554/battery_status_displays_the_battery_levels_of_your_macs_connected_hardware.html

I am curious if you get a spike in sales after that article?

Anyway thought it was kind if funny so I thought I would share.

ArtOfWarfare
Aug 7, 2012, 07:11 AM
This is Off topic but thought it was funny, it still has to do with the poster.

Just before bed I logged on and saw this post here. You said you had not written an app in 8 months. Then I clicked over to Macworld and they are reviewing your app there, Battery Status.

http://www.macworld.com/article/1167554/battery_status_displays_the_battery_levels_of_your_macs_connected_hardware.html

I am curious if you get a spike in sales after that article?

Anyway thought it was kind if funny so I thought I would share.

Mountain Lion has caused daily sales to go from the 2/day they were at up to 20/day. I haven't yet seen the impact of the article sales wise, but for 20/day, I was ranked at 100 in Paid Utilities. This article has brought me up to 5 in Paid Utilities.

Back on topic now... I'm actually working for someone who wants me to mock up their app in 48 hours. So I need it done within 20 hours... once this works, I'm done with the mock up.

Edit: Found the issue!

For some reason, in my header for my view controller I had this:

@property (nonatomic) UISplitViewController* splitViewController;

So what's that do? It seems to replace the superclass (UIViewController) version of the splitViewController with my nonfunctional version. As much as I dislike typing out namespaces in C++, it seems like having namespaces could have helped me avoid this headache...

chown33
Aug 7, 2012, 09:48 AM
For some reason, in my header for my view controller I had this:

@property (nonatomic) UISplitViewController* splitViewController;

So what's that do? It seems to replace the superclass (UIViewController) version of the splitViewController with my nonfunctional version. As much as I dislike typing out namespaces in C++, it seems like having namespaces could have helped me avoid this headache...

Assuming you're talking about C++ namespaces, would namespaces prevent method overrides?

A property is just a different way of defining accessor methods (http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html%23//apple_ref/doc/uid/TP30001163-CH17-SW1). So you overrode accessor methods (provided new declarations and implementations thereof), assuming you synthesized the property.

If you also relied on a synthesized ivar, then the compiler would reuse the one with the same name. (See details of @synthesize in above-linked reference doc.)

There's no substitute for knowing the properties and methods of a class. Overrides are overrides, no matter if intentional or accidental. Even Java's @Override won't always save you from your ignorant self.

dejo
Aug 7, 2012, 12:44 PM
For some reason, in my header for my view controller I had this:

@property (nonatomic) UISplitViewController* splitViewController;

Do you know where that came from? Did you add that?

ArtOfWarfare
Aug 7, 2012, 10:51 PM
Do you know where that came from? Did you add that?

I had. When I was still experimenting with how to send messages between the master and detail view controllers, I had the idea of making that property and then trying to set it from the app delegate or something like that. I quickly realized it wasn't going to work, got rid of the implementation code, but forgot to remove that from the header. Thus, later when I learned about the built in property and tried using it, it didn't work on account of my having accidentally hiding the superclass's getter/setter for it.