generated from exteraGramPlugins/pluginBase
lyuksovannyy
0619c5fe68
Three defects in the restore/injection path. Scrolling stuttered in any chat that had been summarized. The restore gate keyed on id(chat_activity), but every Xposed callback hands Python a fresh Chaquopy wrapper around the same Java object, so the key never matched and each scroll frame opened SQLite and rescanned the message list. updateMessagesVisiblePart runs per frame, so that ran continuously. BaseFragment.classGuid is assigned once per fragment instance, so it identifies an open chat across calls; measured 1 query per 300 frames instead of 300. Saved rows are cached per scope, invalidated on save. The card could attach to the wrong message when many messages were included. insert() computed the index on the calling thread and applied it later on the UI thread; a large range takes long enough for paging or an incoming message to shift the list in between, so a stale index was used. The index is now computed on the UI thread immediately before the mutation that consumes it. Every saved summary appeared stacked together in a row. find_index_for_anchor fell back to nearest-by-id whenever the anchor was not loaded, and a chat opens with a short window, so summaries anchored far up all collapsed to adjacent slots at the bottom. Absence is now reported as -1 and those cards are skipped until paging brings their anchor in; the id-order fallback stays opt-in for reanchor, which must place a card it has already removed. Verified against the 6 real saved summaries for one chat: previously all 6 were injected consecutively on open, now none are, and each appears in its correct place once its range is scrolled in. Also makes restore linear in list length rather than rescanning per summary.