fix(notify): open the activity view when an alert is tapped

[TimeToBuildBob]

Problem

#225 attached a MainActivity PendingIntent, so tapping an activity-time alert no longer did nothing. It still opened dashboard home (http://127.0.0.1:5600) rather than the Activity view.

Fix

• Pass EXTRA_OPEN_ACTIVITY_VIEW on the existing NotifyWorker PendingIntent
• FLAG_ACTIVITY_SINGLE_TOP so a running MainActivity gets onNewIntent instead of stacking
• Load the same URL as the drawer Activity item (/#/activity/unknown/)
• Honor the extra after process death (savedInstanceState restore) and consume it so rotation does not reload the WebView

#234 also edits NotifyWorker.kt, but only parseCategorySeconds. This PR only changes sendNotification. Should merge cleanly.

Fixes #224

[greptile-apps]

Greptile Summary

The PR routes activity-time notification taps to the dashboard Activity view while safely handling cold starts, resumed activities, stopped activities, and process restoration.

• Adds a shared Activity-view route and intent extra.
• Delivers notification taps through onNewIntent for existing MainActivity instances.
• Navigates immediately when resumed and defers stopped-instance navigation until onResume.
• Adds unit coverage for URL selection and lifecycle routing decisions.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the unsafe stopped-instance commit is deferred until onResume, while resumed notification taps now navigate immediately.

Important Files Changed

Filename	Overview
mobile/src/main/java/net/activitywatch/android/MainActivity.kt	Adds lifecycle-aware intent handling and shared Activity-view navigation without leaving either previously reported lifecycle failure reachable.
mobile/src/main/java/net/activitywatch/android/workers/NotifyWorker.kt	Adds the Activity-view extra and single-top delivery flag to the existing notification tap intent.
mobile/src/test/java/net/activitywatch/android/MainActivityNavigationTest.kt	Covers destination URL selection and the resumed-versus-deferred navigation decision.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  N[Activity-time notification tapped] --> M{MainActivity instance exists?}
  M -- No --> C[Cold start in onCreate]
  C --> A[Open Activity view and consume extra]
  M -- Yes --> I[Deliver through onNewIntent]
  I --> R{Activity resumed?}
  R -- Yes --> A
  R -- No --> D[Retain extra until onResume]
  D --> A

Loading

_{Reviews (3): Last reviewed commit: "fix(notify): handle taps while activity ..." | Re-trigger Greptile}

[TimeToBuildBob]

🤖 AI code review

Adds EXTRA_OPEN_ACTIVITY_VIEW extra to notification intents and loads the activity view URL in MainActivity when present. Refactors fragment creation into showWebUi, adds onNewIntent to set the new intent without committing fragments, and updates NotifyWorker to set SINGLE_TOP and the extra.

Confidence Score: 3/5 — One P1 finding

1 finding · ❌ **1** P1 — 🛑 **1 at P0/P1**

❌ P1 high — mobile/src/main/java/net/activitywatch/android/MainActivity.kt:173

When MainActivity is already in the foreground (resumed) and a notification is tapped, the system delivers the new intent via onNewIntent without calling onResume again. Since this PR processes EXTRA_OPEN_ACTIVITY_VIEW only in onCreate (cold start) and onResume (line 173), the extra is never consumed and the activity view does not open. The comment in onNewIntent (lines 143-144) claims commit() would throw, but onNewIntent can be called while the activity is resumed, so a fragment transaction is safe. The fix is to handle the extra in onNewIntent, e.g., by replacing the fragment immediately when the activity is in the resumed state, or setting a flag to be processed in a later lifecycle callback that is guaranteed to run.

In onNewIntent, after setIntent, check if the activity is in the RESUMED state and if so call takeOpenActivityView(intent) and showWebUi(activityViewUrl(), replace = true) directly; otherwise let onResume handle it. For example: if (lifecycle.currentState.isAtLeast(Lifecycle.State.RESUMED) && takeOpenActivityView(intent)) { showWebUi(activityViewUrl(), replace = true) }

_{How this was verified: Traced the lifecycle: onResume's takeOpenActivityView(intent) is the only other consumer; with the extra gone, it returns false and skips showWebUi(replace=true). The saved instance state path (savedInstanceState != null) returns early in onCreate without adding a fragment, so the restored fragment is whatever the user had navigated to.}

_{Consensus: 3/3 passes agreed}
Distinct keys: 1 (general)

Files changed (3) — the diff as I read it

• mobile/src/main/java/net/activitywatch/android/MainActivity.kt — Adds activityViewUrl and initialWebUiUrl helpers, moves fragment creation into showWebUi, and processes EXTRA_OPEN_ACTIVITY_VIEW in onCreate and onResume.
• mobile/src/main/java/net/activitywatch/android/workers/NotifyWorker.kt — Adds EXTRA_OPEN_ACTIVITY_VIEW extra and FLAG_ACTIVITY_SINGLE_TOP to the notification's PendingIntent.
• mobile/src/test/java/net/activitywatch/android/MainActivityNavigationTest.kt — Adds tests for initialWebUiUrl default and activity-view cases.

Previous review passes

commit	score	findings	engine	when
0a2738d9829f	3/5	1	llm	2026-08-27 15:43 UTC

_{Reviewed e79abeca4145 · openrouter/deepseek/deepseek-v4-flash-0731 · llm engine · 253s · about this reviewer}

_{Maintainer commands}

_{@TimeToBuildBob review (own line) — fresh review · @TimeToBuildBob fix — a worker acts on the findings. Once per comment; 👀 = received.}

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.