The Reachability only tells you if a network MIGHT be available. You
still have to write code to do the data transfer. What if
Reachability tells you the network is available, but then you go to
transfer the data (a second later) and the network is no longer
available? You still have to handle that situation, don't you? I
don't see how the Reachability does what I, or anyone else, needs. It
only notifies you of a condition that WAS true at the time of
notification, but that condition may not hold true when the code in
your Reachability callback is actually executed. See what I mean? Or
do I misunderstand.
- Eric
On May 20, 2009, at 4:27 PM, Luke the Hiesterman wrote:
If you've already written a thread to do that, then great. That's
the reinventing the wheel thing I mentioned earlier, though. Your
question is essentially coming down to, "why use the API instead of
the code I've already written to do what the API does?" Only you can
decide which you'd rather use, but I tend to lean toward standard
API utilization, and encourage others to do the same, because it's
that much less code to maintain. If you're happy with your
implementation, though, then you might not need it.
Luke
On May 20, 2009, at 1:21 PM, Eric Hermanson wrote:
I understand what you are saying, but if you do IO correctly you'll
do it in a background thread anyway. So waiting on a blocking
socket until it times out or gives EOF is normally how IO is done.
So if you already correctly handle that aspect of the IO in your
application (and reconnect the socket as necessary), then that's
where I don't see the advantage of the Reachability APIs. Anyway,
thanks for your input. Maybe I'm just missing the bigger picture
here.
- Eric
On May 20, 2009, at 4:13 PM, Luke the Hiesterman wrote:
Again, it's the waiting aspect. The advantage is you don't have to
spin and do something in a loop in your code. You go about your
business and let reachability get back to you when it looks like
you can try your connection. This is the same as the advantage of
using pthread_cond_wait instead of writing your own spin lock.
Luke
On May 20, 2009, at 1:10 PM, Eric Hermanson wrote:
Yes, but even if Reachability says a given host or route is
available, that does not mean it will be available one second
later, for example. You still have to try connecting to the host
and transferring data, and you can still get an 'IO
exception' (so to speak) at any time. I just don't see the
advantage of using the Reachability APIs, and in fact they will
overcomplicate the matter in my opinion. Maybe someone can clear
this up for me.
- Eric
On May 20, 2009, at 4:00 PM, Luke the Hiesterman wrote:
Your approach requires you to keep testing the send if it fails
initially. Using SCNetworkReachability, you can get an
asynchronous callback when your target becomes reachable,
thereby simplifying your code. You could write something to do
that yourself, but then you'd just be reinventing the wheel.
That's why God invented APIs.
Luke
On May 20, 2009, at 12:55 PM, Eric Hermanson wrote:
On the iPhone, what's the point of the network Reachability
APIs, when one can simply open a network socket (or input/
output stream) and observe the EOF notices from the socket to
determine network availability & reachability? In other words,
if a network connection has to be made in the first place, why
not just attempt the network connection via the socket/stream
and see if that is successful, and then also watch for EOF (-1)
return values from the stream to determine when the network is
down?
- Eric
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the
list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com
This email sent to luket...@apple.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the
list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com
This email sent to luket...@apple.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com
This email sent to luket...@apple.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
