It doesn’t seem like there’s any high level, first-party documentation on how to use what is the recommended API for executing networking logic that you otherwise wouldn’t use URLSession for; which is a lot of things.
There’s a sample app, and docs on how to choose the right network API in general, but apparently no high level API docs for Network.framework itself. Am I missing something? How do people learn to use this? Know which classes to use? Know the various ways it can be configured?
Am I missing something?
No. Network framework has good API-level documentation [1] but it’s rather lacking when it comes to introductory material.
There are, however, a few helpful samples. I’ve just updated Networking Resources with links to them. And that has a lot of other helpful links besides.
I’ve also answered a tonne of Network framework questions here on the forums, so it’s always worth searching here.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Although in some cases you’ll find critical titbits in the doc comments in the C headers.
@DTS Engineer Thanks for the reply. One confusion I have is in the TicTacToe sample app. In the PeerListenerViewController whenever the user opts to host a game they create a 'bonjour' type NWListener. Which makes enough sense to me. But in viewDidLoad() they always create an 'application service' NWListener which appears to be never used. Just trying to figure out the significance of this and if it's something I should be doing.
Also CMIIW, but it seems like the messages aren't received through the NWListeners, but through the NWConnections even for the runtime that establishes the 'bonjour' NWListener. I would've thought that the bojour listener communicates through that and the client the NWConnection but it seems like the listener is just used for setting up the connection, at which point they both use the connection objects.
The sample shows two different things:
A Bonjour listener
An application services listener
The first is the most general one. The second is specific to DeviceDiscoveryUI, which allows the app running on tvOS to easily connect to an instance of the app running on iOS, iPadOS, and watchOS.
In reality, most real apps do one or the other, not both. So, unless your specifically concerned with the tvOS case, I recommend that you ignore all the application services stuff.
it seems like the listener is just used for setting up the connection
Yes. You have a listener that ‘vends’ connections and you do all your I/O on the connections.
This is a common idiom in networking APIs. For example, in BSD Sockets you have a listening socket that ‘vends’ connection sockets via the accept system call.
Network framework uses different types for these two things because they have very different semantics. In BSD Sockets you can call send on a listener socket, and that won’t do anything useful. But in Network framework, with its separate listener and connection types, we added the send and receive APIs as methods on the connection type only.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.
Is it in the documentation that an application service listener is specific to DeviceDiscoveryUI?
Probably not. Our docs generally focus on what’s possible rather try to list all the things that impossible.
The application services concept is interesting because it has a very small public API surface — just DeviceDiscoveryUI basically — but it’s used for a lot of other things internally. It’s not hard to imagine that balance changing in the future but, right now, we only get to use what’s available.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
