Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate Issues with Reachability Not Restored #408

Closed
blakewatters opened this issue Oct 14, 2011 · 3 comments
Closed

Investigate Issues with Reachability Not Restored #408

blakewatters opened this issue Oct 14, 2011 · 3 comments
Assignees
Labels
Milestone

Comments

@blakewatters
Copy link
Member

Getting a number of reports about reachability issues not being restored properly.

@ghost ghost assigned blakewatters Oct 14, 2011
@grgcombs
Copy link
Member

I REALLY wish Apple would put together a real reachability framework with a thread-safe objective-c front-end. Until that day, SCReachabilityKit on GitHub works pretty great. There's also Andrew Donoho's more recent revisions to Apple's reachability class.

For what it's worth, I went with the former since it fit my project case better. I wrote a layer on top of it that looks primarily at known hosts, suitable for restkit type usage, and for any other unmonitored hosts, it just looks at general network reachability instead of doing another DNS lookup, etc.

The kicker is there's only one time where it uses the synchronous getFlags: method, on the initial watch. Everything else is asynchronous, to reduce blocking.

I can discuss more if needed, but if you find the SunlightLabs/StatesLege project, look in Classes/Helpers/SLFReachable.m

Don't bother trying to build the project though, not all submodules are open to the public yet.

G

Sent from my iPhone.

On Oct 14, 2011, at 1:47 PM, Blake Wattersreply@reply.github.com wrote:

Getting a number of reports about reachability issues not being restored properly.

Reply to this email directly or view it on GitHub:
#408

@grgcombs
Copy link
Member

Two big things that I'll bring up in the conference call today:

  • We wind up calling SCNetworkReachabilityGetFlags() a whole lot ... every time we check networkStatus or isNetworkReachable or isConnectionRequired. That's a synchronous call that can block the thread up to thirty-seconds every time we use it. What I discovered from using SCNetworkReachabilityKit is that we can get all the same utility out of reachability if we just catch those same flags passively from the userInfo dictionary (that kit handles all of that part). But there should only be one event that prompts you to call the synchronous library functions, and that's when you're just starting to monitor a host.
  • The other big thing that I saw in that SCNetworkReachabilityKit was some unit tests for network access and reachability. He uses fake reachability flags to exercise the reachability code ... I've adopted some of that in my own thing and eventually I want to get it test that all my components react appropriately whenever network access is gone and then returns. We can do something similar for the RestKit spec environment I bet.

blakewatters added a commit that referenced this issue Oct 18, 2011
…synchronous API's. refs #408

Very large update to the capabilities of the reachability observer as well as (hopefully) fixes for
the iOS issues reported on the list.
@grgcombs
Copy link
Member

This restructuring looks good to me.

blakewatters added a commit that referenced this issue Oct 19, 2011
…eue suspension on observer mutation instead of baseURL. Cleaned up specs. refs #408

Various header cleanups for RKClient included
blakewatters added a commit that referenced this issue Oct 20, 2011
blakewatters added a commit that referenced this issue Oct 20, 2011
…LL queue is triggering errors. refs #408"

This reverts commit fa6cff8.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants