Proximity sensor events should not have been part of
PeerConnectionEvent. However, now that all the peer connection related
properties were removed the remaining event can be renamed to something
more accurate.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than simplifying the states to "CONNECTED" and "DISCONNECTED" now
the raw state is posted, and the handler then decides how to treat them
(which, for now, is exactly as before).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than emitting PUBLISHER_FAILED when the publisher connection
fails now PEER_FAILED is emitted when any connection fails, and the
handler checks if the connection was the publisher one to apply the
specific behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only the same data channel messages that were already handled
are taken into account, but at a later point the missing messages
("speaking" and "stoppedSpeaking") could be added too.
Note that the thread used to handle the data channel messages has
changed; the EventBus subscriber mode was "MAIN", but as the messages
were posted from a DataChannel observer, which run in a worker thread
rather than in the main thread, the subscriber was executed in the main
thread rather than in the same thread as the poster. Due to this the
actions performed by the handler now must be explicitly run in the main
thread.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the thread used to send the message does not change; the
EventBus subscriber mode was "BACKGROUND", but as the messages were
posted from a WebSocket handler (when requesting offers to the HPB) and
peer connection observers (when sending offers/answers and candidates,
both with and without HPB), which run in worker threads rather than in
the main thread, the subscriber was executed in the same thread as
the poster.
For legacy reasons, when the internal signaling server is used the
offers and answers are expected to also provide the nick of the local
participant. When the external signaling server is used the field can be
included, but it is just ignored and not sent to the other clients. As
the local participant nick is a value unrelated to the peer connection
and is only needed with one type of signaling server the messages are
adjusted as needed before being sent rather than handling this inside
the PeerConnectionWrapper.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
- add missed call notifications in NotificationWorker and CallNotificationActivity
- introduce refactoring of Notification handling (isolate firebase stuff from other logic). All "UI-notification" logic from ChatAndCallMessagingService was moved to NotificationWorker. ChatAndCallMessagingService was renamed to NCFirebaseMessagingService because it is now only responsible for firebase stuff. This separation should make it easier for alternative push services to dock with the app (if they are incorporated in the future).
- for DEBUG mode: show delivery delay time in notifications (time between sending from firebase to receive on device).
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
RTCPeerConnections have several states but, for simplicity, for now the
events posted reflect only if the connection is fully established or
not (which includes both a broken connection or an established
connection that is unstable or being updated), which is enough for a
basic information about the connection state in the UI.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
BottomSheetLockEvent was only used for old bottom dialog with "kennyc" lib
instead ConversationsListFetchDataEvent.kt is now used to fetch the data in ConversationsListController whenever needed
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
