-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider providing Jetpack Compose support #2203
Comments
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. |
Wouldn't it be best to leave a note in the readme, that Picasso is effectively in an abandoned/archived state? I just read about "Picasso 3" in a medium article and thought to myself "Why not look into it? Could be a great alternative to coil." A quick google search returned close to zero results, so I'm glad I could finally find your statement here @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. |
Maybe it would be more helpful to include a brief comparison of Picasso to Coil/Glide/etc, to help people looking starting green-field projects make informed choices. Not sure if we could do that without it becoming a maintenance burden. |
I just realized Accompanist did have Picasso support at one point, but it was pulled for reasons: google/accompanist#253 |
Looks like #2295 added support for Compose 🎉 |
The coil does micro freezing, so I decided to try using Picasso. It works fast now.
|
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:
RequestCreator
, or some way to just provide aRequestCreator
to the composable? SinceRequestCreator
is a mutable, non-compose-stable type, we can't just pass aRequestCreator
instance to a composable function.error
/placeholder
overloads that take composable functions?Picasso
instance to be passed in, or should we allow one to be provided through aCompositionLocal
? 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.
The text was updated successfully, but these errors were encountered: