views:

524

answers:

1

I noticed that many times while developing for an iPhone 3G, BSD socket functions will simply fail. I also noticed at the time, the 3G antenna wasn't even ON, nor was there WIFI Access to back up the network call (So it seems ridiculous that it doesn't turn on to support the network request).. This information was verified with an app from Apple in the SDK called Connectivity Test, or something of the sort.

Basically if you load Safari or something, then quickly load up the App it would be fine.. Of course that's not ideal. Apparently, to apple, gethostbyname() or something of the sort is by no means a reason to turn on the Antenna.

I contacted Apple about this, and they said that the BSD functions do not switch the Antenna on, but calling all of the Objective-C CFNetwork functions do. I want portable code, so is there a way to keep my existing BSD setup? I really dislike coding in Objective-C, so if anyone knows a work around, that would be awesome.

+5  A: 

The CFStream Socket Additions are what Apple recommends you use instead of the direct BSD sockets. They specifically warn about using the BSD sockets here:

Although BSD (POSIX) networking APIs are available in iPhone OS, you should avoid using them. If you communicate directly with sockets, certain networking capabilities of iPhone OS, such as VPN On Demand, do not work. Use the APIs provided in CFStream Socket Additions instead.

Note that CFNetwork and the like aren't Objective-C, but straight C for almost everything.

Brad Larson
I wonder why they omitted the fact that it doesn't turn on the ant.
Kyle
CFNetwork it is, then!.. Then back to standards for everyone else, lol.
Kyle
@Kyle: To be fair, can you use your BSD socket code as-is on Android, WebOS, or Windows Phone 7 Series? It tends to be hard to make elements like this truly platform independent (as opposed to data model or core logic code).
Brad Larson
Android NDK and WebOS PDK yea, however I think 7 series will give developers alot of porting to do with all the managed code and .NET libraries. I'm not sure if they'll allow for DLL lookups or not, but I would suspect we're in for a nightmare with that.
Kyle