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
Hello.
Earlier this week, I asked how I could determine network reachability from my
app. Someone replied to check the SystemConfiguration framework. I finally got
around to have a look and wrote the following code:
+ (BOOL)hostIsReachable:(NSString *)hostName
{
CFHostRefhost
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
x27;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 a
u'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
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
s 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
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 on
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
ourself, 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)
;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
ourself, 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
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 & reachabil
nting 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 sock
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 ma
21 matches
Mail list logo
