Object changelisteners does not trigger if a linked object changes
See original GitHub issueGoal
Detect changes of nested objects of a single RealmObject
using RealmChangeListener
.
Understand the differences between RealmChangeListener
on RealmObject
and RealmResults
.
Expected Results
RealmChangeListener
of a single RealmObject
would listen to changes of its nested objects.
RealmChangeListener
of a single RealmObject
would listen to more changes than the RealmChangeListener
of RealmResults
.
Actual Results
RealmChangeListener
of a single RealmObject
doesn’t listen to changes of its nested objects.
RealmChangeListener
of RealmResults
listens to changes of its children’s nested objects.
Steps & Code to Reproduce
I created a simple Android project to reproduce my use case: https://github.com/jpmcosta/RealmTestProject/tree/262ee9099b47852c2b26bc2f7e3874c8670e6264
Schema:
App
object contains aRealmColor
property. That’s just a (bad) pattern to illustrate the issue.
How to reproduce the issue:
- there’s a list with a single
App
object - click on that object to randomly change the
value
of itsRealmColor
property - when
RealmColor.value
changes we want to:- change the
App
text color - change the FAB color
- change the
To change the App
text color we add RealmChangeListener
to RealmResults<App>
and call notifyDatasetChanged
when a change is detected.
To change the FAB color we add a RealmChangeListener
to the App
object and update its color when a change is detected.
Issue:
- The FAB color is not updated properly.
Version of Realm and tooling
Realm version: 3.3.2
Issue Analytics
- State:
- Created 6 years ago
- Reactions:11
- Comments:39 (18 by maintainers)
@Zhuinden yes, that would work. I understand that
App
itself has not changed. But then, why does theRealmChangeListener
inRealmResults<App>
detect a change? Also, if I have 10 nested objects, should I need to add 10 different listeners?You probably were updating the parent object in the same transaction, without really thinking about it.
My ugly solution is to update the parent object “manually”. Usually, I have an
updatedAt: Long
property in the parent, which the child object is responsible to update whenever it is updated.