Instead of caching pending messages during the handshake and relaying
them afterwards, they are now sent after the handshake has been
completed.
This is possible because the relevant processors (messages and status
changes) are now event handlers which are registered at the event bus,
which means that they can immediately react to pending messages even if
Client#initReceiver has not been fully executed yet.
Because Client#initReceiver exists for that very reason, it is no
longer necessary anymore. ID generator initialization, which was its other part,
is now directly handled in Startup#performHandshake, which is a far more
sensible placement.
Fixes#106
Reviewed-on: https://git.kske.dev/zdm/envoy/pulls/111
Reviewed-by: DieGurke <maxi@kske.dev>
A bug remains when the total status of a group message is SENT, but the
individual status for the client user is RECEIVED. In this case, the
counter should be incremented but isn't.
This causes problems with group messages as the received date is null
sometimes even though the status is RECEIVED.
The ReceivedMessageProcessor on the client filters out the synced
messages at the moment.
Common
* Replace LocalDateTime with Instant everywhere
Client
* Display message creation date with system time zone in MessageControl
* LocalDB#users now strictly contains Users
* lastSync time stamp in LocalDB (saved per user)
* isOnline parameter in save function (lastSync updated if true)
* lastSync time stamp in LoginCredentials
* No ClientConfig#getLoginCredentials because of missing information,
moved to LoginScene
* Pass LocalDB#lastSync to LoginCredentials in LoginScene
Server
* Explicit lastSync parameter for
PersistenceManager#getPending(Group)Messages
This sends the correct time stamp to the server, however the JPQL
queries have yet to be adjusted.
Kai S. K. Engelbart
Leon Hofmeister
Maximilian P. Käfer