Consider providing Jetpack Compose support

The current state-of-the-art for image loading in Compose apps is the Accompanist library, which provides a Compose wrapper around Coil and Glide APIs. We still use Picasso heavily internally though, so it might make sense to add Compose support directly to Picasso, at least if it’s not too much trouble.

Open questions

I don’t have strong opinions on the API yet, but there are some questions that we need to answer:

1. Should we even bother? Or just start using Coil instead? Coil is a great library, it provides (nearly all, and even some more) the features of Picasso, it’s extensible, etc. There’s also Kamel which even supports Kotlin multiplatform.
2. Assuming we want to support it, should it ship as part of the core Picasso artifact or a separate, compose-specific support artifact?
3. Some of the Picasso APIs expose drawables. Drawables are not support in Compose, so how should the Compose integration handle them?
   • The simplest thing to do would probably be just host an Android View inside the composition to render drawables.
   • Accompanist actually provides an internal-only implementation that even supports animated drawables. Not sure we want to maintain that much code.
4. How much of the existing API should be reused? E.g. should we provide a Composable function that takes all the parameters that can be configured on a RequestCreator, or some way to just provide a RequestCreator to the composable? Since RequestCreator is a mutable, non-compose-stable type, we can’t just pass a RequestCreator instance to a composable function.
5. Should we provide error/placeholder overloads that take composable functions?
6. Should the composable require an explicit Picasso instance to be passed in, or should we allow one to be provided through a CompositionLocal? This question might not matter depending on the answer to (4).

There are probably more questions to be asked, feel free to edit this description or add them in the comments.

[JakeWharton]

Nobody works on Picasso. If you want something in the next N years definitely use Coil. Or Glide. Or whatever. They’re all fine.

Image loading is a terrible, horrible business to be in. It’s been really nice not being in that business for the last few years. I don’t see a reason to resume. I certainly have no intent to support it anymore. Picasso accomplished its goal of moving the ecosystem out of the painful image loaders of 2011/2012 to the fluent and extensible ones we know today. But it’s filled with technical debt and the legacy of poor design (at least, in hindsight) and is currently very, very stuck between a major refactor and redesign with no end in sight.

[JakeWharton]

Sure. I mean nobody wants to write that because no one intends to let a library languish. But really Picasso is in a stable state. It is not abandoned or archived. Tens of thousands of apps rely on it in production and if something serious comes up it will be looked at. It’s just not undergoing active development.