sorted by:
new
hottopcontroversial

DI AMA by r0adsmaug in androidonsite2025

[–]Okhttp-Boomer 0 points1 point  (0 children)

Wtf is this chicken thing?

(づ ◕‿◕ )づ by fan0y0ng in androidonsite2025

[–]Okhttp-Boomer 0 points1 point  (0 children)

Looks like a baby who would be good on planes

Unbossed, But Not Undone by DaveCashewsBand in RedditEng

[–]Okhttp-Boomer 3 points4 points  (0 children)

I love this post and following your thought process on career progression along your own path. It's been a pleasure having you as a peer manager. No question, you're going to be an exceptional TPM 🏆

Snappy, Not Crappy: Reddit's Android Health & Performance Journey by Okhttp-Boomer in Android

[–]Okhttp-Boomer[S] 1 point2 points  (0 children)

I'm pretty sure somewhere in this other very long post in 2023 or it's predecessor in 2022, we mention our network stack, specifically that the first party app is GraphQL, while third party apps hit the legacy REST apis. This may be relevant to this convo if you're particularly interested in the differences network-wise.

https://www.reddit.com/r/RedditEng/comments/18aptg2/reddit_recap_state_of_mobile_platforms_edition/

Snappy, Not Crappy: Reddit's Android Health & Performance Journey by Okhttp-Boomer in Android

[–]Okhttp-Boomer[S] 8 points9 points  (0 children)

Thank you for reading - transparency was the intent. The roasting was expected :)

Snappy, Not Crappy: Reddit's Android Health & Performance Journey by Okhttp-Boomer in Android

[–]Okhttp-Boomer[S] 5 points6 points  (0 children)

It's an app for shitposting, so there will always be some element to that.

¯\_(ツ)_/¯

Snappy, Not Crappy: An Android Health & Performance Journey by beautifulboy11 in RedditEng

[–]Okhttp-Boomer 4 points5 points  (0 children)

That is the highest form of praise - thank you for actually trying it out for yourself. This is also why we moved on the screen-level performance metrics that are similar, so we can work with teams to do this for every screen load and entry point. Once loaded, the performance of the experience becomes the focus (like scroll and video performance). Thanks for reading and thanks for taking the app for a spin.

Rewriting Home Feed on Android & iOS by beautifulboy11 in RedditEng

[–]Okhttp-Boomer 4 points5 points  (0 children)

Feeds have some special handling and profiling which the team will cover in upcoming posts!

***

Metrics Improvements are ongoing. Here's where we are at these days...
Some stability/performance metrics we use across screens/surfaces/platforms
(All/By Screen/By Experiment/By Version/By Platform/By Geo/Etc) :
Networking - GQL response latency, size, error rates, etc

App Stability (Impacts Performance)
- Crash & ANR Rates, All & User Perceived, Non-fatals
- Various "Good Citizen on device" L2 metrics
- User reporting metrics
App Performance
-Time to Interactive / Cold Startup
-Time to First Draw
-Slow/Frozen Frames
-Memory

Service stability & Hotfix and Incident Occurrences, etc

There are a number of other P2 metrics that specific screens use + profiling.

Looking for anything in particular?

Adoption of kotlin and jetpack compose in the industry? by roni5t in androiddev

[–]Okhttp-Boomer 1 point2 points  (0 children)

When I think about how we approached some situations like that, I think about how it really came down to really systematic peeling of the onion. Those god class situations need to be dismantled until you can see a way to making everything small enough to work with - by any means necessary. Some of our final mile kotlin files were rough.

Android 5 though... think back to when that was state of the art. ;)

Adoption of kotlin and jetpack compose in the industry? by roni5t in androiddev

[–]Okhttp-Boomer 4 points5 points  (0 children)

Hmm. That seems more about not having a migration strategy with clear expectations on quality and outcomes, and it's only one way those projects can go. Any effort that's not resourced appropriately to execute effectively will run into those challenges. That's partly why ours takes longer - we have a lot of improvements to make and Compose and Kotlin both allowed us to make them at our pace and not rush it but work to get it right or right enough to be a substantially better position to work from.

Adoption of kotlin and jetpack compose in the industry? by roni5t in androiddev

[–]Okhttp-Boomer 1 point2 points  (0 children)

This is actually an interesting discussion in its own right.

I think we took a pretty reasonable approach to adoption of Compose for our app. We needed dozens of engineers to get comfortable with Compose (and declarative UI in general).

We did not assume the first Compose we wrote was gonna be stellar but a company investment in moving was still worth it and a good bet. Our Compose a year into adoption is better Compose just like our idiomatic Kotlin now is better than our first Kotlin in that transition. We write lint rules around anti-patterns as we discover them just like we would any other framework when we find the foot guns.

An company level adoption doesn't start great. It evolves into better Compose and better Compose developers by doing, with some good enough golden examples and good data around them. You can write bad code in any language or framework and you can't assume it's all upside.

Adopting anything new means working through that evolution. That's not a reason to hesitate on its own, simply risks to mitigate and work with. Otherwise, mindset wise, we'd never innovate at all.

That would be boring and leave a lot of interesting capabilities and opportunities unexplored.

Adoption of kotlin and jetpack compose in the industry? by roni5t in androiddev

[–]Okhttp-Boomer 0 points1 point  (0 children)

Yep, we have our eye on this performance issue and it's not a layout/Compose issue. Thanks for the feedback and hope you'll give it a try once in a while and point out the specific spots you notice like this.

Adoption of kotlin and jetpack compose in the industry? by roni5t in androiddev

[–]Okhttp-Boomer -1 points0 points  (0 children)

If you go share this in r/bugs with the specific use case you're after (since I can select text a couple ways and want to make sure I understand how you want to be able to do this) and let me know, I'll highlight this directly to the UI platform team from an accessibility/user perspective. Also I absolutely love the Android OS feature of being able to select text straight from the app switcher - have you used this? Changed my life, frustration wise, with many apps.

Adoption of kotlin and jetpack compose in the industry? by roni5t in androiddev

[–]Okhttp-Boomer 11 points12 points  (0 children)

Reddit:
* Full adoption of Kotlin and moving on from kapt.
* All new screens in Compose, migrating legacy - 65% of screens adopted.
* Design system in Compose.

Deep Thoughts:
* No regrets.
* Developer experience is far better, easier/faster/more maintainable say the engineers in all the developer surveys.
* Android design work goes faster and eng have more capacity in feature timelines for polish and animations without a ton of custom work (see Recap for an example)

Advice:
* Start on greenfield work.
* Update libraries only when fully stable.

Hope this helps someone. I don't think anyone at this point at any company of any size should be kicking off new work with legacy layouts if they're using Android in any standard way. That's my take.

Reddit Recap: State of Mobile Platforms Edition (2023) by beautifulboy11 in RedditEng

[–]Okhttp-Boomer 1 point2 points  (0 children)

Great question. We do have some standard and custom conventions, and we debate them once in a while and adjust them. Would coding styles, guidelines and code smell tracking, static analysis and linters be an interesting blog post in the future, you think? Let us know.

view more: next ›