On Fri, Jan 29, 2010 at 2:37 PM, Jens Alfke wrote:
>
> On Jan 29, 2010, at 11:12 AM, Laurent Daudelin wrote:
>
>> I was able to determined that when the connection is down, I found out that
>> kSCNetworkFlagsConnectionRequired was true, so it seems to work. It's just
>> difficult to determine wh
On Jan 29, 2010, at 11:12 AM, Laurent Daudelin wrote:
> I was able to determined that when the connection is down, I found out that
> kSCNetworkFlagsConnectionRequired was true, so it seems to work. It's just
> difficult to determine what exactly the flags mean.
This can be confusing. Connecti
On Jan 28, 2010, at 22:38, Jens Alfke wrote:
>
> On Jan 28, 2010, at 9:22 PM, Laurent Daudelin wrote:
>
>> host = CFHostCreateWithName(kCFAllocatorDefault, (CFStringRef)hostName);
>> assert(host != NULL);
>>
>> SCNetworkReachabilityRef target =
>> SCNetworkReachabilityCreateWithN
On Jan 28, 2010, at 9:22 PM, Laurent Daudelin wrote:
>host = CFHostCreateWithName(kCFAllocatorDefault, (CFStringRef)hostName);
>assert(host != NULL);
>
> SCNetworkReachabilityRef target =
> SCNetworkReachabilityCreateWithName(NULL, [hostName
> cStringUsingEncoding:NSUTF8Str
I may have missed it, but I think that an essential point about the
Reachability API has been left unmentioned: The OS Reachability API
does its work without annoying the user -- something that is quite
difficult to guarantee with roll-your-own versions. Believe it or not,
there are still d
On May 20, 2009, at 2:03 PM, Eric Hermanson wrote:
I think that's precisely my point. If I have to manage the data
transfer mechanism independently of the Reachability APIs in the
first place, then that was why I asked the question, why use the
Reachability APIs at all? I guess that was th
Fair enough. My application is so network intensive that I really
don't have the luxury of having a bad network connection in the first
place. If we want to talk APIs, I wish Apple would provide Cocoa APIs
for things like socket timeout and reconnecting a socket that may have
lost its con
On Wed, May 20, 2009 at 4:56 PM, Eric Hermanson wrote:
> I'm not so sure it's poppycock. The asynchronous IO APIs all do the work in
> a background thread (or a 'simulated' background via a run loop). Either
> way the IO is not blocking the main application thread when it is working.
> So I don
I think that's precisely my point. If I have to manage the data
transfer mechanism independently of the Reachability APIs in the first
place, then that was why I asked the question, why use the
Reachability APIs at all? I guess that was the basis for my original
post. Sure, Reachability
Ok, so you write your implementation to simply send the first bit of
data repeatedly in some background thread. If that first send ever
succeeds, does that guarantee the next one will? No, it does not.
There's no way you can write anything that guarantees that at any
given moment that a sen
I'm not so sure it's poppycock. The asynchronous IO APIs all do the
work in a background thread (or a 'simulated' background via a run
loop). Either way the IO is not blocking the main application thread
when it is working. So I don't think the concept that correct IO is
IO that is done
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
We have an app with a UISwitch that we show/hide depending on if there
is a WiFi network available or not. Since its a simple delegate call,
it makes it easy.
On May 20, 2009, at 2:55 PM, Eric Hermanson wrote:
On the iPhone, what's the point of the network Reachability APIs,
when one can s
On Wed, May 20, 2009 at 4: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.
Poppycock. Why do you think non-blocking synchronization primitives exist?
> So waiting on a blocking socket until it times
> out o
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 rat
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
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 inste
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
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 t
19 matches
Mail list logo
