Callback for Realm file events: Created/deleted/migrated
See original GitHub issueGoal
My goal is to run initialData
transaction asynchronously. However, given my Android application use case, I don’t think the new Realm.getInstanceAsync
is the best fit.
Expected Results
Get Realm instance synchronously, but execute initialData
transaction asynchronously.
Actual Results
With Realm.getInstanceAsync
, introduced in Realm 3.2.0, a Realm object is not returned synchronously.
That has implications when you are using dependency injection for the Realm instance, as it would make the workflow much more complex than it needs to be (should I not be using it at all?).
Right now, to initialize data, I’m simply making use of SharedPreferences
and running a transaction asynchronously.
Version of Realm
Realm version: 3.2.0
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
DynamicRealm (Realm 10.10.1) - MongoDB
The Callback used when reporting back the result of loading a Realm asynchronously using either Realm.getInstanceAsync(RealmConfiguration, Realm.Callback) or ...
Read more >Secondary .realm file getInstance taking too long
I solved this problem by caching the realm instance: private Realm auxiliaryRealmInstance; fun getAuxiliaryRealmInstance(): Realm{ return ...
Read more >Event Handling in the Realm Object Server
The Realm way eschews that entire concept of data translation because all we really do is have Realm files on the device and...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi @jpmcosta No, feature requests should go here 😃
It is an interesting use case. By doing an async transaction it also means that you are OK with the Realm instance not being “fully” initialized?
The natural option would be to add something like
RealmConfiguration.initialDataAsync()
but calling something “initial*” kinda implies that it is setup when the Realm is opened, so that doesn’t feel right to me.If I remember correctly we have heard other use cases for doing other things when a Realm is created, like resetting SharedPrefs or similar (need to dig those up). So I’m thinking that perhaps we should expose a lifecylecallback whenever the Realm is created/reset, and then you could do whatever. Something like:
Naming and scope is up for debate of course:
Name:
.realmHandler(...)
.onRealmCreated(...)
.lifecycleHandler(...)
.realmFileHandler(...)
.eventHandler(...)
Possible scope:
onRealmCreated
onRealmMigrated
onRealmDeleted
Would something like that work for you?
@cmelchior Yes, that would be perfect! I also envisioned something like
initialDataAsync
, but the lifecyclecallback should work much better.Edit: I didn’t read the comma! Thanks for your answer.