Saket Narayan
@saket.me
Building Cash App (at S̶q̶u̶a̶r̶e̶ Block) • Android GDE • he/him
🌎 https://saket.me/
📍 Waterloo, Canada
🌎 https://saket.me/
📍 Waterloo, Canada
Yeah as much as I dislike Samsung phones, we owe it to them for Android's popularity.
October 23, 2025 at 3:42 AM
Yeah as much as I dislike Samsung phones, we owe it to them for Android's popularity.
Android Authority says it's not released yet
October 22, 2025 at 5:01 AM
Android Authority says it's not released yet
It's so bad! I was surprised when it was featured on stage.
October 17, 2025 at 9:45 PM
It's so bad! I was surprised when it was featured on stage.
Yeah, the rationale for designing a "unified" user interface has always been a lie. It's very clear our screens were designed with iOS in mind.
September 27, 2025 at 11:48 AM
Yeah, the rationale for designing a "unified" user interface has always been a lie. It's very clear our screens were designed with iOS in mind.
+1. Having immediate access to the entire icon set has been very useful in my side projects. It's sad that we'll have to go pulling them manually from the website.
September 26, 2025 at 9:41 AM
+1. Having immediate access to the entire icon set has been very useful in my side projects. It's sad that we'll have to go pulling them manually from the website.
Hold on, I agree that these are complex problems. All I'm saying is that they're already solved for Swift apps. I wish we had the same convenience on the JVM. :)
September 26, 2025 at 8:09 AM
Hold on, I agree that these are complex problems. All I'm saying is that they're already solved for Swift apps. I wish we had the same convenience on the JVM. :)
Yeah I think I agree with your rationale. I'll take my arguments back for an official AsyncImage() component.
September 26, 2025 at 8:00 AM
Yeah I think I agree with your rationale. I'll take my arguments back for an official AsyncImage() component.
Hmm I don't think that's what I meant. I was referring to the responsibility of _implementing_ windowing APIs.
I do care about Android's lifecycle, but the platform gives me everything I need.
I do care about Android's lifecycle, but the platform gives me everything I need.
September 26, 2025 at 7:20 AM
Hmm I don't think that's what I meant. I was referring to the responsibility of _implementing_ windowing APIs.
I do care about Android's lifecycle, but the platform gives me everything I need.
I do care about Android's lifecycle, but the platform gives me everything I need.
Same thought about window size and position restoration. Developers shouldn't have to care whose responsibility it is. All we know is that it's missing when we compare Compose to Swift for desktop apps.
September 24, 2025 at 12:23 PM
Same thought about window size and position restoration. Developers shouldn't have to care whose responsibility it is. All we know is that it's missing when we compare Compose to Swift for desktop apps.
Honestly, the lines are blurred imo. I see your point, but remote images are such a common enough need that the framework could help. Apple set a nice precedent with SwiftUI with an official AsyncImage() component. Google could/should offer something similar.
September 24, 2025 at 12:23 PM
Honestly, the lines are blurred imo. I see your point, but remote images are such a common enough need that the framework could help. Apple set a nice precedent with SwiftUI with an official AsyncImage() component. Google could/should offer something similar.
Fair enough, I wasn't fully considering the complexity involved.
Still, this feels like yet another compromise when building desktop apps using KMP. 😕
Still, this feels like yet another compromise when building desktop apps using KMP. 😕
September 21, 2025 at 9:55 AM
Fair enough, I wasn't fully considering the complexity involved.
Still, this feels like yet another compromise when building desktop apps using KMP. 😕
Still, this feels like yet another compromise when building desktop apps using KMP. 😕
Would you like to extract your code into a library?
September 19, 2025 at 11:37 PM
Would you like to extract your code into a library?
Oh no, thats awful! I... didn't even know outlets could do that.
September 18, 2025 at 5:37 PM
Oh no, thats awful! I... didn't even know outlets could do that.
Neat! I wish the main window's last size and position were automatically saved by compose multiplatform.
September 18, 2025 at 5:28 PM
Neat! I wish the main window's last size and position were automatically saved by compose multiplatform.
The Pixel phones (and previously Nexus) have made pioneering decisions in the past. This should also be one of them imo.
September 17, 2025 at 5:57 PM
The Pixel phones (and previously Nexus) have made pioneering decisions in the past. This should also be one of them imo.
I'm also on macOS. I was told by one of the engineers that this is a known problem, and they're working on a fix. But… it's been a while.
September 11, 2025 at 7:28 PM
I'm also on macOS. I was told by one of the engineers that this is a known problem, and they're working on a fix. But… it's been a while.
As much as i feel sad about this, i've accepted that salaries are never proportional to a location's cost of living 😔
September 11, 2025 at 3:23 AM
As much as i feel sad about this, i've accepted that salaries are never proportional to a location's cost of living 😔
Gotcha. Don't you have a screen "factory" that can collect these dependencies in one place?
My experience with self contained widgets is a bit limited. In the last two codebases I worked on, we almost always piped the presentation code separately, which made DI simpler for us.
My experience with self contained widgets is a bit limited. In the last two codebases I worked on, we almost always piped the presentation code separately, which made DI simpler for us.
September 2, 2025 at 2:37 AM
Gotcha. Don't you have a screen "factory" that can collect these dependencies in one place?
My experience with self contained widgets is a bit limited. In the last two codebases I worked on, we almost always piped the presentation code separately, which made DI simpler for us.
My experience with self contained widgets is a bit limited. In the last two codebases I worked on, we almost always piped the presentation code separately, which made DI simpler for us.
I'm wondering if you might be doing dependency injection in an uncommon way. Is this because your reusable UI components are self contained in terms of presentation logic? Do they bring their own presenters rather than being wired with a model at the call-site?
August 29, 2025 at 2:57 PM
I'm wondering if you might be doing dependency injection in an uncommon way. Is this because your reusable UI components are self contained in terms of presentation logic? Do they bring their own presenters rather than being wired with a model at the call-site?
What kind of dependencies are you injecting in your UI composables?
August 28, 2025 at 9:09 PM
What kind of dependencies are you injecting in your UI composables?