Before we have used the Event class for all
state events while for invite rooms those
actually were StrippedStateEvent objects. This
created some problems like we needed to set a
fake originServerTs (usually to DateTime.now()).
Actually we don't need the additional keys for
state events most of the time so just using
StrippedStateEvent for all states and typecasting
them to event where needed is not much of a
hassle while we benefit from a more clear
structure.
This also now uses StrippedStateEvent as a base
class for the User class which makes the User
class more minimal as keys like event_id and
origin_server_ts are no longer necessary. As we
create a lot of fake User objects where we had to
put fake values in it, it brings more benefits
than problems to just get rid of those fields.
This makes sure that the
users for an invitation are
correctly loaded so that we
can display the avatar, the
room displayname and
wether the room is a direct
chat or not.
This fixes the bug that the
actual dart Map in the state
has been manipulated because
we have not worked with a
copy of the map. Also this
crashes if the powerlevelmap
would had a wrong type in
users.
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.
Original issue and former solution by
The one with the braid <info@braid.business>
Special thanks for pointing out the problem.
This fixes that dart:io is imported into the
SDK database by moving it into it's own mixin which
makes it reusable and platform independent by
using conditional imports.
- removes `Directory` field in high-level `MatrixSdkDatabase`
- migrates `Directory fileStoragePath` to `Uri fileStorageLocation`
- makes file operations in `MatrixSdkDatabase` conditional on
`dart.libraries.js_util`
- implements a tiny stub of the file operations used in `MatrixSdkDatabase`
It seems like the Flutter tool can compile despite these imports. Sadly
the Dart standalone dart2js compiler doesn't reach there. While
refactorying the code, I decided it's likely cleaner to have a `Uri` as
storage location provider than using some fake directory or String as
relacement.
The advantage of a `Uri` at this place is the explicit `Uri.directory`
constructor available to ensure type and encoding safe directory
locations supporting both Windows and *nix.
Additionally, admitted, that's an edge-case, one could even
easily extend the use of a `Uri` based descriptor to support future
storage location accesses (e.g. IPFS or custom schemes for e.g. local
web browser based file system APIs). Using a `Uri`, one would only need
to override the three methods making use of the `fileStorageLocation`
property to handle different Uri schemes too.
Signed-off-by: The one with the braid <info@braid.business>