Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughCentralizes EditActivity note initialization into a suspend loadNote(...) and adds onNewIntent to switch base notes at runtime; guards NotificationManager.activeNotifications access behind API 23 in ReminderReceiver; ChangeHistory.reset() now clears the stack before setting stackPointer to -1. Changes
Sequence Diagram(s)sequenceDiagram
participant System as "System\n(Intent)"
participant Activity as "EditActivity"
participant Coroutine as "lifecycleScope\n(Coroutine)"
participant Repo as "NoteRepository / ViewModel"
rect rgba(173,216,230,0.5)
System->>Activity: deliver new Intent (EXTRA_SELECTED_BASE_NOTE)
Activity->>Activity: onNewIntent(intent)\nsetIntent(intent)
Activity->>Activity: if different base note -> launch checkSave() (suspend)
end
rect rgba(144,238,144,0.5)
Activity->>Coroutine: launchWhenResumed { loadNote(selectedId, persistedId, savedState, initListeners=false) }
Coroutine->>Repo: request note data
Repo-->>Activity: note data / model
Activity-->>Activity: update model state, UI, reminder chip, menus (no listener reinit)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt (1)
180-185: Potential race between onCreate's load and a fast-arriving onNewIntent.The
loadNotelaunched here fromonCreatemay still be in flight (DB I/O insetState, listener wiring) whenonNewIntentlaunches anotherloadNote. Both coroutines mutatenotallyModeland rebuild listeners/UI without any cancellation/serialization, which can interleave state and re-attach listeners twice. Consider keeping aJobreference and cancelling the previous load before starting a new one, or guardingloadNotewith aMutex.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt` around lines 180 - 185, The onCreate launch calling loadNote can race with onNewIntent because both start coroutines that mutate notallyModel and rewire listeners; fix by serializing/cancelling previous loads: add a Job property (e.g., loadNoteJob) on EditActivity and before starting a new lifecycleScope.launch for loadNote cancelAndJoin or cancel the previous job, then assign the new Job; alternatively wrap loadNote body with a Mutex (e.g., loadNoteMutex) and lock/unlock around the critical section so concurrent invocations of loadNote (from lifecycleScope.launch in onCreate and from onNewIntent) cannot interleave; reference loadNote, lifecycleScope.launch, onNewIntent, and notallyModel when applying the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 163-167: onNewIntent currently reads extras from the new Intent
but never updates the Activity.intent property, causing loadNote (which checks
intent.data, intent.action and EXTRA_DISPLAYED_LABEL) to see stale launch data;
fix by calling setIntent(intent) at the start of onNewIntent before launching
lifecycleScope so loadNote, setState and handleSharedNote operate on the
incoming Intent and not the original one.
- Around line 163-167: onNewIntent currently calls loadNote(selectedId, ...)
which ultimately calls notallyModel.setState(...) and can overwrite in-progress
edits without saving; update onNewIntent to check for unsaved changes before
loading the new note by invoking the existing checkSave()/saveNote() flow (the
same behavior used in finish() and onSaveInstanceState) and only call loadNote
when checkSave() permits or after saveNote() completes; reference the
onNewIntent, loadNote, notallyModel.setState, checkSave(), and saveNote()
symbols when making the change so the code preserves current edits before
replacing state.
- Around line 200-234: The activity currently lets getLongExtra default to 0L
which causes loadNote(id=0L, ...) -> notallyModel.setState(0L) ->
createBaseNote() and overwrites the current note; change the
onNewIntent/intent-handling code to use -1L as the missing-id sentinel for
EXTRA_SELECTED_BASE_NOTE and short-circuit when id == -1L so loadNote is not
called for invalid IDs; specifically, when reading
intent.getLongExtra(EXTRA_SELECTED_BASE_NOTE, -1L) (or intent?.getLongExtra(...,
-1L) ?: -1L) only call lifecycleScope.launch { loadNote(...) } if the selectedId
!= -1L to avoid triggering notallyModel.setState/createBaseNote for missing
extras.
---
Nitpick comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 180-185: The onCreate launch calling loadNote can race with
onNewIntent because both start coroutines that mutate notallyModel and rewire
listeners; fix by serializing/cancelling previous loads: add a Job property
(e.g., loadNoteJob) on EditActivity and before starting a new
lifecycleScope.launch for loadNote cancelAndJoin or cancel the previous job,
then assign the new Job; alternatively wrap loadNote body with a Mutex (e.g.,
loadNoteMutex) and lock/unlock around the critical section so concurrent
invocations of loadNote (from lifecycleScope.launch in onCreate and from
onNewIntent) cannot interleave; reference loadNote, lifecycleScope.launch,
onNewIntent, and notallyModel when applying the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 56f8affb-c09b-498c-adfe-c0d7a6e90516
📒 Files selected for processing (3)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.ktapp/src/main/java/com/philkes/notallyx/presentation/activity/note/reminders/ReminderReceiver.ktapp/src/main/java/com/philkes/notallyx/utils/changehistory/ChangeHistory.kt
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 207-241: loadNote(...) is being called from onCreate and
onNewIntent and re-attaches observers/listeners (setupListeners,
setupAdditionalListeners, configureUI), causing duplicate observers (e.g.,
search.results.mergeSkipFirst(...).observe(this),
search.resultPos.observeSkipFirst(this), notallyModel.viewMode.observe(this),
preferences.*.observe(this)) and duplicate text watchers
(binding.EnterSearchKeyword.doAfterTextChanged). Fix by splitting initialization
from reload: extract a one-time init method (called from onCreate) that
registers observers/listeners (move setupListeners, setupAdditionalListeners,
configureUI contents that add observers here) and make loadNote support a reload
path (called from onNewIntent) that updates state without re-registering
observers; alternatively add a boolean flag to loadNote (e.g., attachObservers:
Boolean) and guard observer/text-watcher registration so subsequent calls skip
re-attachment; also for safety, where appropriate remove existing
observers/listeners before re-attaching
(removeObserver/removeTextChangedListener) or use lifecycle-aware single-event
helpers.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ef236590-edf9-46c6-be49-1c0d98176fc5
📒 Files selected for processing (1)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt (1)
187-194:⚠️ Potential issue | 🔴 CriticalMove
configureUI()invocation into theloadNotecoroutine, or use a post-load callback, to ensure model state is initialized first.
configureUI()and its observers run synchronously inonCreatebefore theloadNotecoroutine executes, meaningnotallyModel.setState(...)(line 211) has not yet run when subclassconfigureUI()methods andsetupAdditionalListeners()observer registrations execute.Confirmed risks in subclass overrides:
- EditListActivity (line 207): calls
listManager.add(pushChange = false)whennotallyModel.items.isEmpty()is true, adding a blank item before the actual loaded items populate the list. AfterloadNotecompletes,setState()callssetItems()which clears and repopulates, creating a UI glitch.- EditNoteActivity and EditTextPlainActivity (lines 51, 83): read
notallyModel.isNewNotebefore it's set bysetState(). While the default value oftruehappens to work for new notes, it will be incorrect untilsetState()runs for existing notes being edited.notallyModel.viewMode.observe(this)(line 689): fires immediately with the defaultNoteViewMode.EDITvalue, callingtoggleCanEdit()andupdateToggleViewMode()against pre-load state, then re-runs onceloadNotefinishes andsetState()updates the actual view mode.Refactor to execute
configureUI()after model initialization completes, either by moving it intoloadNote()as a post-load step or byawait-ing the launched coroutine before calling it.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt` around lines 187 - 194, The call to configureUI() runs before loadNote(...) completes so observers and subclass overrides (e.g., EditListActivity, EditNoteActivity, EditTextPlainActivity) see uninitialized model state; move the configureUI() invocation into the lifecycleScope.launch coroutine after loadNote(...) returns (or await the coroutine before calling configureUI()), or add a post-load callback in loadNote to invoke configureUI(); ensure setupListeners() remains where intended and that notallyModel.setState(...) (inside loadNote) runs before any configureUI()/setupAdditionalListeners() observers execute.
🧹 Nitpick comments (1)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt (1)
163-174: LGTM —onNewIntentcorrectly updates the intent and saves pending edits.The added
setIntent(intent)andcheckSave()calls properly address the previously raised concerns about stale intent reads and unsaved-edit loss, and guarding onselectedId != -1Lavoids needlessly reloading when the activity receives an unrelated new intent.One small nit: the sentinel here is
-1L, whileonCreate(line 189) uses0Las the default forEXTRA_SELECTED_BASE_NOTE. Aligning both to the same sentinel (or extracting a small helper) would make the read paths consistent.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt` around lines 163 - 174, onNewIntent uses -1L as the sentinel while onCreate reads EXTRA_SELECTED_BASE_NOTE with a default of 0L, causing inconsistent intent-read behavior; make the sentinel consistent by choosing one value (or create a small helper like getSelectedBaseNoteFromIntent(Intent) used by both onNewIntent and onCreate) and update references so both onNewIntent and onCreate use the same sentinel logic for EXTRA_SELECTED_BASE_NOTE and the same check (e.g., selectedId != sentinel) to avoid mismatched handling of "no selection".
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 208-240: The title TextWatcher created by
createTextWatcherWithHistory is firing on programmatic setText in
setStateFromModel during onNewIntent reload, polluting changeHistory; to fix,
suppress watcher callbacks around the programmatic update: in setStateFromModel
(or loadNote before calling it) remove or temporarily disable the EnterTitle
TextWatcher, call binding.EnterTitle.setText(notallyModel.title), then re-attach
or re-enable the watcher so only user edits are recorded; alternatively add a
simple boolean flag (e.g., isProgrammaticEdit) checked by the watcher (in
createTextWatcherWithHistory) to ignore programmatic changes and toggle it
around setText to prevent recording the reload as an undoable change.
---
Outside diff comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 187-194: The call to configureUI() runs before loadNote(...)
completes so observers and subclass overrides (e.g., EditListActivity,
EditNoteActivity, EditTextPlainActivity) see uninitialized model state; move the
configureUI() invocation into the lifecycleScope.launch coroutine after
loadNote(...) returns (or await the coroutine before calling configureUI()), or
add a post-load callback in loadNote to invoke configureUI(); ensure
setupListeners() remains where intended and that notallyModel.setState(...)
(inside loadNote) runs before any configureUI()/setupAdditionalListeners()
observers execute.
---
Nitpick comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 163-174: onNewIntent uses -1L as the sentinel while onCreate reads
EXTRA_SELECTED_BASE_NOTE with a default of 0L, causing inconsistent intent-read
behavior; make the sentinel consistent by choosing one value (or create a small
helper like getSelectedBaseNoteFromIntent(Intent) used by both onNewIntent and
onCreate) and update references so both onNewIntent and onCreate use the same
sentinel logic for EXTRA_SELECTED_BASE_NOTE and the same check (e.g., selectedId
!= sentinel) to avoid mismatched handling of "no selection".
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 87f6744a-cce7-4b59-ae2c-35ba05dd788d
📒 Files selected for processing (1)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`:
- Around line 206-244: The issue is that loadNote(..., initListeners = false)
skips configureUI(), so for Type.LIST the list adapters (MainListView.adapter
and CheckedListView.adapter set in configureUI()) are not rebound on onNewIntent
and old items remain; fix by splitting configureUI() into two parts (or adding a
new method) so that view-binding always runs but listener registration runs only
when needed: extract the adapter/view-binding logic into a new method (e.g.,
rebindListViews() or bindUIState()) and call it unconditionally from loadNote
(before setStateFromModel or right after), while keeping existing listener
attachment inside configureUI() guarded by a listenersInitialized flag (or only
called when initListeners is true); update subclasses (EditNoteActivity
overrides) to move adapter setup into the bind method and guard any listener
registration so repeated calls are safe.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2b57b27f-a113-4434-8aad-20b67892ef7a
📒 Files selected for processing (1)
app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt
| private suspend fun loadNote( | ||
| id: Long, | ||
| persistedId: Long?, | ||
| savedInstanceState: Bundle?, | ||
| initListeners: Boolean, | ||
| ) { | ||
| changeHistory.reset() | ||
| if (persistedId == null || notallyModel.originalNote == null) { | ||
| notallyModel.setState(id, intent.data == null) | ||
| } | ||
| if (notallyModel.isNewNote) { | ||
| when (intent.action) { | ||
| Intent.ACTION_SEND, | ||
| Intent.ACTION_SEND_MULTIPLE, | ||
| Intent.ACTION_VIEW -> handleSharedNote() | ||
|
|
||
| else -> | ||
| intent.getStringExtra(EXTRA_DISPLAYED_LABEL)?.let { | ||
| notallyModel.setLabels(listOf(it)) | ||
| } | ||
| } | ||
| } | ||
|
|
||
| initBottomMenu() | ||
| resetToolbars() | ||
| if (initListeners) setupListeners() | ||
| setStateFromModel(savedInstanceState) | ||
|
|
||
| if ( | ||
| !notallyModel.isNewNote && notallyModel.type == Type.LIST && savedInstanceState == null | ||
| ) { | ||
| val lastUsedViewMode = notallyModel.viewMode.value | ||
| notallyModel.viewMode.value = | ||
| preferences.defaultListNoteViewMode.value.toNoteViewMode(lastUsedViewMode) | ||
| } | ||
| if (initListeners) configureUI() | ||
| binding.ScrollView.visibility = VISIBLE | ||
| setupEditNoteReminderChip() | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect concrete configureUI overrides to confirm body/list binding lives there
# and assess idempotency for re-invocation on onNewIntent.
fd -e kt | xargs rg -nP -C3 'override\s+fun\s+configureUI\s*\(\s*\)'
echo '----'
# Check how EnterBody / MainListView / CheckedListView text/adapters are populated.
rg -nP -C2 '\b(EnterBody|MainListView|CheckedListView)\b\s*\.(setText|adapter|text)\b'Repository: Crustack/NotallyX
Length of output: 6341
🏁 Script executed:
# Extract full configureUI implementations from the two main subclasses
echo "=== EditNoteActivity.configureUI() ==="
sed -n '48,/^ override\|^ fun\|^ private\|^}/p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditNoteActivity.kt | head -80
echo ""
echo "=== EditListActivity.configureUI() ==="
sed -n '204,/^ override\|^ fun\|^ private\|^}/p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditListActivity.kt | head -100Repository: Crustack/NotallyX
Length of output: 665
🏁 Script executed:
# Find setStateFromModel implementation
rg -n 'fun setStateFromModel' -A 30 app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.ktRepository: Crustack/NotallyX
Length of output: 1375
🏁 Script executed:
# Check where updateEditText is called in EditNoteActivity
rg -n 'updateEditText' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditNoteActivity.ktRepository: Crustack/NotallyX
Length of output: 129
🏁 Script executed:
# Get context around line 112 in EditNoteActivity to see when updateEditText is called
sed -n '100,130p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditNoteActivity.ktRepository: Crustack/NotallyX
Length of output: 1152
🏁 Script executed:
# Find all invocations of updateEditText in EditNoteActivity
rg -n 'updateEditText\(\)' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditNoteActivity.ktRepository: Crustack/NotallyX
Length of output: 129
🏁 Script executed:
# Find where list adapters are bound in EditListActivity - look for adapter assignments
sed -n '240,280p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditListActivity.ktRepository: Crustack/NotallyX
Length of output: 1826
🏁 Script executed:
# Check if setStateFromModel has overrides in subclasses that might bind body
rg -n 'override.*setStateFromModel\|fun setStateFromModel' app/src/main/java/com/philkes/notallyx/presentation/activity/note/Repository: Crustack/NotallyX
Length of output: 43
🏁 Script executed:
# Check if EditListActivity has any mechanism to rebind adapters after configureUI
rg -n 'binding\.(MainListView|CheckedListView)\.adapter\s*=' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditListActivity.ktRepository: Crustack/NotallyX
Length of output: 177
🏁 Script executed:
# Verify EditNoteActivity.setStateFromModel is actually called and does update text
sed -n '111,135p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditNoteActivity.ktRepository: Crustack/NotallyX
Length of output: 932
🏁 Script executed:
# Check the onNewIntent method to see the full flow
rg -n 'override.*onNewIntent\|fun onNewIntent' -A 5 app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.ktRepository: Crustack/NotallyX
Length of output: 43
🏁 Script executed:
# Search for onNewIntent in all activity files
rg -n 'onNewIntent' app/src/main/java/com/philkes/notallyx/presentation/activity/note/Repository: Crustack/NotallyX
Length of output: 315
🏁 Script executed:
# Also check the base EditActivity to understand the full architecture
rg -n 'loadNote' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt | head -20Repository: Crustack/NotallyX
Length of output: 227
🏁 Script executed:
# Check if there's an onNewIntent that's not in the standard location
find app/src/main/java/com/philkes/notallyx/presentation/activity/note/ -name '*.kt' -exec rg -l 'onNewIntent' {} \;Repository: Crustack/NotallyX
Length of output: 143
🏁 Script executed:
# Get the full onNewIntent implementation
sed -n '163,180p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.ktRepository: Crustack/NotallyX
Length of output: 734
🏁 Script executed:
# Also get context around line 171 to see the full flow
sed -n '160,180p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.ktRepository: Crustack/NotallyX
Length of output: 751
🏁 Script executed:
# Finally check if EditListActivity has any custom setStateFromModel
grep -n 'setStateFromModel\|updateEditText' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditListActivity.ktRepository: Crustack/NotallyX
Length of output: 187
🏁 Script executed:
# Get full EditListActivity.setStateFromModel override
sed -n '217,230p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditListActivity.ktRepository: Crustack/NotallyX
Length of output: 560
🏁 Script executed:
# Confirm the exact line in loadNote where configureUI is called vs where setStateFromModel is called
sed -n '206,244p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt | grep -n 'setStateFromModel\|configureUI\|initListeners'Repository: Crustack/NotallyX
Length of output: 235
🏁 Script executed:
# Verify the order of operations in loadNote
sed -n '206,244p' app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.ktRepository: Crustack/NotallyX
Length of output: 1405
List note content is not refreshed on onNewIntent reload — note B's items will still show note A's list.
When onNewIntent calls loadNote(..., initListeners = false), the order of operations is:
setStateFromModel()is always calledconfigureUI()is skipped (gated byinitListeners)
For Type.NOTE, this works correctly: EditNoteActivity overrides setStateFromModel() to call updateEditText(), which rebinds the body text.
However, for Type.LIST, the adapter bindings (MainListView.adapter and CheckedListView.adapter, set at lines 266–271) live only inside configureUI(). Since configureUI() is skipped on onNewIntent, list adapters are never rebound, leaving the old note's items visible. This defeats the fix for #981 in the reused-activity path.
The configureUI skip was intended to avoid re-attaching listeners. The cleaner fix is to split the subclass configureUI() overrides into two parts: (a) rebind state to views (always run), and (b) register listeners (run only on first init).
🔧 One possible shape of the fix
- if (initListeners) configureUI()
+ configureUI()…paired with making the subclass configureUI() overrides safe to call on reload (e.g., guard listener registration with a listenersInitialized flag).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@app/src/main/java/com/philkes/notallyx/presentation/activity/note/EditActivity.kt`
around lines 206 - 244, The issue is that loadNote(..., initListeners = false)
skips configureUI(), so for Type.LIST the list adapters (MainListView.adapter
and CheckedListView.adapter set in configureUI()) are not rebound on onNewIntent
and old items remain; fix by splitting configureUI() into two parts (or adding a
new method) so that view-binding always runs but listener registration runs only
when needed: extract the adapter/view-binding logic into a new method (e.g.,
rebindListViews() or bindUIState()) and call it unconditionally from loadNote
(before setStateFromModel or right after), while keeping existing listener
attachment inside configureUI() guarded by a listenersInitialized flag (or only
called when initListeners is true); update subclasses (EditNoteActivity
overrides) to move adapter setup into the bind method and guard any listener
registration so repeated calls are safe.
Fixes #981
Summary by CodeRabbit
Bug Fixes
Refactor