Stop delaying ElementCall until the next sync loop and only notify other participants when presumed to already be up to date. #3559
Conversation
…her participants when presumed to already be up to date.
Generated by 🚫 Danger Swift against 7c1cdaf |
|
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## develop #3559 +/- ##
===========================================
- Coverage 78.58% 78.53% -0.06%
===========================================
Files 757 757
Lines 63685 63683 -2
===========================================
- Hits 50048 50013 -35
- Misses 13637 13670 +33
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| // Here we assume that the app is running and the call state is already up to date | ||
| presentCallScreen(roomProxy: roomProxy, notifyOtherParticipants: !roomProxy.infoPublisher.value.hasRoomCall) |
There was a problem hiding this comment.
FWIW, I think it would signal the intent more clearly if notifyOtherParticipants was passed up in the action, having its value derived from context.viewState.hasOngoingCall in the room screen. WDYT?
| let colorScheme: ColorScheme = appMediator.windowManager.mainWindow.traitCollection.userInterfaceStyle == .light ? .light : .dark | ||
| presentCallScreen(configuration: .init(roomProxy: roomProxy, | ||
| clientProxy: userSession.clientProxy, | ||
| clientID: InfoPlistReader.main.bundleIdentifier, | ||
| elementCallBaseURL: appSettings.elementCallBaseURL, | ||
| elementCallBaseURLOverride: appSettings.elementCallBaseURLOverride, | ||
| colorScheme: colorScheme)) | ||
| colorScheme: colorScheme), | ||
| notifyOtherParticipants: notifyOtherParticipants) |
There was a problem hiding this comment.
Should we add this to the configuration rather than passing it in separately?
| @@ -132,52 +131,44 @@ class CallScreenViewModel: CallScreenViewModelType, CallScreenViewModelProtocol | |||
|
|
|||
| // MARK: - Private | |||
|
|
|||
| private func setupCall() { | |||
| private func setupCall(notifyOtherParticipants: Bool) { | |||
There was a problem hiding this comment.
Ok yeah answering my own question, I would say so given we access the configuration in this method.
We implementing ringing we observed that sometimes notifications were being sent multiple times, causing multiple incoming calls to appear. The reason for that was that the app wasn't necessarily up to date and the call member list wes still unknown.
The fix was to delay the starting of the call until the next sync loop but that in turn made entering an ElementCall slow. We are now reverting that and only, intentionally, sending a notification if the user presses the button and a call is not running yet. We're assuming that the app is already up to date at that point and that the call state is correctly known.
Relates to element-hq/voip-internal/issues/259