Closed Janne-M closed 10 years ago
Hmm, the category declares -responseObject for the subclasses. I suppose it'd be reasonable to return -responseData
for AFHTTPRequestOperation itself, when a more specific subclass is not in use.
I'm guessing you're not using a subclass, right? Also, are you still using AFNetworking 1.x?
Wow, that was fast! Yup, no need for a subclass. I'm still on AFNetworking 1.x, I have some legacy code that depends on it. I'll probably update to AFN 2 when time permits, but I understood that it was som restructuring needed and not jus a recompile... ;-)
Cool, yeah, I haven't used AFN 2 yet. I watched some of the patches go by and I think the synchronous case may be easy to handle in the new version. If not this will need rewriting to accommodate it.
It sounds strange, but I hadn't considered the use case where you use the data directly rather than in a subclass. Some programmers might want -responseString
instead of -responseData
, but it seems like -responseData
is at least possibly useful, where nil
definitely is not.
I'll get this changed tonight. Thanks for the patch!
You're welcome! I thank You for providing this excellent category that just blended nicely into my project and solved my synchronous need in no time. Please make it compatible with AFN2, so I have another reason to myself to make the switch.. :-)
I was very pleased to find Your category for AFNetworking, I was in need for handling a specific synchronous case in my otherwise async app. But to my surprise, although I didn't get any errors, I never seemed to get any data back...
And after spending sometime in the debugger, I noticed that the implementation of the AFHTTPRequestOperation (ResponseObject) ALWAYS returned nil. Replacing that with a simple "return [self responseData]" solved the problem for me.
Unfortunate, I'm not a experienced Git contributor, so I have no idea how to contribute to the code, so this will be my contribution... :-)