This can improve the start-up time of apps.
The three big db reads on init are
loading account data, rooms and
device keys.
This makes it now possible to let
them run parallel
(while it may depend on platform
if this has any effect)
and the init() method can skip
awaiting them. They will
be at least awaited before handling
the first received sync.
So the app can already display the
room list before device keys are
loaded and request the first sync
from the server before anything
else is loaded from the DB.
Apps had a hard time to just set
the marker for the last event.
The lastEvent in the Room may
not be the actual last event
because we ignore several
event types there. Therefore
it makes sense to refactor
the setUnread method.
Now the timeline class has an
easy method to set the read
marker to the last synced
event, which can only be
known by the timeline if we
want to avoid another DB access.
This makes it finally possible to
use Flutters AnimatedListView with
our Timeline class and in web we
can now update single elements
instead of the whole timeline
on every change which should
be quiet good for the
performance
fix: add room invite update to roomStateBox, so invites don't show empty room when app is restarted
Closes#228
See merge request famedly/company/frontend/famedlysdk!865
Room states are ignored if the event with the same event ID
is already known in the database. But
because of the event is stored in the
database and after this
setState in the Room class is called,
an event is always "known" and
therefore auto updating was broken.
Events with a status of 1 should be sorted in the normal timeline.
They should not be stucked at the bottom. This fixes a bug
where a limited timeline flag
can stuck a SENT event at the bottom of
the chat forever.
When requesting history the `start` parameter could become larger than the loaded events
from the database were, resulting in an error when attempting to request history.