add chatlist changed event

[Simon-Laux]

adds an event that signals the ui to reload the chatlist. (when order changes or items are added/removed)
currently DC_EVENT_MSGS_CHANGED with chatid 0 is sometimes used for that, but it's missing at some places.
so in the long run I think it would make sense to deprecate DC_EVENT_MSGS_CHANGED and replace it with more distict/specific smaller events.

also desktop already emulates this event, so merging this can remove that logic from the desktop code.

[link2xt]

I'd rather have it named ChatlistChanged and use CHATLIST for consistency with already existing Chatlist type.

[link2xt]

Removing ChatId::new(0) everywhere would be very nice indeed.

[Hocuri]

Android just registers for all events that could change the chatlist:

    eventCenter.addObserver(DcContext.DC_EVENT_CHAT_MODIFIED, this);
    eventCenter.addObserver(DcContext.DC_EVENT_CONTACTS_CHANGED, this);
    eventCenter.addObserver(DcContext.DC_EVENT_INCOMING_MSG, this);
    eventCenter.addObserver(DcContext.DC_EVENT_MSGS_CHANGED, this);
[Note: the next four events can only do changes within existing chats]
    eventCenter.addObserver(DcContext.DC_EVENT_MSGS_NOTICED, this);
    eventCenter.addObserver(DcContext.DC_EVENT_MSG_DELIVERED, this);
    eventCenter.addObserver(DcContext.DC_EVENT_MSG_FAILED, this);
    eventCenter.addObserver(DcContext.DC_EVENT_MSG_READ, this);

and then debounces chatlist reloading to 100ms (loadChatlistAsync()) (it also registers for CONNECTIVITY_CHANGED and SELFAVATAR_CHANGED but doesn't reload the chatlist for these events). And in the most cases, these events do mean that the chatlist has to be reloaded, so we don't do many unnecessary reloads.

I'm not totally sure about this PR, as it introduces a place where things can go wrong. Like, we could forget a place where we would have to emit ChatListChanged.

It looks like the first four events above can add/remove/reorder chats and require a full chatlist reload, while the last four events only do changes within existing chats.

Maybe you can use these events in Desktop, too?

If this works for you, too, we should probably point out in the documentation that these are the events that can be used for chatlist reloading.

[Hocuri]

Emitting the event is already done in delete()

[Hocuri]

Does "or contents" mean that the event is also fired if something within a chatlist item changed (like, a read receipt was received for the last message you sent and now two green checkmarks are shown)

[Simon-Laux]

no, I'm open for suggestion on how to make this more clear

[r10s]

currently DC_EVENT_MSGS_CHANGED with chatid 0 is sometimes used for that

well, "sometimes" seems to be a bit understated here - in fact, DC_EVENT_MSGS_CHANGED is sent in all cases where the new event is sent - apart from contact blocking, and i would consider this as a bug.

so, in practice, DC_EVENT_MSGS_CHANGED is always followed by a DC_EVENT_CHATLIST_CHANGED. i can imagine that such an event could be useful for batch updates or so, but this is not part of this pr, and i also think, debouncing would be needed anyway.

so, not sure if the added complexity and the doubled events help much here.

and i agree, we should not merge that now, we are in release phase and there are already lots of moving targets and bug came in by revamped things, and this again has the potential to break things badly, esp. when we start to modify existing events.

also, as desktop handles the events as they are already ("also desktop already emulates this event"), it seems not be helpful for current issues or needed urgently.

[Simon-Laux]

Android and iOS don't always display the chatlist.
Also I don't like the DC_EVENT_MSGS_CHANGED event as it can mean multiple things, so I'd suggest breaking it up into smaller events in the long run.

But sure maybe it's better for now to just put a DC_EVENT_MSGS_CHANGED(chatid=0) event where ever I placed a chatlist update and there currently isn't a DC_EVENT_MSGS_CHANGED yet.
and change its documentation that it's clearer that it should be used for that.

[r10s]

Android and iOS don't always display the chatlist.

but they could, this is not an issue with the current events when listening to the interesting ones as @Hocuri pointed out above.
in fact, the activity with the chatlist is never destroyed or so but is updated by events even if overlaid completely - that way, you can go back amazingly fast. for ios, we just changed to the same behavior, making things much more responsive.

But sure maybe it's better for now to just put a DC_EVENT_MSGS_CHANGED(chatid=0) event where ever I placed a chatlist update and there currently isn't a DC_EVENT_MSGS_CHANGED yet.
and change its documentation that it's clearer that it should be used for that.

+1 - these affects blocking contacts only.

i suggest to close this pr, do that in another pr and go for w30 or so then :) there are bigger fishes to get :)

i would not be up for revamping the event system currently.

[r10s]

we thought that over recently, as already pointed out above, it makes sense to introduce a DC_EVENT_CHATLIST_CHANGED in addition to the existing events. however, that would make sense only of that new DC_EVENT_CHATLIST_CHANGED is debounced and only be emitted when all messages and updates arrived, avoiding UIs being blocked by lots of updates.

we could introduce that new event easily, and the chatlists would just listen to that event instead of DC_EVENT_MSGS_CHANGED/DC_EVENT_INCOMING_MSG (that part is also the gist of this pr).