-
|
I'm building my first app and trying to wrap my head around the shared database part. To be honest, I don't fully understand all of the parts of the docs. I have a fairly basic app where I can read and write some data. Now I want to show this data to (multiple) widgets on the homescreen. From my understanding, it should be possible to still use the DatabaseQueue that I'm using at the moment in my app code and connecting with a DatabaseQueue in WAL mode from my widget code, which just reads data from time to time. And if this is the case, what happens if I'm adding two or three widgets on the homescreen? They would try to read from the database at the same time and I'm quite sure that I'm not able to share a connection for multiple widgets. Any help would be much appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hello @gopeter,
That's because I'm a poor writer, and because sharing a database is HARD. I'll try to illustrate the Sharing a Database guide from the description of your app.
Definitely, yes. The WAL mode allows your widget to open a read-only connection, and read from the database, with very little chance of error, even if the app is toying with it (read/write) at the same time. Since it is a read-only connection, the WAL mode has been set by the main app, when it has created the database (the WAL mode is a property of the SQLite file, not of individual SQLite connections). The problems I can think of can happen when the read-only widget boots:
That's fine. Each widget runs in its own process and uses its own read-only connection to the WAL database. That's what the WAL mode is for. Remains the problem of As soon as your app stores a WAL database in a shared container, the operating system activates a nasty little monitor that mercilessly crashes your app as soon as it gets suspended while holding a lock on the database (i.e. if a write hasn't completed). Simple apps don't do that, except when they do. For example, the user hits "Refresh" is a screen, and sends the app to the background (because people are bored, you know). Yikes: the system decides to suspend the app right in the middle of the database write, and there you are: 💥 Preventing this exception is possible, but it is not exactly trivial (background tasks that postpone app suspension, and in some apps, database suspension). I'm sorry if the guide is not very clear, but maybe give a second read. In the end, if you really want to keep your app simple, DON'T SHARE THE DATABASE. For example, what about having the main app export some JSON files that widgets will feed from? I'm sorry sharing a database is so complicated. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, thank you SO much for your answer! Incredible detailed answer and very useful! You should link it in the documentation 😄 I think I will stick with the JSON approach but have to figure out how to write these files periodically in the background. But that's another topic – thank you so much for your help! |
Beta Was this translation helpful? Give feedback.
Hello @gopeter,
That's because I'm a poor writer, and because sharing a database is HARD. I'll try to illustrate the Sharing a Database guide from the description of your app.
Definitely, yes.
The WAL mode allows your widget to open a read-only connection, and read from the database, with very little chance of error, even if the app is toying with it (read/write) at the same time.
…