sakethpathike
[Feature] Change app data default folder/file
I directly use KeePass files stored in Nextcloud, accessed through Nextcloud provider in Android's native file picker. When I save new passwords, it's automatically sync across all devices.
I'd like to implement similar functionality for Linkora: Allow users to select a JSON file using Android's built-in file picker and Set this selected file as Linkora's main data storage
This approach eliminates the need for implementing separate integrations with various cloud storage services.
Allow users to select a JSON file using Android's built-in file picker and Set this selected file as Linkora's main data storage
doesn't this remove the usage of the local database and the sync-server?
Also, dealing with the JSON file as the main storage means you need to serialize and deserialize for every function.
I'd like to implement similar functionality for Linkora
while I don't think this is a very effective solution, you can go ahead and create a PR once you're done :)
doesn't this remove the usage of the local database and the sync-server?
App also have an option to choose a path from the device's storage and it continue the process as it saves the data right now but in selected path.
as it saves the data right now but in selected path
so what you mean is, change the database path itself? If yes, there's no reason to use a JSON file.
I don’t really see any problem with this. But by default, it should be set to the current location, and if anyone wants to change the DB path to the nextcloud location (this directory should exist locally), then your implementation would come into play :)
I think you can add an option to change the DB path to this and use it as the path for the Room DB implementation on android. Now, there's no need for a JSON file, but on the other hand, storage permission must be set to allow.
so what you mean is, change the database path itself? If yes, there's no reason to use a JSON file. ...
I think using the word JSON made it wrong, I didn't necessarily mean JSON, I mean a file that kept the data.
Yeah, that's exactly how KeePass works: load a DB file from any location and just have the app remember the path. Then users can freely sync/copy/share the DB file however they like. That's presuming Linkora keeps all of it's data in a single database file.
But, that approach would also require Linkora to auto-close the database after X minutes of inactivity or on minimize/exit, so that the DB file doesn't stay locked 24/7.
that approach would also require Linkora to auto-close the database
room handles this because we're only changing the db path, nothing more. closing the connection means the app can't collect data reactively, and the latest data doesn't get reflected.
That's presuming Linkora keeps all of it's data in a single database file.
yeah, it only uses one db file along with other files (.shm, .wal and .lck); I think we can copy all these to the destination and it should work as expected 🤔
that approach would also require Linkora to auto-close the database
room handles this because we're only changing the db path, nothing more. closing the connection means the app can't collect data reactively, and the latest data doesn't get reflected.
Of course, it's all about usage patterns and how the app is implemented.
KeePass, being a password safe, is meant to be closed/locked majority of time, and only accessed/unlocked occasionally on-demand. It naturally has auto-close-on-idle and read-the-whole-db-on-every-start.
Now, if one is using Linkora in a different manner, like, keeping it running at all times on a desktop, then, this I'm-syncing-my-own-database approach can't be used because the app will never release nor re-read the database. But that's not a problem since Linkora already supports it's own syncing-server which is ideal for such a scenario anyway.
All I'm saying is that, if Linkora embraces this I'm-syncing-my-own-database approach, then, just like KeePass, it has to have (optional, of course) means for user to set close state, either manually, by clicking on some UI affordance, and/or automatically by some user-pre-defined idle timer.
This is the scenario that needs to be prevented: the user is using the I'm-syncing-my-own-database approach and running Linkora both on a phone and on a desktop. Naturally, the phone app never closes and never releases the database which means that changes done on the desktop never get propagated, and, in case a link is added on the phone consecutively, changes from the desktop are lost. To prevent this, Linkora needs to be able to auto-close-on-idle.
Now, if one is using Linkora in a different manner, like, keeping it running at all times on a desktop, then, this I'm-syncing-my-own-database approach can't be used because the app will never release nor re-read the database.
i was out of context with that 😅. i was referring to the current version, where it does it on its own. but yeah, i get what you are telling. now, if the same file is the source for both (i'm-syncing-my-own-database approach), it won't work when writing into it. but i don't think room locks it for reading (reading the changes is the only reason why the connection to the db is always open).
if both clients want to write at the same time, it'll lead to the issue that you've mentioned which definitely sucks.
if Linkora embraces this I'm-syncing-my-own-database approach, then, just like KeePass, it has to have (optional, of course) means for user to set close state, either manually, by clicking on some UI affordance, and/or automatically by some user-pre-defined idle timer.
now this is up to @alr86 😅
but i don't think room locks it for reading (reading the changes is the only reason why the connection to the db is always open).
Yes, but it won't reload on open either as the android app just keeps running in the background, instead of getting closed and starting anew. That's why KeePassDX has this big 🔒 button available in the bottom left corner at all times.
Now, if one is using Linkora in a different manner, like, keeping it running at all times on a desktop, then, this I'm-syncing-my-own-database approach can't be used because the app will never release nor re-read the database. But that's not a problem since Linkora already supports it's own syncing-server which is ideal for such a scenario anyway.
If the app updates with every file change, there shouldn't be any big issues. Unlike KeePass, which requires encryption and decryption processes, this approach doesn’t need to lock and unlock the database, allowing app for background updates with every change in file. However, if updates happen simultaneously, one change might be missed👍
If the app updates with every file change, there shouldn't be any big issues.
Yes, that's true, but rarely are apps built like that.
An atomic app could open the database connection on every save and quickly close it back. In addition, it could monitor the DB file via filesystem watch to compare the modified timestamp and to reload if changed. But, I'm afraid this is far from how Linkora is implemented right now, given it is heavily relying on a broad tech stack.
Most probable reality is that Linkora just locks the database and keeps it open indefinitely and that's it.
On a similar note, Currently the data export tool in Android, just exports it to a folder under Documents for me. Is it possible somehow to change the export location ? I am having to copy it everytime to a different folder, just so that sync works
