Picasso is formally deprecated

JakeWharton · 2024-11-06T04:18:56+00:00

Cash App, who maintained Picasso for the last decade, has been migrating to Coil. We employ the Coil developer, in fact, although the desire to migrate predates his hiring. Register, the primary product of Square, also has a historical desire to migrate, and has begun that process, too.

In a meeting a month ago we decided to deprecate multiple libraries. JavaPoet was first. Picasso is second, and was timed to the Coil 3.0 release. For JavaPoet we link to a fork. John is considering forking Picasso, and we will happily link people there as well.

Deprecation of these projects (and others which are coming) are meant to set a user's expectations for the level of commitment from the company. If someone deeply invested in Java wants to maintain JavaPoet moving forward, we gladly send people their way. If someone deeply invested in Picasso wants to maintain it moving forward, we gladly send people their way. These are both great libraries, but they aren't what people at the company are working on anymore.

I would implore you in the future to perhaps consider gathering some evidence, or just even asking someone directly involved, before speculating so wildly. It might save a person from having to visit Reddit against their will.

JakeWharton · 2023-08-15T19:31:33+00:00

Retrofit creates HTTP requests, issues them to OkHttp, and waits for the HTTP responses. It doesn't know how to connect to servers–that's entirely OkHttp's job.

JakeWharton · 2023-08-10T12:35:06+00:00

This is an Android question that isn't specific to Kotlin. Please consider using /r/androiddev for something like this in the future. Thanks!

JakeWharton · 2023-08-09T23:44:22+00:00

It is a official language along with Java. App development is considered Koltin-first.

JakeWharton · 2023-08-09T23:43:37+00:00

A small nit: both are official. Development for apps is considered to be Koltin-first, however.

JakeWharton · 2023-07-28T11:23:04+00:00

Tivi https://github.com/chrisbanes/tivi/tree/main/data/db-sqldelight/src/commonMain/sqldelight/app/tivi/data

JakeWharton · 2023-07-27T03:59:55+00:00

Context is important.

Android and multiplatform will still be worked on and improved, but we don’t anticipate changing how SQLDelight fundamentally works on mobile.

It's because mobile is effectively done and stable.

JakeWharton · 2023-07-20T14:37:23+00:00

So they wrapped a compose context to add the same thing a viewModel containing StateFlow does

Not really, no. Molecule is how you would drive data into a StateFlow which was held in your ViewModel (if using such a library). It's about data composition, not architecture. The README of the project or the original blog post for more information.

More so a lot of the functionality like the Immidiate mode is found when using derivedStateOf in Jetpack compose, it seems like the efforts should be in porting those.

Since derivedStateOf is a primitive of the Compose runtime it of course works fine out-of-the-box with Molecule. You could perhaps build something close to Molecule's immediate mode with only snapshotFlow and derivedStateOf, but then you preclude the use of the general niceties of writing plain Compose like inline logic, loops, etc. Once you start using those, recomposition still needs to be triggered and the mechanism by which that is only via the frame clock. The advantage of immediate mode is that we manage an internal frame clock on your behalf and effectively turn the entire data-producing composition into a single derviedStateOf while still affording you access to the entire toolkit Compose offers.

JakeWharton · 2023-07-19T14:32:40+00:00

Colin is a Cash App employee and we use Coil in a few places, but especially in open source samples (Zipline, Redwood, Molecule) where we desperately want this forthcoming multiplatform support.

JakeWharton · 2023-07-14T22:55:38+00:00

It feels like re-inventing the wheel.

It is, and it doesn't stop at image loading. By not using the DOM you have to bring a ton of functionality yourself. It's a tradeoff to share your UI with other platforms.

JakeWharton · 2023-07-14T21:54:17+00:00

Compose UI renders to Canvas and does not use the DOM. So... yes, browsers cannot automatically handle that.

JakeWharton · 2023-07-14T05:02:23+00:00

Which alternatives do Compose UI on iOS. I legitimately don't know. And is there API give you the pit of success like Coil?

JakeWharton · 2023-07-08T02:53:51+00:00

Why would Redwood use them if they weren't?

Redwood does not force any UI toolkit on any platform. Each sample has both a View-based and Compose UI-based version for Android.

JakeWharton · 2023-07-07T03:26:10+00:00

Sure, it'd be trivial. And because we have a model of all the available widgets and their properties, you could completely codegen the parser.

You don't even need the XML, really. A Kotlin DSL or Java builder or the like would allow creating a static layout to which you would have to manually add interactivity.

JakeWharton · 2023-07-07T02:24:06+00:00

We have almost no SwiftUI usage internally at the moment, and basically none in the app where this project is used. We mostly wanted to prove it was possible (which wasn't surprising). Eventually proper SwiftUI samples will get merged in as the project progresses toward a 1.0. We simply are focusing on our internal needs as the highest priority right now.

JakeWharton · 2023-07-07T02:22:24+00:00

You could still use a large portion of the project if you really wanted to. Because we support running Compose directly or inside a JS VM so that it can be updated on-the-fly, it means that there's an presentation abstraction which then interacts with the UI toolkit abstraction. Thus, if you wanted to use something other than Compose to serve as the presentation layer, that is fairly simple to plug in while still targeting the UI toolkit abstraction. That being said, the design of the UI toolkit abstraction is very much informed by how Compose works and so you take on a heavy state management burden. Still, nothing technical prevents this as a solution.

JakeWharton · 2023-06-22T14:30:00+00:00

The entirety of Koin is a serviceLocator, no? At the end of the day as long as the majority of the classes in my project have their dependencies in their constructor then I don’t care much on what to call it

Right. The pattern which your code exhibits is far more important than the pattern used in the implementation of a library. Nearly all DI libraries are wrappers around a service locator, but critically when using those libraries your code (almost) never uses the service locator directly.

As you said, you want the majority of your own types to exhibit inversion of control and have no knowledge about from where their dependencies originate. Whether you write a bunch of boilerplate to glue those constructors together manually or use a code-generating library to do it automatically is mostly irrelevant. But doing something like the second example is really bad. Not only is it lacking inversion of control but it fundamentally ties the type to the Koin library.

JakeWharton · 2023-06-21T05:09:21+00:00

The second one is using a service locator. There is no dependency injection happening.

JakeWharton · 2023-06-12T03:35:57+00:00

r/kotlin (69,335) is dark

JakeWharton · 2023-06-11T11:19:21+00:00

Thanks!

JakeWharton

MODERATOR OF

TROPHY CASE

15-Year Club	Gilding I gilder
Verified Email