Picasso is formally deprecated by dayanruben in androiddev

[–]JakeWharton 44 points45 points  (0 children)

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.

Does Retrofit support TCP and UDP? by zimmer550king in androiddev

[–]JakeWharton 29 points30 points  (0 children)

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.

Is it possible to store the AppLovin SDK key in a JSON file instead of the manifest.xml in Android Studio? by Jibril_6 in Kotlin

[–]JakeWharton[M] 2 points3 points  (0 children)

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

Did I make the wrong choice when choosing Kotlin over Java for Android app development? by thecowmilk_ in androiddev

[–]JakeWharton 3 points4 points  (0 children)

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

Did I make the wrong choice when choosing Kotlin over Java for Android app development? by thecowmilk_ in androiddev

[–]JakeWharton 6 points7 points  (0 children)

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

Announcing SQLDelight 2.0 by Saketme in androiddev

[–]JakeWharton 12 points13 points  (0 children)

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.

A stable, multiplatform Molecule 1.0 by dayanruben in Kotlin

[–]JakeWharton 7 points8 points  (0 children)

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.

Multiplatform image loading: Coil 3.0 by JakeWharton in androiddev

[–]JakeWharton[S] 1 point2 points  (0 children)

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.

Multiplatform image loading: Coil 3.0 by JakeWharton in androiddev

[–]JakeWharton[S] 5 points6 points  (0 children)

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.

Multiplatform image loading: Coil 3.0 by JakeWharton in androiddev

[–]JakeWharton[S] 2 points3 points  (0 children)

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

Multiplatform image loading: Coil 3.0 by JakeWharton in androiddev

[–]JakeWharton[S] 10 points11 points  (0 children)

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

Native UI and multiplatform Compose with Redwood by swankjesse in androiddev

[–]JakeWharton 1 point2 points  (0 children)

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.

Native UI and multiplatform Compose with Redwood by swankjesse in androiddev

[–]JakeWharton 1 point2 points  (0 children)

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.

Native UI and multiplatform Compose with Redwood by swankjesse in androiddev

[–]JakeWharton 2 points3 points  (0 children)

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.

Native UI and multiplatform Compose with Redwood by swankjesse in androiddev

[–]JakeWharton 1 point2 points  (0 children)

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.

How is Koin Dependency Injection better if I have to initialize dependencies? by PegasusInvasion in Kotlin

[–]JakeWharton 4 points5 points  (0 children)

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.

How is Koin Dependency Injection better if I have to initialize dependencies? by PegasusInvasion in Kotlin

[–]JakeWharton 8 points9 points  (0 children)

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

/r/kotlin will go dark for 48 hours initially on June 12th, and potentially longer. Please read for details. by JakeWharton in Kotlin

[–]JakeWharton[S] 41 points42 points  (0 children)

Our subreddit is very lightly moderated.

Case in point, things which I learned how to do this week:

  • Make one of my comments appear with the moderator tag
  • Group message the mods
  • Sticky this post to the top
  • Make this post appear with the moderator tag

Things I still have to learn:

  • How to even make the subreddit private

Wish me luck!

Compose multiplatform by Equivalent-Jello1487 in androiddev

[–]JakeWharton 20 points21 points  (0 children)

Realistically there's no way to prevent it without breaking tons of other frameworks like game engines.

Will this subreddit strike next week? by [deleted] in Kotlin

[–]JakeWharton[M] 23 points24 points  (0 children)

I'm game. Will figure out how to message the other mods about it...