0

i have a static final list with Overriden Methods:

protected final ArrayList<ABC> objects = new ArrayList<ABC>() {
        @Override
        public void add(int index, ABC object) {
            super.add(index, object);
            notifyChanged();
        }

        @Override
        public boolean remove(Object object) {
            boolean b = super.remove(object);
            notifyChanged();
            return b;
        }

        @Override
        public ABC remove(int index) {
            ABC b = super.remove(index);
            notifyChanged();
            return b;
        }

        @Override
        public boolean add(ABC object) {
            boolean b = super.add(object);
            notifyChanged();
            return b;
        }
    };

notifyChanged will call notifyOnDataSetChanged on a (Android-)Adapter.

The problem now is, if i call objects.remove(object), my notifyChanged is not called. I tried with LogCat (Log-Console on Android, like System.out.println) and with debugging, it is definetly not called!

Anyone has an idea why?

Normally it should work...

metinkale38
  • 718
  • 3
  • 10
  • 28
  • 1
    No exceptions thrown? Do you maybe swallow an exception? Can you step it through in the debugger? – Fildor Nov 23 '15 at 11:54
  • 1
    I would strongly recommend that you look at using delegation to create a notifying `ArrayList` rather than inheritance: it is much harder to capture all mutations via inheritance, e.g. notifying on `objects.subList(0, 1).clear()`. – Andy Turner Nov 23 '15 at 11:55
  • the `subList` does call into the original list's public methods for modifications, though. – Thilo Nov 23 '15 at 11:59
  • 1
    @Thilo [not true](http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/java/util/ArrayList.java#987), at least in the case of `set`. – Andy Turner Nov 23 '15 at 12:03
  • @AndyTurner: I see `parent.add`, `parent.remove` etc. So `clear` should work. `set` is not being overridden. – Thilo Nov 23 '15 at 12:04
  • @Thilo it might be the case that *some* mutation methods call the parent class, but at least one does not, and in any case that's an implementation detail on which you should not really rely (it's an example of the fragile base class problem). – Andy Turner Nov 23 '15 at 12:06
  • Either way, it does not help with the problem at hand. – Thilo Nov 23 '15 at 12:07

0 Answers0