FLEX-35043 CAUSE: The solution implemented for FLEX-34885, which had an problematic consequence: when calling itemUpdated(item) on a collection with only the first parameter provided (which developers usually do to signal that some - unspecified - properties of the item have changed), ListCollectionView.handlePropertyChangeEvents() would treat that as if the object had been just introduced to the collection - as "property" was null -, replacing a null value - since oldValue was null as well. (That is to say, when the "property" value of the PropertyChangeEvent was null, it was taken to mean that the oldValue - which was also null here - was changed into that item, i.e. the object reference changed in the collection, not just one of the object's properties.) As such, it would try to remove that supposedly existing null value from the collection (and sometimes a null does exist, but shouldn't be removed). In a way this was logical based on the properties supplied to itemUpdated(), but we also know that a frequent use of that function is with only one parameter, to specify that some of the object's properties have changed (but the object itself should still be in the collection). So we should continue to support this use case.
SOLUTION: now ListCollectionView.handlePropertyChangeEvents() only assumes that the entire object has been replaced in the collection if the event's "property" is null AND if either its "oldValue" or "newValue" is non-null. In other words, if the developer entered all these arguments into the function or in the event they're dispatching, and one of them is non-null, it probably means they want to signal that the entire object has changed in the collection.
NOTES: -renamed "entireObjectChanged" into "objectReplacedWithAnother" to emphasize that it's not the object's internal state that "entirely changed", but that the object itself was replaced in the collection by another object instance. -some of the unit tests in ListCollectionView_PropertyChangeEvent_Tests are now failing, which is expected.
FLEX-34885 Added a new unit test class, ListCollectionView_PropertyChangeEvent_Tests, that not only tests a few scenarios to make sure that ListCollectionView reacts as expected to PropertyChangeEvents, but also makes explicit 2 of the consequences of manually dispatching PropertyChangeEvents through the VOs in the list without specifying a "property" and an "oldValue" in the PropertyChangeEvent: 1. null is assumed to have been replaced in the collection by that VO, so it will be removed if it already exists. This may be unexpected to developers. 2. if there's a customCompareFunction in the Sort object, it will be called with null as one of the arguments. This may again be unexpected to developers. NOTES: -also removed some whitespace and improved asdocs.