I use a Samsung device which unforunately doesn't have the app lock feature.
But it does have a "secure folder" which is more or less what you mean by "spaces", I guess.
The downside of the secure folder against normal app locking is that the apps are no longer seamlessly integrated with the launcher and other apps. It's definitely more secure but is ultimately overkill for my needs.
The option is available to move a vault from the app to the device storage, but not the other way around. At least not from within Obsidian.
But if you use a PC or a file manager that has full device access, you can manually copy the vault folder to the `/storage/emulated/0/Android/data/md.obsidian/files` directory.
> it would be great if the app offered an option to hide its files from other apps by locating them in the app's private storage area
For what it's worth, you can do just that now.
Not sure when it was introduced, but on the current Android version, you are prompted to select either "Device storage" or "App storage" when creating a new vault.
You can also change the location of existing vaults from app to device and vice-versa.
With that now available, the one thing missing for me is a biometric lock option. Or even any kind of locking at all.
There's a community plugin for that, but it's quite unstable and no longer maintained.
One question, since you seem to have more experience with this approach.
> Test the API that triggers the query.
When you test the API, do you also check the state of the database?
Let's say there's an endpoint which creates an entity, and that operation involves setting a bunch of columns that aren't returned in the API.
When testing, do you check only the expected API response, or also the database state to be sure the operation was fully correct?
I currently do the latter, but this feels a bit iffy as the database internals are being leaked in an otherwise "blackbox" test.
If you learn towards the first option, how then do you verify all the unreturned database fields are correctly set?