UINavigationController subclassing

[rendezvouscp]

So I have a bit of a problem. I’m going to use the clock app as an example for my problem.

When I want to add a new alarm, I create a blank alarm object with some default values. However, I need to be able to use different nibs for input/selection.

I originally loaded all of the nibs and accessed their values from the main "add view" directly. However, this is too memory-intensive for my application. So, I subclassed UINavigationController so that it could store the new alarm object, and as the input/selection nibs came and went, they could update the new alarm object by saying self.navigationController.newAlarmObject.time = @"Time";.

This, however, isn’t working. If anyone has suggestions as to how I can make this work, or other ways to achieve what I’m trying to do, it’d be much appreciated.

[DevTeamOfOne]

I am unsure how to set up the app, but just letting you know that UINavigationController should never be subclassed.

[rendezvouscp]

Originally Posted by DevTeamOfOne

I am unsure how to set up the app, but just letting you know that UINavigationController should never be subclassed.

I’m interested why you say that. I haven’t read in the docs or header files anything that says never to do it. Or, maybe people shouldn’t do it for the very issue I’m running into!

So, I’m currently trying a different pattern to solve the issue, which includes loading the nibs when needed and deallocating all of them (that aren’t nil) whenever the main "add view" appears.

[DevTeamOfOne]

It is stated in the ViewController programming guide that TabBarControllers and NavigationControllers "Don't need to be subclassed" and Apple never say that about any class. What are they saying? You shouldn't. It creates mega hassles.

[javid.alimohideen]

Create a new NavigationController with the AddAlarmViewController as the root view controller and present it as a ModalViewController from your main NavigationController. This way you wouldnt have to worry about subclassing NavigationController. Your add alarm view controller will hold the new blank alarm object.

I agree with the DevTeamOne, that UINavigationController should never be subclasses.

[rendezvouscp]

Hi javid.alimohideen,

My problem lies with accessing the data from my new alarm object in all of the subsequent views. Choosing repeat, sound, and label all happen in a different view, and those views need to update the new alarm object in the AddAlarmViewController. I chose to subclass the navigation controller because that is common among all of the view controllers, but I’m going to try the method I outlined above instead.

I’ll let everyone know how it goes!

[DevTeamOfOne]

I recommend a simpler way: Do all your organization in the app delegate and create a singleton object version of it in each subclass. Then apply that to each level in your navigation controller sequentially.

So, you make an alteration. Send that data to the app delegate by sending the app delegate a message with the information required. That custom message sends it off to the root view controller. That root viewcontroller sets the property of the next one and so on.

[javid.alimohideen]

Ok. In that case, why don't you sublcass the Views or view controllers where you are changing the properties.
For example, say you have view AlarmRepeatViewController.xib and AlarmRepeatViewController.
You would doing something like initWithNibName:@"AlarmRepeatViewController"

In your AlarmRepeatViewController.h file, create a property of type Alarm

AlarmRepeatViewController.h
@interface
  Alarm *alarm;
@property (nonatomic, retain) Alarm *alarm;
 @end

// Before you push the AlarmRepeatViewController set the alarm object value

AlarmRepeatViewController *controller = [[AlarmRepeatViewController alloc] initWithNibName:@"AlarmRepeatViewController" bundle: nil];

controller.alarm = self.myAlarmObject
[self.navigationController pushViewController: controller animated:YES];
[controller release];

[DevTeamOfOne]

This is generally the idea I speak of. Its simple and effective, and not a waste of time like subclassing UINavigationController.

This is, tbh, basic stuff.

I would recommend, however, instead of the way you do it above, encase that in a method and send the app delegate a message to change the main property which sends the root view controller a message automatically to resyncronise its data to the app delegate which then asks the next view to syncronise down and so on.

Make sense?

[rendezvouscp]

I didn’t find any of the above methods to be particularly useful. For reference, here’s the solution I came up with.

Each of the detail views (repeat, label, etc.) send a message (thanks to NSObject’s performSelector:withObject: method) to the main "add" view controller when they are about to disappear with new data that they have. The message in the "add" view controller then updates its blank alarm object and updates the appropriate row (instead of reloading the entire table).