Please do not post the same thing multiple times. The board software automatically flags certain posts as needing moderator attention. This happens the most often for new users. I'm pretty sure this is made clear at the time you attempt to post. Posting the same thing over and over again just makes that many more posts the moderators have to weed through later. This makes us sad. Don't make us sad. If your post/thread doesn't appear, just wait a while. Don't post it again. If it hasn't shown up by the next day, then you can try again. I normally go through posts in the mornings, and try to check a few times throughout the day, but I'm not here 24/7. There will typically be a significant delay before posts are approved. Just be patient.
So I have a bit of a problem. Im 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, isnt working. If anyone has suggestions as to how I can make this work, or other ways to achieve what Im trying to do, itd be much appreciated.
I am unsure how to set up the app, but just letting you know that UINavigationController should never be subclassed.
Im interested why you say that. I havent read in the docs or header files anything that says never to do it. Or, maybe people shouldnt do it for the very issue Im running into!
So, Im currently trying a different pattern to solve the issue, which includes loading the nibs when needed and deallocating all of them (that arent nil) whenever the main "add view" appears.
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.
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.
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 Im going to try the method I outlined above instead.
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.
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
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.
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).
rendezvouscp
Posts: 53Registered Users
Replies
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeSo, Im currently trying a different pattern to solve the issue, which includes loading the nibs when needed and deallocating all of them (that arent nil) whenever the main "add view" appears.
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like Awesome- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeI agree with the DevTeamOne, that UINavigationController should never be subclasses.
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeMy 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 Im going to try the method I outlined above instead.
Ill let everyone know how it goes!
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeSo, 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.
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeFor 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
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeThis 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?
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like AwesomeEach 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).
- Spam
- Abuse
- Troll
0 · Off Topic Insightful Disagree Dislike Like Awesome