I'm working on an iPhone application. I'm using Storyboard.
I wanted to have one object attached to the NavController to handle the visibility of the button bar at the bottom of windows that display table views.
I created my own UINavigationDelegate; MyNavigationControllerDelegate.
I have created an NSObject in UIBuilder and changed its class MyNavigationControllerDelegate. And then attached it as the delegate of the UINavigationController.
For some reason MyNavigationControllerDelegate is getting deallocated. I would have thought that being the delegate would be enough to keep a reference to it and prevent deallocation, but that seems not to be the case.
Any suggestions as to how to prevent it from being deallocated? And do I have to reset it as the delegate each time a view is loaded?
The delegate property of UINavigationController is declared as assign rather than retain or strong (see here). Delegates are typically declared either weak or assign, which means assigning the property will not cause the UINavigationController to increase the reference count on your delegate, and you need another object to hold a strong reference to it (perhaps your RootViewController).
Related
I am new to ARC. My issue is that if we create a strong type property on a view controller, we need to make it nil once the navigation controller's popViewController happens.
Normally, we would do that in viewDidUnload. But in iOS 6 it's deprecated.
So where do we make that object nil? Apple says to do it in didReceiveMemoryWarning but that method does not get called every time when we pop the view controller.
Don't worry about it. Your properties will all get set to nil automatically by the Objective-C runtime in dealloc. This is true of all properties, not just outlets on a view controller.
You define a property strong if you want to keep ownership on the referenced object.
From what I can understand you probably need a weak property (when your object is released by someone else you don't need it and it can be deallocated) or maybe a workaround could be set it to nil in the viewDidDisappear method, but as Jim Puls said, without seeing you code mine are just educated guesses...
If you're popping/pushing between the same two view controllers, then the pointer in the UINavigationController shouldn't change as long as they don't get dealloc'ed. If they do get dealloc'ed then everything in them should get dealloc'ed too. You may end up creating new copies of these view controllers but that shouldn't be a problem because you're only creating new copies if the old ones were already dealloc'ed. The only way you can be retaining objects is if your view controllers (or objects within them) are referencing each other, causing them to be retained.
The difference between strong and weak is not that you need to manually set strong to nil. Rather, a strong relationship will cause an object to be retained, while a weak will not. That's why delegates are usually set to weak since you don't want a delegate retaining its parent (not parent exactly, but the object that it's a delegate of).
I'm trying to get an instance of my AppDelegate accessible to all methods in each ViewController that I have. If I try to declare it with other class variables I get Initializer Element is not a compile-time constant. If I declare it in a method within the ViewController however I am able to use it. I am trying to save integers and floats to properties I have set up in the AppDelegate (a big no-no I know, but this is a project for an introductory class and I'm not expected to get too advanced, especially since everything we've done so far is not compliant with the MVC paradigm). The app uses a toolbar to switch between views using the app's ViewController to load the other ViewControllers as subviews. I was going to put the AppDelegate declaration and update statements in the ViewDidUnload method of each view controller, but I'm not sure that the Views are unloaded whenever they are switched (they're switched by removing the current View from the SuperView and loading the new one as a Subview at index 0). What happens to the views that are not currently being viewed then? Is there a method that detects that that I could implement the AppDelegate declaration and updates into?
I guess ideally I'd like to be able to access the AppDelegate object in any method in my ViewControllers because I have a lot of quantities being updated throughout and would like to have those quantities updated in the AppDelegates values as soon as they happen, since I'm not sure what happens with a View is cleared from SuperView
Thanks in advance everyone
You can access your app delegate via [[UIApplication sharedApplication] delegate] from anywhere in your application.
You should never instantiate another copy of the object on your own. The system does this for you at startup.
As for detecting changes, you can override the viewDidDisappear method of UIViewController. (You're correct--in general, they will not be unloaded when switched, and viewDidUnload will not be called)
I have a view controller that then has a button that passes to an option menu.
When options are set they need to be past back to the previously allocated viewcontroller.
How is this possible without 'alloc and init another' instance of the object?
You can achieve this by using a delegate protocol. First view controller should become the delegate of the second view controller and then you can call this delegate method in your first view controller once the selection is done.
You can lookup google for implementation of delegates in objective-c. Its pretty simple. Add a
#protocol <delegatename>
<declare delegate method>
#end
Create a member variable in the second view controller for assigning the delegate. And define the method in the class implementing the delegate.
When you init your option viewController, pass it a reference to its parent.
I.E.
[[OptionViewController alloc] initWith...: parent:];
Use a #property or a method or somesuch to call on the parent to pass the data back.
You could use a shared singleton?
http://cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html
Or save the parameters to nsuserdefaults and read them back in in your first viewcontroller
or some other temporary store such as your appdelegate
I've used all three of the above approaches before.
I have been having huge issues with this, so I drew a diagram...
alt text http://tomsfil.es/7bdead0a.png
I successfully get to the CLASS A - METHOD B but at that point, IBOutlet Z is Nil? :(
Any ideas?
note
Somebody told me it might be an Overrelease and to use NSZombieEnabled but that confused me
It's all a matter of when you call the class. Right after you create a view controller with initWithNibName, nothing is actually wired up yet - it's only after the view is created that IBOutlets are created and wired in.
One trick is that you can simply ask the view controller for .view, like so:
myViewController.view;
Then the view will be created and the IBOutlet will exist. A better method though, is to create properties on the view controller that you set, and then either in viewDidLoad, or in viewWillAppear you use those properties to set values for your outlets.
I have 2 or 3 views in my iPhone application where I have various pieces of functionality that use delegates. In all cases the delegates are assigned to "self", responding specifically to that view's actions and interacting with instance variables.
However, if I do something that takes a bit of time with a delegate, and leave the view, obviously it crashes my app as the delegate methods get called on a view I've left.
Typically in my delegate methods I am doing things like interacting with IBOutlets, calling other instance methods, saving data to Core Data etc...
How can I work with delegates better? Is what I'm doing typical, or not?
Thanks for any guidance!
Depends on the use case. If, for example, you've got a UINavigationController that manages a ViewController that use something such as Location Services, when you pop the View Controller off of the stack you're going to want to set the CLLocationManager's delegate to nil. You can do this in the dealloc method.
Can you give a specific example of an issue you're facing?
I've encountered this situation once when dealing with MapKit (race conditions involving delegate callbacks and delegate deallocation). However, in general, I think it's an indication of a bad design decision when your delegate becomes invalidated as a result of race conditions, but I could be wrong.
Typically, the objects that make use of your delegate should exist within the context of the delegate itself. So, for example, the same class that contains various IBOutlets that you want to manage with delegate callbacks should also be the delegate of those IBOutlets. That way, when the class (i.e., the delegate) is deallocated, the IBOutlets are (hopefully) also deallocated, so they won't be making callbacks to anything.
bpapa's right. More generally, if you have a potentially lengthy delegate callback, either make sure that 1) the delegate is an object that won't be deallocated during the lifecycle of the delegator (e.g., UINavigationController managing UIViewControllers) or 2) the delegator's delegate object is set to nil during the delegate's deallocation.
... That last sentence was a mouthful. :)
Your delegates should be declared as
#property (nonatomic, assign) id <MyDelegateProtocol> delegate;
This ensures a weak reference so that when you dealloc the object which has delegate, it only removes the reference and NOT the corresponding object. using (strong) will cause a crash on dealloc.
When calling your delegate, you can check
if (self.delegate && [self.delegate respondsToSelector:#selector(MyDelegateProtocolCallbackMethodName:)] {
[self.delegate MyDelegateProtocolCallbackMethodName:result];]
}
Generally I use delegates for proxy classes which fetch data from a server or edit screens like changing the title of a task in a todo list or editing a model in a database.
The advantage of a delegate is a very clear use case. If you find that multiple parts of your app need to be aware of when an event happens (triggered on 1 screen but perhaps listened for in another), I suggest using NSNotificationCenter to raise notifications, instead of or perhaps in addition to sending a message to your delegate.