NETransparentProxyProvider having these two methods:
override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool
override func handleNewUDPFlow(
_ flow: NEAppProxyUDPFlow,
initialRemoteEndpoint remoteEndpoint: NWEndpoint
) -> Bool
During initial days when NETransparentProxyProvider
was introduced,
We used handleNewFlow
to handle NEAppProxyTCPFlow
and handleNewUDPFlow
to handle NEAppProxyUDPFlow
.
Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow?
will this works always or there are some scenario where keeping handleNewUDPFlow will be usefull?
Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow?
Yes and no.
It’s always been fine to use just handleNewFlow(…)
. However, I think you’ve misunderstood the reason behind the deprecation of handleNewUDPFlow(_:initialRemoteEndpoint:)
. It wasn’t deprecated because it’s no longer necessary. Rather, it was deprecated because it works in terms of legacy types. It’s replacement is handleNewUDPFlow(_:initialRemoteFlowEndpoint:)
, which works in terms of Network framework’s standard NWEndpoint
type.
So:
-
If you need the initial remote endpoint, implement that new method.
-
And if you have to support old systems, you’ll need to implement the old method too.
-
If you don’t need the initial remote endpoint, it’s fine to do everything in
handleNewFlow(…)
.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"