Crash when calling findAllRemote in rapid succession

(from [dc4fe44dd1338ede2e642e86fa5da20fd22d6ec2]) [#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode http://github.com/yfactorial/obj...

(from [949e4dc87d9e60ad1265465fa0d67874301c0786]) Revert "[#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode"

This reverts commit dc4fe44dd1338ede2e642e86fa5da20fd22d6ec2.

It looks like NSURLConnection needs to run in the default mode, or it will exit immediately. http://github.com/yfactorial/obj...

This is quite the pain. It looks like the problem is with the async NSURLConnection code and events firing in the main runloop. It doesn't seem to be crash within ObjectiveResource, but rather somewhere within the SDK.

I guess the solution is to figure out a different way to handle the async requests.

I did run across this post from an Apple engineer which provides some sample code:

https://devforums.apple.com/mess...

It looks very similar to what you guys are already doing but since there are a couple minor differences, maybe that would be the key? Hope it turns out to be useful...

(from [7573de144e550f23f0a6b0a1b648653581bb53b6]) [#39 Crash when calling findAllRemote in rapid succession] brilliant find Adam! using a custom run loop mode seems to take care of this problem http://github.com/yfactorial/obj...

I can confirm that after getting the latest source the crash is completely eliminated in my local project as well! Just in case, I should point out that a side effect of this change seems to have been a reduction of the asynchronous-ness of the remote connection. I say this because it seems UI changes such as updating a status label or activating a UIActivityIndicatorView, when done immediately before calling findAllRemote, do not take effect until after the connection has completed. This is not a complaint at all, I can work around it in my code but I just wanted to point it out to you in case that had gone unnoticed.

Ah yes, the original implementation kept the UI responsive while the server communication was going on, but this one doesn't.

Still, it's probably better to have to wrap calls from the UI thread up in a "peformSelector:afterDelay:" call than to have the app blow up.

Very true, also I forgot to mention before that I have noticed a significant performance improvement since this fix was implemented. Network operations and unit tests all seem to run much faster, so that's more good news.

It seems there are a few different (sometimes competing) goals that would all be nice to have:

1. Excellent performance
2. Simple syntax for client code
3. Responsive UI during network operations
4. Not blowing up

This latest commit improved #1 Performance Tests and fixed #4 add harvest sample app at the expense of #3 Update README. Like you said above, we have the option to gain #3 Update README back by sacrificing #2 Performance improvements a little. I'm going to try a few different things to see what works the best in my current project (which happens to represent a good example of a relatively standard use case for ObjectiveResource) and will let you guys know what I come up with, either in terms of client code patterns or opportunities to further update OR to give us even more of the 4 qualities above.

(from [ce5e0577391c706fc2ecd6b9d61f90fef698f66d]) Merge branch 'master' of git@github.com:yfactorial/objectiveresource

• 'master' of git@github.com:yfactorial/objectiveresource: [#39 Crash when calling findAllRemote in rapid succession] brilliant find Adam! using a custom run loop mode seems to take care of this problem Revert "[#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode" [#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode Added refresh button to People View http://github.com/yfactorial/obj...

(from [ce5e0577391c706fc2ecd6b9d61f90fef698f66d]) Merge branch 'master' of git@github.com:yfactorial/objectiveresource

• 'master' of git@github.com:yfactorial/objectiveresource: [#39 Crash when calling findAllRemote in rapid succession] brilliant find Adam! using a custom run loop mode seems to take care of this problem Revert "[#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode" [#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode Added refresh button to People View http://github.com/yfactorial/obj...

(from [ce5e0577391c706fc2ecd6b9d61f90fef698f66d]) Merge branch 'master' of git@github.com:yfactorial/objectiveresource

• 'master' of git@github.com:yfactorial/objectiveresource: [#39 Crash when calling findAllRemote in rapid succession] brilliant find Adam! using a custom run loop mode seems to take care of this problem Revert "[#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode" [#39 Crash when calling findAllRemote in rapid succession] run the NSURLConnection in the NSConnectionReplyMode rather than the NSDefaultRunLoopMode Added refresh button to People View http://github.com/yfactorial/obj...

As promised (threatened?) I have come up with some additional thoughts and ideas about this and posted them to a discussion I found at oup/objectiveresource/browse_thread/thread/87393e897ae16c05/f31161c822eccfd4?hl=en#f31161c822eccfd4 since the crash reported in this ticket is already resolved. Thanks in advance for any direction you can provide =)

Bad paste, should be:

http://groups.google.com/group/o...

Hi Adam, I moved your comment to a new ticket: #57 async connection manager

First, make sure you place your test crashing code in a different place than applicationDidFinishLaunching. This is only for testing -- Crashlytics will detect crashes in your applicationDidFinishLaunching method. A good place could be a button action. There is so much to be learnt about it. So better concentrate on it rather than on writing your dissertation abstracts online.

Our academic pursuits, along with a range of extracurricular activities, help in honing a child's skills and ensuring that he/she grows to be a mature and responsible citizen.

best school in greater noida