You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been using Realm for about a year now. By far, the steepest learning curve (and source of headaches) has been Realm's concurrency model. I've managed to write a sync engine that will sync data between a local Realm and a GraphQL service, which does its work on a background thread (so that the UI is not blocked while it's working.) However, I've also run into issue where UI can block when the user saves the data they're working on, because there is a background sync in progress.
I've done significant reading and re-reading of Realm's documentation, but I can't find any easy or obvious solution to this problem. The answer "don't write from the UI thread" isn't satisfying, because it's next-to-impossible not to when you are writing an app to modify data. It seems strange to me, too, because Realm's built-in syncing has the same behavior. It's not just a matter of my "custom" syncing over the off-the-shelf solution.
The only solution that I can think of is to do all writes from a background thread, thus queuing the write while it waits for the background sync to complete. However, this introduces the problem of stale data. The user will return to the previous screen, (e.g. a list of To-dos) which may or may-not show their change until the background thread resolves (i.e. the write lock opens up.)
Are there any "best-practices" around this? It seems like the documentation would benefit from some specific examples, rather than just being a high-level overview.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have been using Realm for about a year now. By far, the steepest learning curve (and source of headaches) has been Realm's concurrency model. I've managed to write a sync engine that will sync data between a local Realm and a GraphQL service, which does its work on a background thread (so that the UI is not blocked while it's working.) However, I've also run into issue where UI can block when the user saves the data they're working on, because there is a background sync in progress.
I've done significant reading and re-reading of Realm's documentation, but I can't find any easy or obvious solution to this problem. The answer "don't write from the UI thread" isn't satisfying, because it's next-to-impossible not to when you are writing an app to modify data. It seems strange to me, too, because Realm's built-in syncing has the same behavior. It's not just a matter of my "custom" syncing over the off-the-shelf solution.
The only solution that I can think of is to do all writes from a background thread, thus queuing the write while it waits for the background sync to complete. However, this introduces the problem of stale data. The user will return to the previous screen, (e.g. a list of To-dos) which may or may-not show their change until the background thread resolves (i.e. the write lock opens up.)
Are there any "best-practices" around this? It seems like the documentation would benefit from some specific examples, rather than just being a high-level overview.
Beta Was this translation helpful? Give feedback.
All reactions