Question

I’m coding a library (Obj-C for iPhone) that I want to package and sell, so I obviously need to work out any design kinks before listing it for sale. I am also utilizing this library to help me develop another app.

My library is heavily built on task delegation. The primary function I have is to launch a (potentially) long-running process, and when it’s done, I call a Delegate Protocol method in the class’s delegate.

An additional complicating factor here is that I will often schedule this task to fire off every 30 seconds or so. Usually, I do this with [self performSelector:@selector(someMethod:) withObject:nil afterDelay:30] rather than using an NSTimer. Then, when the delegate method successfully returns, I process the returned data and trigger the method to fire in another 30 seconds. This gives me 30 seconds BETWEEN method calls, rather than 30 seconds FROM THE START OF ONE CALL TO THE NEXT. (This is mainly just in case the call ever takes more than 30 seconds, which shouldn’t happen.)

The error that I’m catching is that sometimes, the Delegate callback method is failing with an EXC_BAD_ACCESS error. Based upon my investigation, it appears that the delegate of my class library has disappeared (been released/dealloced) since the long-running process was initiated. Thus, when it calls [[self Delegate] doSomeDelegateMethod], it’s accessing a released object.

I tried first checking [[self Delegate] respondsToSelector:@selector(doSomeDelegateMethod)], but even that access apparently also throws the EXC_BAD_ACCESS.

It doesn’t yet seem that checking for [self Delegate] == nil is the right way to go, either.

One way I think I have solved the problem, in this specific instance, is when the view controller that instantiates my object is disappearing (and therefore on its way to the garbage dump), I call [NSObject cancelPreviousPerformRequestsWithTarget:self]. This apparently fixes the problem. (Does this “fix” also indicate that my object “knows” about the call to come and keeps itself in memory until it can successfully, desperately, fire off its final shot?)

This appears to put a band-aid on a bullet wound. Yes, it appears to stop my app from breaking this time, but my gut tells me that this is a poor solution.

I’ve also considered setting the custom object to nil in my viewWillDisappear:animated: method, which is probably the correct coding pattern, but it doesn’t seem right that the customer has to be so precise in handling my objects.

What’s really bugging me, though, is that I haven’t yet found a way, as a library developer, to “box in” my code so that it won’t throw an exception for the user if they don’t do just the right things. Basically, I’d like a way to have my object:

1. Get a request.
2. Go look for the answer.
3. Find the answer.
4. Try to return the answer.
5. Realize that there’s nothing on the other end.
6. Give up and die on its own. (OK, so “die on its own” probably won’t happen, but you get the point.)

One interesting side point:

A main reason I have for preventing this type of error from occurring is this:

I did the following steps:

1. Built my library’s .h/.m files.
2. Generated my library’s .a output file.
3. Imported my library’s .a/.h files into another project.
4. Had the error described above.
5. Got to peruse the code from one of the .m files that SHOULD have been hidden inside the .a file.

Am I missing something here? Am I really risking exposing my entire source code if it ever throws an error for a client? (This is just a side issue, but I’m fairly concerned here!)

Thanks for any help you can provide to help me be a better programmer!

—EDIT—

I have found another reason why this is important. In another view controller, where I am using this library, I implemented the NSTimer strategy. If the view is popped from the navigation stack (i.e., in the viewWillDisappear:animated: method), I invalidate said timer. So, no more calls will go to my library after the view disappears.

Here’s the rub: what if the view disappears IN THE MIDDLE of the long-running call? Yes, it’s tricky and unlikely to do, but I just had it happen on the simulator. In particular, THIS is why I’m looking for a workaround to let my code realize “hey, there’s nothing on the other end of this pipe” and then fail gracefully. Anyone?

Thanks!

Answer 1

There are several approaches to this problem:

• The traditional delegate approach (UITableViewDelegate) makes it a requirement to clear yourself as delegate before going away. This is traditionally done in dealloc of the delegate with otherObject.delegate = nil. Failure to do so is a programming error. That’s basically what you’re seeing. This is the common pattern when the delegate and the delegator have basically the same lifespan.

• Another approach is how NSURLConnection handles it: retain your delegate until you’re done. The key to this working well is that NSURLConnection has a lifespan of its own, so the retain loop will work itself out automatically. UITableView could not retain its delegate because this would almost always create a permanent retain loop. If your object lives for a while and then goes away, then this makes sense. Typically here the delegate has a much shorter lifespan than the delegator, so the retain loop doesn’t hurt anything.

Any object that calls performSelector:withObject:afterDelay: should always call cancelPreviousPerformRequestsWithTarget:self in its own dealloc. This has nothing to do with your delegate, though. It should be self-contained to the object itself. (I don’t know why I keep thinking this is true, and then proving to myself again that it isn’t. When you call performSelector:…afterDelay:, you are retained, so you can’t deallocate before it fires. My SIDE NOTE, while true, isn’t relevant here.)

SIDE NOTE cancelPrevious... is really expensive in my experience. If you have to call cancelPrvious... very often, I recommend keeping your own one-shot NSTimer and just resetting it when it fires to get the same effect. performSelector:withObject:afterDelay: is just a wrapper around a one-shot timer.