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'm kinda in the same spot right now as olavbg has been when he opened up this (#78) ticket.
I am overwriting equals() and hashCode() as I need to compare Lists and use contains() while disregarding any FilterValues which may have been (user)set before.
On first start of the application (fresh database) while modifying and saving a Filter in my FilterFragment this Filter is being duplicated afterwards (without child objects - List is being omitted in this case).
This only happens on first start, while staying in the first (Home)View without switching activities and while overwriting hashCode.
If I comment out my custom hashCode(), this object duplication does not occur.
Possibly clarifying output from logcat - relevant parts being the Filter-object and the Rush='xxx' property:
hashCode() commented out, expected behaviour:
a textview with checkmark is toggled, the corresponding Filter is being modified and saved after
the first logcat snippet shows the wanted and expected behaviour: Rush='true', meaning the object has getId() != null; after saving, the List<> looks like I expected - no duplicated Filter objects, all children exist
the second logcat snipped shows something confusing: Rush='false' - afterwards we have duplicate entries inside our List<> without child objects
I could of course work around this problem by writing a custom contains() method which does not use equals() (meaning me not having to overwrite hashCode) but still I'd like to hear if such behaviour is to be expected? If yes, what's the reason for this?
PS: the same problem also applies to the FilterValue class which I've written a custom equals() and hashCode() for. As I don't need those right now I've commented them out for debugging purposes. If I use a custom hashCode on FilterValue as well, these objects also report Rush='false' on being modified after first start.
Kind regards,
Christian
The text was updated successfully, but these errors were encountered:
I'm starting a new ticket for this as the other one is closed already.
Closely related to #78 I guess.
I'm kinda in the same spot right now as olavbg has been when he opened up this (#78) ticket.
I am overwriting equals() and hashCode() as I need to compare Lists and use contains() while disregarding any FilterValues which may have been (user)set before.
I have the following (pseudocode) classes:
On first start of the application (fresh database) while modifying and saving a Filter in my FilterFragment this Filter is being duplicated afterwards (without child objects - List is being omitted in this case).
This only happens on first start, while staying in the first (Home)View without switching activities and while overwriting hashCode.
If I comment out my custom hashCode(), this object duplication does not occur.
Possibly clarifying output from logcat - relevant parts being the Filter-object and the
Rush='xxx'
property:hashCode() commented out, expected behaviour:
custom hashCode() in place, unexpected behaviour:
Explanation of log output:
Rush='true'
, meaning the object hasgetId() != null
; after saving, the List<> looks like I expected - no duplicated Filter objects, all children existRush='false'
- afterwards we have duplicate entries inside our List<> without child objectsI could of course work around this problem by writing a custom contains() method which does not use equals() (meaning me not having to overwrite hashCode) but still I'd like to hear if such behaviour is to be expected? If yes, what's the reason for this?
PS: the same problem also applies to the FilterValue class which I've written a custom equals() and hashCode() for. As I don't need those right now I've commented them out for debugging purposes. If I use a custom hashCode on FilterValue as well, these objects also report
Rush='false'
on being modified after first start.Kind regards,
Christian
The text was updated successfully, but these errors were encountered: