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

Check Network reachable #511

Closed
diegothucao opened this issue Jun 4, 2015 · 9 comments

Comments

@diegothucao
Copy link

commented Jun 4, 2015

Hi, I think it is nice if there is a feature which allows users to check network status like Reachable feature of AFnetworking

@cnoon

This comment has been minimized.

Copy link
Member

commented Jun 4, 2015

Duly noted. We've had some very interesting discussions / debates on AFNetworking around the usage of the Reachability APIs and how useful they truly are. I'll huddle the TC at WWDC and we'll see if this is something we want to get onto the roadmap.

I'll go ahead and leave this issue open for the moment for others to comment as they like.

Cheers 🍻

@jshier

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2015

In my experience with AFNetworking, the reachability check is almost never useful. If a request fails because of a connectivity failure, you get an error back immediately that tells you so. It also goes against Apple's recommended practice to check reachability before making requests. So really it comes down to using to the reachability status changes to trigger some change, like restarting previously failed requests. But since such functionality isn't built into Alamofire, and seems rather out of scope for the library, it seems like integrating reachability would be too. I haven't looked but I'm guessing there's already a good Swift reachability library out there which developers can integrate with Alamofire if they need.

@cnoon

This comment has been minimized.

Copy link
Member

commented Jun 13, 2015

Thanks for the feedback @jshier. I agree that the usefulness is for handling the connectivity restored notification. As for it being out-of-scope for Alamofire, I don't entirely agree. We want Alamofire to be the best way to use NSURLSession in Swift. Dealing with connectivity issues and events is certainly a part of that story.

@bsantanas

This comment has been minimized.

Copy link

commented Jul 28, 2015

Well, I have to agree that the reachability check is not that useful most of the time. However, I'm building an app which is really time-sensitive and I need to alert the user as soon as the network changed its state. I use AFNetworking.sharedManager to monitor the state of network at anytime and post a notification in the mentioned case. It's simple and elegant, I would love to see this pattern in AlamoFire.

@justinmakaila

This comment has been minimized.

Copy link

commented Jul 31, 2015

I think your best bet is to wrap the Alamofire API and use your own reachability monitor; I believe it's out of the scope of the library to build it in when it could be accomplished so easily outside.

@aminiz

This comment has been minimized.

Copy link

commented Aug 6, 2015

In my experience there are two obvious scenarios where reachability is useful. One is re-trying some previously failed requests as @jshier mentioned. Another scenario is where the application needs to continuously sync some information with the server.

Additionally, some apps could have an offline/online mode.

@vinod1988

This comment has been minimized.

Copy link

commented Oct 27, 2015

Best way is to implement the reachability to allow the user offline alert. Also some option to disable the reachability. In some scenario we don't want to show internet connection message because we are fetching the data from server in background that time its very helpful.

@ashleymills

This comment has been minimized.

Copy link

commented Nov 20, 2015

If you're looking for a Swift native Reachability replacement, take a look at http://github.com/ashleymills/Reachability.swift

@cnoon

This comment has been minimized.

Copy link
Member

commented Nov 22, 2015

Thanks for posting that @ashleymills. I'm going to go ahead and close this issue out. We're still debating this internally to figure out whether this is something we'd like to directly support. Once we make a decision, I'll update this issue. Thanks for everyone's input here. 👏🏼👏🏼👏🏼

@cnoon cnoon closed this Nov 22, 2015
@cnoon cnoon self-assigned this Nov 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.