Advertise here




Advertise here

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

UINavigationController subclassing

rendezvouscprendezvouscp Posts: 53Registered Users
edited November 2008 in iPhone SDK Development
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.
Post edited by rendezvouscp on
<a href="https://ironmoney.com/ios/" target="_blank">Iron Money, a personal finance organizer, for iPad, iPhone, and iPod touch</a>

Replies

  • DevTeamOfOneDevTeamOfOne Posts: 361Registered Users
    edited October 2008
    I am unsure how to set up the app, but just letting you know that UINavigationController should never be subclassed.
  • rendezvouscprendezvouscp Posts: 53Registered Users
    edited October 2008
    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.
    <a href="https://ironmoney.com/ios/" target="_blank">Iron Money, a personal finance organizer, for iPad, iPhone, and iPod touch</a>
  • DevTeamOfOneDevTeamOfOne Posts: 361Registered Users
    edited October 2008
    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.alimohideenjavid.alimohideen Posts: 298Registered Users
    edited October 2008
    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.
  • rendezvouscprendezvouscp Posts: 53Registered Users
    edited October 2008
    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!
    <a href="https://ironmoney.com/ios/" target="_blank">Iron Money, a personal finance organizer, for iPad, iPhone, and iPod touch</a>
  • DevTeamOfOneDevTeamOfOne Posts: 361Registered Users
    edited October 2008
    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.alimohideenjavid.alimohideen Posts: 298Registered Users
    edited October 2008
    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];
    
  • DevTeamOfOneDevTeamOfOne Posts: 361Registered Users
    edited October 2008
    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?
  • rendezvouscprendezvouscp Posts: 53Registered Users
    edited November 2008
    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).
    <a href="https://ironmoney.com/ios/" target="_blank">Iron Money, a personal finance organizer, for iPad, iPhone, and iPod touch</a>
Sign In or Register to comment.