2

I'm using the Facebook iOS SDK for a project and if I pop a UIViewController after doing a request but before receiving an answer I get an EXC_BAD_ACCESS when it tries to see if the delegate responds to a selector. Well, the delegate is the UIViewController already popped so it probably doesn't exist anymore.

When researching about this issue I stumbled upon this answer here on SO which tell me I shouldn't be having this problem since the delegate is retained. But the answer is a little old and they started to use arc after that. So I checked the SDK and noticed their not retaining it anymore.

Is this a known issue? Am I missing something here?

I tried modifying the SDK and retaining the delegate and the problem disappears. Nevertheless I don't like modifying third-party libraries as I don't have that much expertise and I'm not sure if arc is really a problem in this situation (I thought we didn't need to use retaing/release/autorelease anymore). Also, I thought this being Facebook SDK, if it were a bug someone should already stumbled upon the same problem and solved it.

EDIT: I realize now that at least the version I'm using of the Facebook SDK is not using arc (I don't know if they already support it) and the problem may be this:

@property(nonatomic,assign) id<FBRequestDelegate> delegate;

Shouldn't it be retain?

EDIT2: I'm sorry, I skipped through another answer in the same post linked earlier.

It seems what I pointed out is now obsolete in newer versions of the SDK. The best approach seems to be to cancel the request.

Community
  • 1
  • 1
dvieira
  • 683
  • 1
  • 7
  • 19

1 Answers1

0

Shouldn't it be retain?

Absolutely not. If you did that then you'd very likely have a retain cycle (VC owning the FBRequest which owns the VC).

You're 100% correct that the right thing to do is cancel the request when the view controller is deallocated, or probably even better is to set the delegate of the request to nil and then cancel it.

mattjgalloway
  • 34,792
  • 12
  • 100
  • 110