This makes use of dart
records to return three
different values for one
method. This makes the
special class no longer
necessary just for
returning data.
This changes the way how the last event is stored
for each room. It is now stored next to the
room event itself in the rooms box and no longer
stored like a room state. This way we need to
bump the database version which will cause an
inital sync for the client. Be aware of this when
updating the SDK!
This also makes sure that
the access token is
refreshed when calling
client.getEventByPushNotification()
which is porbably the most
common case for a client
with a stopped sync loop
doing network requests.
This fixes several problems with current soft logout
handling, as it now stores the refresh token correct and
only refreshs it 1 minute in advance instead of 5
minutes.
This was implicitly relying to the timestamp of state events getting
compared in the setState function. Fix this by using the helper
functions already used for invite and join rooms.
This changes the behavior
when client init fails. It
no longer calls logout and does
only clear local data while
returning all available
information in a new
exception type so that the
SDK consumer can decide
to logout or try again to init
with these information. This
should make it much more rare
that users loose their sessions.
This fixes the response
timeout for the initial
sync and sets it to 2
minutes instead of 10
seconds. This should increase
the speed for the initial
sync especially for large
accounts. This change
also adds some
documentation in the
code about what
timeout does what.
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.
- store left rooms in archive during sync (as well as they are removed
on join already)
- refactor room archive code
- fix typo
Internal reference: SMC-385
Signed-off-by: The one with the braid <info@braid.business>
If you create DM room, but the other party doesn't join it, they might
be unable to create a new DM using startDirectChat. Since creating a new
DM is pretty much the same as joining the invite, we try to join the
pending DM invite first and fall back to creating a new room if that
fails.
It wasn't quite obvious that invites were always sorted at the top, if
you just looked at the sort function. This makes it more explicit and
also makes invites always sort before favourited rooms.
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.