Asynchronous image decoding

[FaizanDurrani]

Fixes #860

Notes

This implementation keeps the api as-is. Existing code should work like before. Async-based implementation can be utilised by implementing AsyncImageDecoding instead of ImageDecoding.

There are some quirks that need to be addressed, mainly that autoreleasepool cant be used with async-await syntax, and that "isAsynchronous" flag is practically useless with async-await.

Tests

I didn't create any new tests for this since there's no new image decoder implemented and existing ones should still function like before.

[FaizanDurrani]

I realise that this is basically impossible to do without breaking the existing Cache API.

Something to note is that it would be a good idea to add some form of cancelation token to the decoders. For example, in case you start decoding a bunch of images and the user decides to exit the view.

I will keep this PR open for now, feel free to close this if the Cache API change requires a major version bump.

I havent updated the ImagePipelineCacheTests yet (they fail to compile because of API change), will do it if there's a chance for this PR to be merged.

[kean]

Hey @FaizanDurrani, thanks for the PR!

I also attempted to address #860 as part of my work on v13.0, but couldn't come up with a satisfactory solution. My plan is to make a large subset of the existing APIs async in v14.0.

As an interim solution, I'm happy to ship a new API hidden behind the @_spi attribute to support this use case. I was considering a new ImagePipeline.Delegate method as one option, but I'm not sure how to handle the cache situation. It should have been an asynchronous method from the start, but it is what it is.

If we ship a new API under @_spi, I think it's fine if ImagePipeline.Cache doesn't support it out of the gate and gains support in v14.0 once a more stable version is available.

[FaizanDurrani]

I recently completely switched my image stack to a custom implementation (was moving away from Kingfisher to Nuke but decided it'd be simpler to roll my own, due to my specific requirements) so I no longer need this but I believe an api behind @_spi would benefit anyone with a similar usecase.

To better explain my actual usecase, I dont necessarily need to make a custom image decoder, rather, I needed to transform the raw Data before it was passed to any other decoder (and before being cached) essentially equivalent to decrypting an encrypted image. This transformation was async had to be done after the response had been completely downloaded.

The easiest way to achieve this in Nuke was ImageDecoding but one could argue that this sort of transformation should be done before "decoding". So, might be something you want to maybe consider for the next version.

[kean]

Thank you for the additional context.

The easiest way to achieve this in Nuke was ImageDecoding but one could argue that this sort of transformation should be done before "decoding".

That is something maps to a new ImagePipeline.Delegate method – it's easily extensible. I added willLoadData in v13.0. I can easily see adding didLoadData that would let you verify the request and do some pre-processing.