Implementing URLSessionDelegate, URLSessionTaskDelegate, URLSessionDataDelegate, and URLSessionDownloadDelegate be like

I might need the joke to be explained to me :)

@Lensflare Sorry, it’s very apple specific. some years ago apple introduced a “better way” of making network requests. but it’s not better.

@BellAppLab I‘m very familiar with Apple development and I know the old delegate pattern. That‘s why I was wondering what the joke was.

Oh and it IS better now.

@Lensflare alright. The rant is on. So if you want a one liner, you have to use a default configuration, but if you want to handle background fetch, then you must use a delegate. That’s already to parts of the code that do the same shit.

The session holds a strong reference to the delegate so you can’t have the session be its own delegate. And if the session is invalidated the delegate is released. So that’s “nice”.

Ephemeral sessions don’t call the delegate. Why? Who knows?

Why are all these the same class instead of different structures? ¯\_(ツ)_/¯

Then the delegates are just…. So. Many. Delegate. Methods. Which again, may not be called if you’re not in the background, so you also have to support some of that logic at the request level. Again, duplicated code.

You can’t really subclass the session because it doesn’t have a designated initializer. Much wow.

If you want to do a simple request with bearer token authentication, that is so much overkill.

@BellAppLab most if not all of your points have already been improved. You can use async/await api now and skip all the delegates.

@Lensflare for background fetch?

@BellAppLab not sure about that. Haven’t used it for a very long time.