canRequestHistory could become false, even though you didn't load all
events from the database yet. So you had to either rely on fetching
until the requestHistory method throws or rely on other workarounds.
This makes requestHistory not throw, when the prev_batch is null, but
also makes canRequestHistory return sane values (but might require an
extra request, that does nothing).
This fixes several problems. First
sending a fake event through the
onEventUpdate stream was not a
good design and lead to problems
if you expect a timeline event but
then are unable to build the
event from json. This now uses
a new stream in the Client which
is listened to in the timeline to
delete an event which should be
much more reliable.
It also now throws an exception
if deleting the event fails
instead of returning true or false.
A deprecation note is added.
When using the searchEvent()
method it was impossible to
paginate to the next
chunk when one chunk had
0 returned events. This
fixes it by returning the
prevBatch and makes it
possible to insert the prevBatch
again. sinceEventId is still
working but now deprecated.
BREAKING CHANGE: This changes the runInRoot method to not return a
future. As a user, if you need the result of an async computation passed
to runInRoot, please await it directly. Also the KeyVerification start
and a few call methods now return a future.
You can either set them to private on the client or overwrite the
behaviour for that on each readMarker call. This also handles incoming
thread receipts and tries its best to figure out what is the latest
receipt. This however breaks the old m.receipt account data event.
This fixes a bug that the
last message was sent
incorrectly when a session
key received for example
from the key backup. It may
fix several issues like the
last message is set as a
very old one or the last
message is not decrypted.
When opening a room we need to
fetch all users from the database.
Otherwise we would need to
update the timeline per user after
creation which should be much slower.
The redaction events should not
be displayed in the GUI but it
is the job of the app to hide
them from the timeline while
the SDK should offer an
accurate list of ALL timeline
events by default.
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
RoomUpdate came from a time where we had no data model for
SyncUpdates but now we have and therefore this class is just
code duplication. This removes the class
and uses the SyncRoomUpdate class from
the package matrix_api_lite instead.
It needed a lot of refactoring at some places
where I also have removed some unnecessary null or type checks.
The current implementation of sortOrder can be made way more easier now
by just keeping the sortOrder of the list
and the timelineFragments in the hiveStore. This needed a huge
change but mostly removes a lot of code which can be done
way more easy now. This also needed some rewriting of the setState logic and changes to
the prevEvent calculation. This solution should also be more stable.
More information:
https://www.reddit.com/r/fluffychat/comments/pfnlhq/the_sort_order_of_matrix_timelines/
Nicolas Werner
Krille
krille-chan
Krille
Ray
Malin Errenst
Philipp Grieshofer
henri2h
Henri Carnot
Reza
Jindřich Pikora
Jayesh Nirve