Kunzisoft / Kunzisoft/KeePassDX
Timer Autosave
- Dominant language
- Kotlin
- Stars
- 7.3k
- Forks
- 401
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 1
Description
### Checks
- [x] I have read the Wiki, searched the open issues, and still think this is a new feature.
### Explain the problem clearly and succinctly:
I had a recent scenario with KeePassDX 4.2.4 with Autosave off & with a Timeout (Save & Lock) of 15 minutes, whereby an entry was finalized, and I switched to another app. Android system decided to rug-pull the RAM from KeePassDX a little while after, thus destroying the existence of the new entry. Resuming-to KeePassDX to Save was therefore impossible
Autosave is off is to prevent thrashing the MicroSD card: theyre fragile and require paced management. The Timeout feature assumes an ideal state: that RAM is plentiful and there is no outer governance of resources, and therefore the Timeout can be achieved as set
### Describe the solution you'd like:
I don't know the Android internal mechanism for memory management, but the behavior hints that Android system doesnt throw a warning, nor does KeePassDX have any mechanism to know when its RAM allocation is about to expire, nullifying its Timeout. Considering that, a middleground balance can be optioned: a timered Autosave of 1 or 2 minutes since last activity. Keeping the database open, securing the entry to avert events of the system executive. It can be the one that toggles-on when event Autosave is toggled-off, and it too can be toggled-off, further for the manual Save
### Describe alternatives you've considered:
A shorter Timeout
### Additional context:
_No response_
Contributor guide
Research direction
No files or tests are named. Start by locating the existing Autosave and Save & Lock timeout settings and their Android lifecycle handling, then determine how a timered save would interact with manual saving and both toggles. Done means the proposed interval behavior preserves edits after the app is reclaimed while leaving users able to disable it and avoid unwanted frequent writes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100