Cut avoidable main-thread work in the Compose details screens - #879
Conversation
TrackersFragment.buildScreenModel() ran a PackageManager queryIntentActivities IPC for the browser warning on every toggle, expand and refresh, though the result depends only on the app id and install type; it is now computed once per fragment lifetime. Category blocked state was re-queried from TrackerBlocklist per row sharing the same category; it is now looked up once per category per render. TimelineScreen no longer MD5-hashes its LazyColumn key strings: the prefixed identity strings are already unique and stable. Fixes #872 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bc26b0fb51
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (browserWarning == null) { | ||
| Intent urlIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("https://www.wikipedia.org/")); | ||
| urlIntent.setPackage(mAppId); | ||
| browserWarning = Common.isCallable(context, urlIntent) && !Util.isPlayStoreInstall(); |
There was a problem hiding this comment.
When the inspected app is updated or one of its browser activities is enabled or disabled while this fragment is stopped but retained, queryIntentActivities can return a different result even though mAppId is unchanged. onResume() refreshes the model, but this nullable cache is never cleared—even during view recreation—so the browser warning remains stale until a new fragment instance is created; invalidate the cache when returning to the screen or when package state changes.
Useful? React with 👍 / 👎.
The inspected app can gain or lose browser activities while this screen is stopped (app update, component toggled), so the cached queryIntentActivities result is refreshed once per resume rather than held for the fragment's lifetime. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Fixes #872 with the targeted, no-restructure wins — the full-rebuild render design stays, per the issue's caution against speculative restructuring:
TrackersFragment.buildScreenModel()ran aPackageManager.queryIntentActivitiesIPC (the browser-warning check) on every toggle, expand and refresh tick. The result depends only on the app id and install type, so it is now computed lazily once per fragment lifetime.TrackerBlocklistonce per section row and once per company row sharing the same category — O(rows) synchronized lookups per render. It is now looked up once per category per render and threaded into the row builders; the per-company blocking-key lookup is unchanged, and the map is rebuilt every render so toggles are reflected immediately.TimelineScreenno longer MD5-hashes (UUID.nameUUIDFromBytes) itsLazyColumnkey strings on every 30-second rebuild: the prefixed identity strings (section:,entry:,contact:) are already unique and stable.Behaviour is unchanged — the same booleans reach
TrackerStatusLogic.resolveand the row constructors, and key identity semantics are preserved.Verified:
:app:compileGithubDebugJavaWithJavac,:app:testGithubDebugUnitTest,:app:lintGithubDebugall pass.🤖 Generated with Claude Code