Add detailed notification for RealmObject #4331

beeender · 2017-03-16T09:05:07Z

Add RowObject for wrapping Object Store's Object class.
Enabled detailed object notification.
Add RealmObjectChangeListener, ObjectChangeSet.
Fix false positive change notifications for RealmObject. Now the
notification will only be sent when the object actually changes.

- Add RowObject for wrapping Object Store's Object class. - Enabled detailed object notification. - Add RealmObjectChangeListener, ObjectChangeSet. - Fix false positive change notifications for RealmObject. Now the notification will only be sent when the object actually changes. See #4101

beeender · 2017-03-16T09:16:35Z

For use cases in #4101

Object change listeners will now only be called if the object actually changed. It should reduce the number of unnecessary updates which is happening right now due to the change notification being table based.
It should make it possible to register listeners for a single field value, e.g. if the UI should only be refreshed if a single field changed.
It should be possible to register a listener on an object and be give the old and new values, e.g. useful if you only need to refresh the UI if a String changed in a particular way.
It should now be possible to be notified when an object is deleted. See findFirstAsync is not emitting object when queried object is deleted from Realm #3138. Realm classes only implementing "RealmModel" might be tricky to support.
We should strive for easy integration with Databinding https://developer.android.com/topic/libraries/data-binding/index.html. How this should be done is still undecided.

Currently this will solve 1) 4) need more investigation on 5)

I don't say a strong requirement right now, so we can discuss it when needed in the future. Also based on current API, it is easy to get a 3rd party lib to subscribe on field changes.
Yes, cocoa has it. My major concern is that would require to store the old value in memory and convert to java values. Problems will happen when there is some huge strings/binary existing, then the memory consumption + encoding performance are something really should be considered. Also, generic type for field value might also be a problem.
I don't see there is case that old value is important, but if we need to implement it, based on current API, maybe we can have something like:

    class FieldChange<T> {
        /**
         * The name of the field which changed.
         */
        final String fieldName;
        final T oldValue;
        final T value;

        public FieldChange(String fieldName, T oldValue, T value) {
            this.fieldName = fieldName;
            this.oldValue = oldValue;
            this.value = value;
        }
    }

beeender · 2017-03-16T09:17:36Z

@realm/java I am still working on this to fix some corner issues. But the API part is ready for review. Please take a look.

kneth

Looks promising!

kneth · 2017-03-16T10:01:06Z

CHANGELOG.md

@@ -15,6 +15,8 @@
  * Migration for linking objects is not yet supported.
  * Backlink verification is incomplete.  Evil code can cause native crashes.
 * [ObjectServer] In case of a Client Reset, information about the location of the backed up Realm file is now reported through the `ErrorHandler` interface (#4080).
+* The listener on `RealmObject` will only be triggered if the object changes (#3894).
+* Added `RealmObjectChangeListener` to get detailed information about `RealmObejct` changes.


"RealmObejct" -> "RealmObject"

kneth · 2017-03-16T10:38:10Z

realm/realm-library/src/main/java/io/realm/internal/RowObject.java

+/**
+ * Java wrapper for Object Store's {@code Object} class. Currently it is only used for object notifications.
+ */
+public class RowObject implements NativeObject {


Is RowObject really the best name? I know that RealmObject is taken but that's what it is.

I am really out of ideas ... First i tried Object, but apparently it will conflict a lot with java's Object ... But ObjectStoreObject sounds really stupid... any suggestions are welcome.

Just throwing ideas at the wall: OsObject, NativeRealmObject, InternalObject, OsRealmObject ... nothing is really great, so RowObject is probably fine for now.

But perhaps we should find a common prefix for all the ObjectStore classes?

common prefix makes sense. So OsObject? and Collection -> OsResults?

Yes and OsSharedRealm I assume?

cmelchior

I only looked at the public API parts. Generally it looks good I think. Only pain point is finding out what to do about FieldChange and what methods to have in the ObjectChangeset class. Generally, I'm not worried about long strings or byte arrays, since you probably wouldn't use field change listeners for those cases? But we should probably document the problem in any case.

cmelchior · 2017-03-16T10:01:35Z

CHANGELOG.md

@@ -15,6 +15,8 @@
  * Migration for linking objects is not yet supported.
  * Backlink verification is incomplete.  Evil code can cause native crashes.
 * [ObjectServer] In case of a Client Reset, information about the location of the backed up Realm file is now reported through the `ErrorHandler` interface (#4080).
+* The listener on `RealmObject` will only be triggered if the object changes (#3894).
+* Added `RealmObjectChangeListener` to get detailed information about `RealmObejct` changes.


RealmObjct -> RealmObject

cmelchior · 2017-03-16T10:03:02Z

realm/realm-library/src/main/java/io/realm/ObjectChangeSet.java

+ * Information about the changes made to an object.
+ * @see RealmObject#addChangeListener(RealmObjectChangeListener) .
+ */
+public interface ObjectChangeSet {


Mirroring the CollectionChangeSet seems like the correct approach 👍

cmelchior · 2017-03-16T10:06:33Z

realm/realm-library/src/main/java/io/realm/ObjectChangeSet.java

+    /**
+     * @return {@code null} if the object has been deleted. Otherwise returns the information about changed fields.
+     */
+    FieldChange[] getFieldChanges();


This wouldn't work very well if you had e.g an int and a String field, as this would basically be type-erased to FieldChange<Object>.

Figuring out how to represent the changes are probably the crux of the problem, since the rest of the API's fall fairly natural from what we did for Collection notifications. Also, we probably need to consider what is most likely if interested in multiple changes. Do you register 1 listener and do switches or register multiple listeners?

What about this, it adds a few more helper methods people can use, that could provide a little more type safety.

public interface ObjectChangeset { boolean isDeleted(); // I'm not sure this is very useful in practical code. I cannot think of any generic code // where you wouldn't need the type information somehow? FieldChange[] getChanges(); String[] getFieldNames; boolean didChange(String fieldName); <E> FieldChange<E> getChange(E type, String fieldName); /// Alternatively FieldChange<Long> getLongChange(String fieldName); FieldChange<String> getStringChange(String fieldName); FieldChange<Double> getDoubleChange(String fieldName); FieldChange<Float> getFloatChange(String fieldName); FieldChange<Boolean> getBooleanChange(String fieldName); FieldChange<Date> getDateChange(String fieldName); <E> FieldChange<E> getRealmObjectChange(E type, String fieldName); <E> FieldChange<RealmList<E>> getRealmListChange(E type, String fieldName); }

Generally, I think we should try to make it as easy as possible for people to get the typed information since that is most likely what you want to operate in client code.

FieldChange getChange(E type, String fieldName);

E as type, how? You'd be able to use int.class and the like, but that falls apart with RealmList<E> which requires the ugly hack new TypeToken<RealmList<E>>() {};

If we want to use generics we are forced to use the boxed types, e.g Integer instead of int. Alternatively you are forced to create a FieldChange class for each type we support, which also seems like massive overkill: IntegerFieldChange, intFieldChange ....

I prefer one listener on the RealmObject instead of multiple listeners on the object's fields. It makes the API simpler and it is still quite simple for real use cases, eg.: databinding. We/Users can always inherit the RealmObjectChangeListener for specific use cases. See my example code of using it in data binding https://github.com/realm/realm-android-adapters/pull/99/files#diff-58a0e399a032fe72057d0e65269ebdb6

I would choose something with less methods, so probably:

public interface ObjectChangeset { boolean isDeleted(); String[] getChangedField(); public static class FieldChange<T> { T oldValue; T newValue; } // This will always return null for RealmList field. <E> FieldChange<E> getChange(E type, String fieldName); }

FieldChange and getChange() will not be implemented in this PR. Also if we are going to have them, there are some restrictions:

For local transactions, there is no way to get the old values.

store the old values will be slow and consuming memory when the old value is a big String or Binary -- The listener is on the RealmObject instead of on the field.

Having isDeleted(), getChangedFields(), isChanged(String fieldName) and getChange(type, fieldName) probably covers the use cases I can think of 👍

It seems a rather big (and arbitrary) limitation that this doesn't work for local transactions. Any reason why?

IMO we should just document that you need to be careful if using this with objects with big field values. You shouldn't register 100's of these anyway, but doing it on an object with a 16MB image is probably a bad idea (if it changes). Cocoa has a feature request for ignoring certain fields I believe, but this is currently out of scope.

cmelchior · 2017-03-16T10:10:16Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+     * When this gets called when the object is modified, {@code changeSet.isDeleted()} will return {@code false} and
+     * {@code changeSet.getFieldChanges()} will return the detailed information about the fields' changes.
+     * <p>
+     * This will be called if the {@link RealmObject} field gets set or removed, but it won't be called if the


Perhaps rewriting this would make it a bit more clear:

If a field points to another RealmObject this listener will only be triggered if the field is set to a new object or null. Updating the referenced RealmObject will not trigger this listener. If a field points to a RealmList, this listener will only be triggered if a objects are inserted, removed or moved within the List. Updating the objects in the RealmList will no trigger this listener.

dalinaum · 2017-03-17T07:20:06Z

realm/realm-library/src/androidTest/java/io/realm/RealmObjectTests.java

@@ -1593,7 +1590,7 @@ public void run() throws Exception {

                //noinspection TryFinallyCanBeTryWithResources
                try {
-                    dog.addChangeListener(null);
+                    dog.addChangeListener((RealmChangeListener)null);


dog.addChangeListener((RealmChangeListener) null);

Backlinked object won't be notified when their parents object changed.

- Add ObjectChangeSet & RealmObjectChangeListener. - Add OsObject to wrap ObjectStore's Object for notifications. - No more false positive notifications for RealmObject. - Use ObserverPairList in ProxyState instead of normal list to solve the potential listener removal problems which is handled well by the ObserverPairList. - Fix tests.

beeender · 2017-03-21T12:41:10Z

realm/realm-library/src/main/java/io/realm/ObjectChangeSet.java

+     * @return the names of changed fields if the object still exists and there are field changes. Returns {@code null}
+     * if the object has been deleted.
+     */
+    String[] getChangedFields();


@cmelchior I am not quite convinced that boolean isFieldChanged(String fieldName) is useful here:

If user wants, it is very easy to do with Arrays.asList(getChangedFields()).contains(fieldName)

It would be ambiguous when the object is delete, what should it return in that case? false?

But I am totally fine if you strongly think it is needed. 🍏

I would think a very common pattern is:

if (changeset.isFieldChanged("name")) { updateName(changeSet.getChange(String.class, "name").newValue()); }

That should be as easy as possible.

Agree, that it gets slightly ambigious with deleted objects, but getChangedFields() would also return nothing, so I think that will be acceptable?

OK, i will add it in another PR.

Can you make a list of outstanding issues? or known problems?

Sure, see #4366

beeender · 2017-03-21T12:49:18Z

@realm/java This is ready for review.
@bmeike I removed some tests from backlink test set because of those notification on backlinked object should not be triggered when the parent changes. They passed before simply because of we fire lots of false positive notification on RealmObject before. But let me know if there are any tests related to this PR need to be added to the backlink tests.

cmelchior

Didn't have time for a full review. So only got halfway through it. Mostly minor stuff.

cmelchior · 2017-03-21T19:18:43Z

realm/realm-library/src/androidTest/java/io/realm/LinkingObjectsManagedTests.java

-    // A listener registered on the backlinked object should be called when a commit adds a backlink
-    @Test
-    @RunTestInLooperThread
-    public void notification_onCommitModelObject() {


It feels like a mistake to delete this test? Perhaps a restriction in the Object Store?

no, it is not. And it is expected behavior from object store.
Line 175 called parent.setFieldObject(child);, the changed object is parent, but the original test added listener on child which won't be trigger since nothing changed on the child. I am not quite sure what is the purpose of this test, maybe @bmeike can help to clarify this.

Technically the RealmResults field on child is a field with a (backlink) reference to the parent, so one could argue it should trigger the same type of notification as when a RealmList changes. I'm fine with leaving it as it is right now, but we should probably document that somewhere.

Yeah... I'm with Christian on this. Something has, most definitely, changed, for the child. child.backLinkedField.size(), for instance, is different. That is, clearly, a change.

If notifications on backlinks are not supported, that's life. We need clear documentation of the fact, though.

Clarified in the javadoc of LinkingObjects.

cmelchior · 2017-03-21T19:18:52Z

realm/realm-library/src/androidTest/java/io/realm/LinkingObjectsManagedTests.java

-    // A listener registered on the backlinked object should be called when a backlinked object is deleted
-    @Test
-    @RunTestInLooperThread
-    public void notification_onDeleteModelObject() {


cmelchior · 2017-03-21T19:19:06Z

realm/realm-library/src/androidTest/java/io/realm/LinkingObjectsManagedTests.java

-    // This test exists only to document existing (but odd) behavior.
-    @Test
-    @RunTestInLooperThread
-    public void notification_notSentOnUnrelatedChangeModelObject() {


This was only here to document the old behaviour so 👍

cmelchior · 2017-03-21T19:19:32Z

realm/realm-library/src/androidTest/java/io/realm/LinkingObjectsManagedTests.java

-    // A JSON update should generate a notifcation
-    @Test
-    @RunTestInLooperThread
-    public void json_jsonUpdateCausesNotification() {


Not sure if this should be deleted?

cmelchior · 2017-03-21T19:24:39Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+
+    @Test
+    @RunTestInLooperThread(before = PopulateOneAllTypes.class)
+    public void changeDoubleField() {


All types doesn't seem to be covered. Missing is at least: boolean, float, byte[], Date

and int since the first test is covering long

long is just the same as int, and there is no int field in the AllTypes :(

cmelchior · 2017-03-21T19:37:16Z

realm/realm-library/src/main/java/io/realm/ObjectChangeSet.java

+    boolean isDeleted();
+
+    /**
+     * @return the names of changed fields if the object still exists and there are field changes. Returns {@code null}


Just return String[0] if no fields changed IMO. No reason to force a bunch of null-checks onto people.

cmelchior · 2017-03-21T19:38:19Z

realm/realm-library/src/main/java/io/realm/RealmObject.java

+     *
+     * @param listener the change listener to be notified.
+     * @throws IllegalArgumentException if the change listener is {@code null} or the object is an unmanaged object.
+     * @throws IllegalArgumentException if object is an unmanaged RealmObject.


You just stated that above.

cmelchior · 2017-03-21T19:40:06Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+     * When this gets called to return the results of an asynchronous query made by {@link RealmQuery#findFirstAsync()},
+     * {@code changeSet} will be {@code null}.
+     * <p>
+     * When this gets called because of the object is deleted, {@code changeSet.isDeleted()} will return {@code true}


because the object was deleted

cmelchior · 2017-03-21T19:40:32Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+     * When this gets called because of the object is deleted, {@code changeSet.isDeleted()} will return {@code true}
+     * and {@code changeSet.getFieldChanges()} will return {@code null}.
+     * <p>
+     * When this gets called because of the object is modified, {@code changeSet.isDeleted()} will return {@code false}


because the object was modified

cmelchior · 2017-03-21T19:41:39Z

realm/realm-library/src/main/java/io/realm/ObjectChangeSet.java

+     * @return the names of changed fields if the object still exists and there are field changes. Returns {@code null}
+     * if the object has been deleted.
+     */
+    String[] getChangedFields();


Can you make a list of outstanding issues? or known problems?

Zhuinden · 2017-03-22T10:47:44Z

Databinding support requires an ignored field. But that is a question of treating transient the same as @Ignore, and also that inheriting from a parent that has only ignored fields needs to be allowed by the annotation processor

kneth · 2017-03-24T10:16:18Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+                looperThread.testComplete();
+            }
+        });
+    }


What if multiple fields are changed in the same transaction?

Added a test case.

kneth · 2017-03-24T10:42:34Z

realm/realm-library/src/main/cpp/io_realm_internal_OsObject.cpp

+    {
+        JNIEnv* env = JniUtils::get_env(false);
+        if (!env || env->ExceptionCheck()) {
+            // JVM dettached or java exception has been thrown before.


"dettached" -> "detached"

kneth · 2017-03-24T10:52:56Z

realm/realm-library/src/main/java/io/realm/RealmObject.java

@@ -313,11 +313,22 @@ public final boolean load() {
    }

    /**
+     * Adds a change listener to this RealmObject to get detailed information about the changes.


"about the" -> "about"

kneth · 2017-03-24T10:54:50Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+
+/**
+ * {@code RealmObjectChangeListener} can be registered on a {@link RealmModel} or {@link RealmObject} to receive
+ * detailed notification when a object changes.


"notification" -> "notifications"

kneth · 2017-03-24T10:55:36Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+ * Realm instances on a thread without an {@link android.os.Looper} cannot register a {@code RealmObjectChangeListener}.
+ * <p>
+ *
+ * @param <T> The type of {@link RealmModel} where your listener will be registered on.


"where" -> "on which"?

kneth · 2017-03-24T11:00:44Z

realm/realm-library/src/main/java/io/realm/internal/SharedRealm.java

@@ -428,6 +429,38 @@ void invalidateIterators() {
        iterators.clear();
    }

+    // addPendingRow, removePendingRow and executePendingRow queries is to solve that the listener cannot be added


"is" -> "are"

kneth · 2017-03-24T11:01:08Z

realm/realm-library/src/main/java/io/realm/internal/SharedRealm.java

@@ -428,6 +429,38 @@ void invalidateIterators() {
        iterators.clear();
    }

+    // addPendingRow, removePendingRow and executePendingRow queries is to solve that the listener cannot be added
+    // inside a transaction. For the findFirstAsync(), listener is registered on a Object Store Results first, then move


"a Object" -> "an Object"

kneth · 2017-03-24T11:01:49Z

realm/realm-library/src/main/java/io/realm/internal/SharedRealm.java

+    // inside a transaction. For the findFirstAsync(), listener is registered on a Object Store Results first, then move
+    // the listeners to the Object when the query for Results returns. When beginTransaction() called, all listeners'
+    // on the results will be triggered first, that leads to the registration of listeners on the Object which will
+    // will throw because of the transaction has began already. So here we execute all PendingRow queries first before


remove "will"
"has began already" -> "has already begun"

bmeike · 2017-03-24T18:11:54Z

I am just getting to this. I think that '@' to me, somehow did not actually notify me.
So, I'm not qualified to talk about "expected behavior" as far as core is concerned. I definitely would expect to be notified when the contents of a backlinked field changes. If that is not the case, then I think we need documentation that says that notifications do not work for backlinks.
I would prefer that either those UTs get re-enabled and pass or that we add documentation saying that backlink fields do not get notifications, before this commit goes in

bmeike

I believe that either those UT should be made to work, or we need to document the fact that notifications do not work for backlinks.

nhachicha · 2017-03-24T13:51:17Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+    public final RunInLooperThread looperThread = new RunInLooperThread();
+
+    @Before
+    public void setUp() {


Unused delete

nhachicha · 2017-03-24T13:51:23Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+    }
+
+    @After
+    public void tearDown() {


Unused delete

nhachicha · 2017-03-24T14:04:46Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+                        if (field.equals(name)) {
+                            break;
+                        }
+                        fail("Cannot find field " + name + " in field changes.");


shouldn't the fail be outside the for-loop?
current impl runs at most 1 iteration (either exit through break or fail)

nhachicha · 2017-03-24T14:08:04Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+            public void run() {
+                looperThread.testComplete();
+            }
+        }, 100);


If you're sure that the testComplete will be the last Runnable in the looper queue, then no need to use the delayed 100 ms. Just looperThread .postRunnable should suffice?

The event might be sent through the notifier thread and we have no control for that thread unfortunately. I don't like the delay here, and I don't like to rely on the fact we are triggering on the commitTransaction will trigger the listener either . So post delay is more "common" solution here.

Technically calling listeners for local commit in commitTransaction() will fix some silly bugs like #4384 so it is a good thing.

nhachicha · 2017-03-24T14:14:37Z

realm/realm-library/src/androidTest/java/io/realm/ObjectChangeSetTests.java

+
+    @Test
+    @RunTestInLooperThread(before = PopulateOneAllTypes.class)
+    public void changeIntField() {


the actual test is testing long not int maybe rename to changeLongField

nhachicha · 2017-03-25T16:34:16Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+
+/**
+ * {@code RealmObjectChangeListener} can be registered on a {@link RealmModel} or {@link RealmObject} to receive
+ * detailed notification when a object changes.


a -> an object

nhachicha · 2017-03-25T16:34:57Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+ * detailed notification when a object changes.
+ * <p>
+ * Realm instances on a thread without an {@link android.os.Looper} cannot register a {@code RealmObjectChangeListener}.
+ * <p>


Cannot also register within a transaction

nhachicha · 2017-03-25T16:39:31Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+     * and {@code changeSet.getFieldChanges()} will return {@code null}.
+     * <p>
+     * When this gets called because the object was modified, {@code changeSet.isDeleted()} will return {@code false}
+     * and {@code changeSet.getFieldChanges()} will return the detailed information about the fields' changes.


fields' -> field's

it means fields's here.

nhachicha · 2017-03-25T16:42:05Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+     * If a field points to another RealmObject this listener will only be triggered if the field is set to a new object
+     * or null. Updating the referenced RealmObject will not trigger this listener.
+     * <p>
+     * If a field points to a RealmList, this listener will only be triggered if a objects are inserted, removed or


if a -> if one or many objects were inserted, removed or ..

nhachicha · 2017-03-25T16:45:17Z

realm/realm-library/src/main/java/io/realm/RealmObjectChangeListener.java

+     * or null. Updating the referenced RealmObject will not trigger this listener.
+     * <p>
+     * If a field points to a RealmList, this listener will only be triggered if a objects are inserted, removed or
+     * moved within the List. Updating the objects in the RealmList will no trigger this listener.


will no -> will not

- The listeners on RealmList/RealmResults will be tiggered immediately when the transaction committed on the same thread if the collections are changed or the async query should return. - Listeners on the RealmObject will have same behaviour after #4331 merged. This is to solve the problem for predictive UI animations and local transactions. Fix #4245

cmelchior · 2017-03-27T08:22:45Z

realm-annotations/src/main/java/io/realm/annotations/LinkingObjects.java

@@ -57,6 +57,7 @@
 *     <li>They are ignored when doing a `copyToRealm().`</li>
 *     <li>They are ignored when doing a `copyFromRealm().`</li>
 *     <li>They are ignored when using the various `createObjectFromJson*` and `createAllFromJson*` methods.</li>
+ *     <li>The listeners on parent object won't be triggered when the linking objects changes.</li>


Perhaps rephase. I especially find "parent object" confusion since I assume it means the object pointing to this object.

Suggestion:
Listeners on an object with a @LinkingObject field will not be triggered if the linking objects change, e.g if another object drops a reference to this object.

cmelchior · 2017-03-27T08:29:15Z

realm/realm-library/src/main/java/io/realm/RealmObject.java

@@ -354,6 +365,30 @@ public final boolean load() {
    }

    /**
+     * Adds a change listener to a RealmObject.


That is how the current change listeners work? The fine-grained object notifications work slightly different that way

cmelchior

Only some minor doc comments, otherwise this looks shippable.

kneth · 2017-03-28T11:46:40Z

realm/realm-library/src/main/java/io/realm/internal/SharedRealm.java

    // the listeners to the Object when the query for Results returns. When beginTransaction() called, all listeners'
    // on the results will be triggered first, that leads to the registration of listeners on the Object which will
-    // will throw because of the transaction has began already. So here we execute all PendingRow queries first before
+    // throw because of the transaction has already began. So here we execute all PendingRow queries first before


"began" -> "begun"

Zhuinden · 2017-03-29T10:22:36Z

realm-annotations/src/main/java/io/realm/annotations/LinkingObjects.java

@@ -57,7 +57,6 @@
 *     <li>They are ignored when doing a `copyToRealm().`</li>
 *     <li>They are ignored when doing a `copyFromRealm().`</li>
 *     <li>They are ignored when using the various `createObjectFromJson*` and `createAllFromJson*` methods.</li>
- *     <li>The listeners on parent object won't be triggered when the linking objects changes.</li>


oh, so they are triggered? Cool.

no, but the next line in this file is talking about the same thing :p

oh, so I should learn how to read 😄

bmeike · 2017-03-29T16:45:20Z

Thanks for adding the doc. I think that will reduce the number of surprised developers!

realm-ci assigned beeender Mar 16, 2017

beeender mentioned this pull request Mar 16, 2017

Single Object Notifications #4101

Closed

6 tasks

beeender added S:Review T-Enhancement labels Mar 16, 2017

kneth reviewed Mar 16, 2017

View reviewed changes

cmelchior reviewed Mar 16, 2017

View reviewed changes

dalinaum reviewed Mar 17, 2017

View reviewed changes

beeender added S:In Progress and removed S:Review labels Mar 17, 2017

zaki50 changed the title ~~Add detailed notifcation for RealmObject~~ Add detailed notification for RealmObject Mar 18, 2017

beeender added 9 commits March 21, 2017 10:42

Merge remote-tracking branch 'origin/master' into mc/object-notification

3443fca

Rename RowObject

87289a5

Format code

49b66cc

Clean interface

2c80676

Remove useless code

a5351b9

Share RealmObject ObserverPairList with OsObject

cbad457

Merge remote-tracking branch 'origin/master' into mc/object-notification

029fef7

Remove unrelated backlink tests

a68a8a2

Backlinked object won't be notified when their parents object changed.

beeender commented Mar 21, 2017

View reviewed changes

Fix javadoc

7ab119e

beeender added S:Review and removed S:In Progress labels Mar 21, 2017

beeender mentioned this pull request Mar 21, 2017

ChangeListener no longer triggered on a findFirstAsync, after delete #4360

Closed

cmelchior reviewed Mar 21, 2017

View reviewed changes

cmelchior added this to the 3.1 milestone Mar 23, 2017

beeender added 4 commits March 24, 2017 11:25

javadoc fix

8281207

Convert LogicError to ISE

40045c7

T extends RealmModel for RealmObjectChangeListener

dc08078

Add isFieldChanged

643f122

kneth reviewed Mar 24, 2017

View reviewed changes

bmeike self-requested a review March 24, 2017 18:13

bmeike suggested changes Mar 24, 2017

View reviewed changes

nhachicha reviewed Mar 25, 2017

View reviewed changes

beeender added 4 commits March 27, 2017 12:41

Add all fields change test

77924ac

Doc fix

ac00ee9

LogicError has been converted to ISE

be9c0bb

PR fix

cdc59d5

cmelchior reviewed Mar 27, 2017

View reviewed changes

cmelchior approved these changes Mar 27, 2017

View reviewed changes

More fix for javadoc

a883850

kneth reviewed Mar 28, 2017

View reviewed changes

Fix comments & javadoc

07f3020

kneth approved these changes Mar 29, 2017

View reviewed changes

Zhuinden reviewed Mar 29, 2017

View reviewed changes

bmeike approved these changes Mar 29, 2017

View reviewed changes

Merge remote-tracking branch 'origin/master' into mc/object-notification

6841a38

beeender merged commit 6361326 into master Mar 30, 2017

beeender deleted the mc/object-notification branch March 30, 2017 02:59

beeender removed the S:Review label Mar 30, 2017

beeender mentioned this pull request Mar 30, 2017

Get a notification about deleted RealmObject #4398

Closed

github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2024

Add detailed notification for RealmObject #4331

Add detailed notification for RealmObject #4331

Conversation

beeender commented Mar 16, 2017

beeender commented Mar 16, 2017 • edited Loading

beeender commented Mar 16, 2017

kneth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmelchior left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmelchior Mar 16, 2017 • edited Loading

Choose a reason for hiding this comment

cmelchior Mar 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beeender Mar 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmelchior Mar 16, 2017 • edited by beeender Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beeender commented Mar 21, 2017

cmelchior left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmeike Mar 24, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Zhuinden commented Mar 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmeike commented Mar 24, 2017 • edited Loading

bmeike left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beeender commented Mar 16, 2017 •

edited

Loading

cmelchior Mar 16, 2017 •

edited

Loading

cmelchior Mar 16, 2017 •

edited

Loading

beeender Mar 20, 2017 •

edited

Loading

cmelchior Mar 16, 2017 •

edited by beeender

Loading

bmeike Mar 24, 2017 •

edited

Loading

bmeike commented Mar 24, 2017 •

edited

Loading