I have created a class that implements UITextFieldDelegate so I only need to use [MyDelegateClass setDelegate:textField someConfigparams:...] in order to use it. Inside it will create an object and assign to the textFieldDelegate.
The problem appears when releasing: the setDelegate method in UITextField doesn't retain the object so I can't just autorelease it. I could keep a reference outside to release it but it is ugly and prone to error since I need to do an extra work outside the delegate class. Subclassing UITextField is a bad option since I would need to use always this subclass which could conflict with others.
Is there any way I could release the delegate object when UITextField object is destroyed without relying to code outside MyDelegateClass?
I assume [MyDelegateClass setDelegate:textField someConfigparams:...] creates and instance of MyDelegateClass and assigns that instance as the delegate on the provided textField. What i would do is make the instance of MyDelegateClass a singleton, meaning there is only ever 1 instance.
Basically what will happen in this case is that MyDelegateClass will retain a strong reference to a single static instance of itself and that instance will stay alive for as long as your application stays alive or until you purposefully release it. It is perfectly ok to have one instance of an object be the delegate for many textFields. The memory impact of having a single instance of this class alive always is going to be constant, i.e. not growing, and very small.
Related
Say I have an instance variable MyObject that has been allocated and initialized. Then say I do this:
[backgroundThread performBlock:^{
//do something with MyObject that might take some time
}];
[self dismissModalViewController]; //this releases all instance variables, right?
So what happens is I have an NSManagedObjectContext called backgroundThread that does some work on an object in the background. This returns immediately and does the work in the background, and then dismissModalViewController is called, which deallocates all instance variables. So what if the modal view has now been dismissed, but the backgroundThread still needs to use the object? Is this an issue? What is the workaround?
And another thing: This MyObject is inserted into the managed object context backgroundThread. Does this mean that this NSManagedObjectContext will retain the object, even after dismissing the view?
I'm using ARC.
There are several things you need to think about here. First keep in mind that the block will capture whatever it refers to. So you might not need to do anything special and your code will work fine, depending on exactly what you are doing in your block. The rules for block capture are described in Apple's Block Programming Topics documentation and how each variable is treated depends on its type. In particular,
In a manually reference-counted environment, local variables used within the block are retained when the block is copied. Use of instance variables within the block will cause the object itself to be retained. If you wish to override this behavior for a particular object variable, you can mark it with the __block storage type modifier.
If you are using ARC, object variables are retained and released automatically as the block is copied and later released.
Another thing to consider is that access to the instance variables may or may not be thread safe. Accessing the instance variables through properties declared as atomic is a step in the right direction, but you may need to use mutex locks or other techniques to synchronize access depending on the specifics on the situation.
If you want to reference ivars or other properties of your (modal) view controller, you need to insure that the modal view controller still exists.
Here's a potentially useful hint from Apple's documentation on dismissModalViewControllerAnimated::
If you want to retain a reference to the receiver’s presented view
controller, get the value in the modalViewController property before
calling this method.
Another idea that might work would be to create & instantiate a separate object that encapsulates the data / objects you want to access from either the view controller, or any other thread.
I need to download some images from server. So I created a seperate class to handle NSURLConnection delegates.
At the end of didFinishDownloadingData, I called a delegate method like [(id)delegate performSelectorselector(finished:) withObject:receivedData]
I have a view controller called ListImages.
I created the above connection class from ListImages class and assigned connection.delegate = self. After image loaded from server the method -(void)didFinishDownloadingData:(NSData *)data; was called successfully, and I could display that image.
My problem starts now. To handle some common tasks, I created a new class called SharedMethods which is a subclass of NSObject. I allocated connection class as
Connection *conn = [[Connection alloc]init];
conn.delegate = self;
[conn startDownload]; //called a method which starts nsurlconnection.
I am using ARC so not released that object. My applicaion got exception in method, (In Connection class)
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
[(id)delegate performSelectorselector(finished:) withObject:receivedData]; //Got an exception in this line
}
The exception was [SharedMethods retain] message send to deallocated object. I dont think I have released anything because I am using ARC.
There was also a problem while callingUIAlerView delegates inside a Class which is a subclass of NSobject. It is not called any how. My doubt is, is there any problem with using a NSObject sublass? Is there anything to consider when using NSObject sublass ?
Thanks in advance.
Using ARC doesn't mean than objects never receive the release method, or that they never get deallocated. It just means that you don't have to make explicit calls to retain and release, and that happens automatically.
The problem here is that your objects are getting deallocated because no one is owning them. Your specific problem is that SharedMethods is being deallocated because it's not getting retained, but I can't show you how exactly that's happening because you didn't post the relevant code.
I can, however, show you that you're not managing your Connection properly, and hopefully that can help you figure out what you're doing wrong with SharedMethods.
So you create Connection with alloc init, which with retain-release code would give it a retain count of 1, but since you're not using ARC anymore that's not really relevant. Unless some other object asserts ownership of the Connection, ARC will automatically insert a call to release to bring the retain count back to 0 (it's kind of like if ARC automatically inserted an autorelease).
Since you don't assign Connection to a strong or retain property, or put it in a collection, no other object is asserting ownership to it. So once execution reaches the end of the scope where the variable conn is defined, it will get released and deallocated.
So in ARC, much like in manual retain-and-release code, you still need to make sure objects are owned by some other object in order for them to stick around. The only difference is that you don't need to manually call retain and release, you just have to think about the object ownership graph—which object is owned by which other object—and make sure that any object you want to stick around is owned by some other object.
So to reiterate, you need make sure that SharedMethods is owned by some other object.
I have a bunch of objects and I try and simulate events with them.
id completedSelectorTarget;
SEL nextTripSelector;
Then I call perform selector on the selector target.
Well I created a double reference where the listener of the event completedSelectorTarget retains my object and completedSelectorTarget is retained by the object as well.
How do I avoid this? Is there a better way to do events? I thought to remove the retain on completedSelectorTarget, but then what will happen when I call perform selector? The whole thing will crash wont it? Is there a way to check if completedSelectorTarget has been released before I call perform selector? Or perhaps I'm just doing this wrong?
Yes you are correct, you should avoid circular retains.
The way to do this is to decide on an ownership model for these objects. This means deciding which object should have the final say over the life and death of these objects, and a good way to choose this is to pick the object that creates these objects as the owner and main retainer of them. It's not the only way it can be done, but that should be a good start in the right direction. All other relationships should be weak and use assign for the property. In this way you can be sure that when the owner of the objects decides that they should go away, that they will. The owner could also cause these weak links to be cleaned perhaps by calling a method that separates the weak connection by setting the target properties to nil. This is done in case any other object is hanging onto either of the objects and causing the selectors to fire on the targets that have been deallocated.
So you can remove the retain from the completedSelectorTarget properties and make weak connections between the objects.
#property (assign) __weak id completedSelectorTarget;
Once that is done, decide which object is the owner of these objects and make it retain them, either directly using #propery (retain) ..., or perhaps by storing them in a container such as an array or dictionary. When this retain, or container, is released, your object(s) should deallocate or at the very least wind up on an autorelease pool. And you now have a single owner that you can go to to make sure your objects get deallocated.
For now I'm using NSNotification Center. I notice that it crashes as well if you don't remove the observer when it is released. Still it should save me time from writing my own code.
I have a class I wrote called Location that just holds some strings. I'm using two instances of that class in a view controller, and when I initialize the two variables in viewDidLoad, they work fine for that method, but then when I try to use them later they are null. I have them set as retained properties. I have tested them and know that they are initialized for viewDidLoad (I use their fields in the view). Do I have to do something special in the Location class to make sure they don't get released? When I re-initialize them in a different method, everything runs smoothly.
Instance variables properly initialized in viewDidLoad should retain values normally just like they would in any other method. A coding error may cause the issue you are describing, e.g. if you have local variables in viewDidLoad hiding identically named instance variables.
you (or the event loop) is probably releasing the objects you are initializing after viewDidLoad is complete since they are autoreleased or something. To prevent that, make the variables in question properties on the class with the "retain" attribute and set them to nil on dealloc.
I have an instance of a UITableView, and a separate class that adheres to the delegate and datasource protocols. I'm doing this like so:
SubjectTableViewHandler *handler = [[[SubjectTableViewHandler alloc] init] retain];
tv.delegate = handler;
tv.dataSource = handler;
[handler autorelease];
I don't want to maintain the handler as an ivar, and if I take off the retain call at the end, when the autorelease happens, it is sent release, then added to the pool, which causes an EXC_BAD_ACCESS. So currently, the retain count is:
(1) At init: 1
(2) At retain: 2
(3) delegate/datasource properties are 'assign', still 2
(4) At autorelease: 1, now in autorelease pool.
But then since the properties are 'assign', they will never be released, the retain count will never hit 0, and the handler will never be deallocated anyway. Is there any more efficient way to accomplish this than maintaining the handler as an ivar and releasing it in the dealloc method?
When you initialize the object using init, you are claiming ownership of it and there is no reason to call retain. You also don't want to call autorelease since that will cause the object to be released at the of the run loop.
Since you need to keep the handler (so that your tableView can call the delegate/dataSource methods) and a reference to the handler after the method returns (so you can release it when you are done showing the tableView), the cleanest approach would be to make it an ivar.
The only solution that I can see is, as you mentioned, to make it an ivar and store, allocate, and deallocate it in parallel with the table.
It all depends on your use of table view.
Common practice is you create a view controller which is a delegate to table and table may be a controller's member.
As another alternative you can inherit from UITableView and make it delegate of itself.
Sometimes it's better to use a singleton delegate.
Also, in table delegate methods first argument is tableview, so one delegate object can service multiple tables.