[Calling][Feature] Rooms v1

[pavelprystinka]

Purpose

• ...

Does this introduce a breaking change?

• [ ] Yes
• [ ] No

Pull Request Type

What kind of change does this Pull Request introduce?

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Documentation content changes
• [ ] Other... Please describe:

Pull Request Checklist

• [ ] Public API changes
• [ ] Verified for cross-platform
• [ ] Synced with iOS, Web team
• [ ] Internal review completed
• [ ] UI Changes
  • [ ] Screen captures included
  • [ ] Tested for Light/Dark mode
  • [ ] Tested for screen rotation
  • [ ] Tested on Tablet and small screen device (5")
  • [ ] Include localization changes
• [ ] Tests
  • [ ] Memory leak analysis performed
  • [ ] Tested on API 21, 26 and latest
  • [ ] Tested for background mode
  • [ ] Unit Tests Included
  • [ ] UI Automated Tests Included

How to Test

• Open...
• Click on...

What to Check

Verify that the following are valid

• ...

Other Information

[ahammer]

GPT Breakdown of the additions.

The provided code snippets appear to be part of an update to an Android application that uses Azure Communication Services, specifically extending the functionality to include "Rooms Calls" alongside existing "Group Calls" and "Teams Meetings". This is done by introducing a new call type (ROOMS_CALL), room ID (roomId), and participant roles (CallCompositeParticipantRole with PRESENTER and ATTENDEE) into the application. Let's review each part of the changes:

1. Addition of ROOMS_CALL to CallType enum and new fields to CallConfiguration:

   • The addition of ROOMS_CALL is straightforward, indicating a new type of call supported by the application.
   • The CallConfiguration class has been expanded to include roomId, which is presumably a unique identifier for a room, and roomRoleHint, which suggests the intended role of the participant in the room call.

2. Updates in CallingSDKWrapper.kt:

   • The logic for determining the type of call locator based on the callType has been updated to handle ROOMS_CALL, creating a RoomCallLocator with the provided roomId. This aligns with the application's strategy to support different types of calls through specific locators.

3. UI Adjustments in CallLauncherActivity.kt:

   • New UI components (like radio buttons) and logic have been added to handle user interaction for selecting a rooms call, and to dynamically adjust the available roles based on the type of call selected. This enhances the user interface to accommodate the new call type and roles, making it user-friendly and interactive.

4. Handling Rooms Call in CallLauncherViewModel.kt and CallComposite.java:

   • The logic to launch a call composite with the new CallCompositeRoomLocator is introduced, handling cases where a rooms call is initiated. It ensures that the room ID and role are passed correctly to set up the call.
   • In CallComposite.java, the configuration is extended to support roomId and roomRole, demonstrating how the application's internal logic adapts to accommodate rooms calls.

5. Definition of CallCompositeParticipantRole and CallCompositeRoomLocator:

   • The CallCompositeParticipantRole class provides a clear definition of possible roles within a rooms call, allowing for explicit role management and assignment.
   • The CallCompositeRoomLocator class facilitates the initiation of rooms calls by holding the room ID, serving as a specific locator type for this call mode.

6. XML UI Changes:

   • The introduction of a new RadioButton for selecting rooms meetings in the UI (activity_call_launcher.xml) indicates a direct interaction point for the user to choose this new call type, integrating it into the existing UI layout seamlessly.

Overall Review:

• The changes are well-structured and consistent across the different files, showing a clear path towards integrating a new type of call (Rooms Calls) into the application.
• The code follows good practices by keeping the UI logic separate from the backend logic and by using enums and specific classes to handle different call types and roles cleanly.
• It would be beneficial to ensure that there are corresponding updates in documentation, tests, and localization files (strings.xml for UI text) to fully support these changes.
• Additionally, considering the security and privacy implications of introducing new call types and roles is essential, especially in terms of access control and permissions during a rooms call.