I think perhaps having two databases would be preferable:
- `app_state.db`: It stores data such as which Spaces are currently added to the app and where they are located on the disk. Will also include a table of recently opened Spaces - this will be used to show a list in the UI.
- `cache.db`: This database is disposable and is just used for mirroring. The app will scan the Space folder to rebuild the database.
The local files are always the source of truth, but having the `cache.db` database allows for very efficient indexing. #dev
The easy route would be to just store everything in the SQLite database, but I really do prefer the approach of having local files. I think the right choice is going to be a hybrid approach where the app uses both local files and a database, but I need to find the right balance...
There should be an app database storing 'Spaces' with their names and icons/images.
This database will be stored inside the app directory, and it will therefore be device-specific. This means, each device will have its own local database.
This creates a bit of a problem in terms of continuity because of no global database that's hosted in the cloud.
Imagine the following scenario:
- The user bookmarks a note on their Mac.
- Now the user opens the iOS app, but the bookmark is not to be found.
The bookmark will not appear automatically, because as already mentioned, each device has its own local database. Luckily, there is another way to do it that solves the problem of continuity.
I could simply use hidden folders inside the space folder. Then the local database will just mirror the information found in the files located in the hidden `.space/` folder.
The folder structure could be something like:
```
/Documents/My_Project_Space/
├── .space/
│ ├── settings.json (spaceName, icon/image, bookmarks, recentNotes, ...)
│ └── history/
│ └── F0B35EEF/ (Folder named by note ID)
│ ├── 20260112_1000.json
│ └── 20260112_1045.json
├── assets/
│ └── some_image.png
├── Work_Notes/
│ └── meeting_jan_12.json
└── some_other_note.json
```
The local files should always be the source of truth, while the database is there mirroring for performance.
If the user types a character in a note, the local DB should be updated and immediately refresh the UI, this should take <1ms, so the user sees the change instantly.
Then after, the app triggers a background task to write the updated JSON to the disk.
I'm still in the process of figuring out the best architecture before beginning implementation, but I think I'm starting to have a pretty good idea of how to best do this. #dev #app
View quoted note →
View quoted note →