* refactor: Removed @Nullable annotations and converted CallCompositeNavigationBarViewData to use Fluent construction
* Converted CallCompositeLocalOptions to also use Fluent construction
Co-authored-by: pavelprystinka <30868871+pavelprystinka@users.noreply.github.com>
* feature: Settings and usage of Call Title and Subtitle
* refactor: Made variables non-final and added no param constructor for CallCompositeLocalOptions
* Updated CHANGELOG with new feature line
* refactor: moved call title and subtitle to new CallCompositeNavigationBarViewData class and updated actionbar title colors to match Figma
* refactor: code formatting
* styling: changed textSize of title and subtitle of Actionbar to 17sp and 12sp to match Figma
* refactor: removed * import
* refactor: prefix all non-conforming ui elements with azure_communication_ui_
* refactor: changed id names in ui tests that were failing after refactor
There are four parts to enable basic multi-participant instrumented tests:
- Extract remaining native SDK references from the CallingSDK interface. Building up on the initial API extraction that resulted in the CallingSDK interface, and trying to build a mock implementation that's suitable to tests, it became evident that more interfaces were necessary to hide the underlying native calling SDK library implementation.
- Allow injecting a custom CallingSDK implementation into the library. Once we have a complete set of interfaces that are suitable for mocking, we need to allow their injection into our dependency container. This involves exposing an internal singleton (TestHelper) which acts as shared memory between SDK code and test code, and a natural injection point relying on the fact that we can run our instrumented tests in-process and use package access rules to get at the internal APIs.
- Use single-threaded dispatcher in AppStore, allow its injection. Instead of a handler (behaviour of which we can't control in tests), we use a Dispatcher in the AppStore that we can pass along via TestHelper. Then in tests, we can use the same scheduler for test code and code running in coroutines inside of the sdk to execute our work in a well-sequenced way.
- Actual multi-participant tests included in this commit are a basic demonstration of what a mock calling sdk implementation can look like, and how we can emulate remote events during a call. WebViews are used to actually display simulated "video streams".
Also included is some minor unrelated code cleanup.
Co-authored-by: Inderpal Singh Aulakh <73618019+iaulakh@users.noreply.github.com>
Inderpal Singh Aulakh
ShaunaSong
Mrayyan
Dhiraj Gupta
Albert Lo
Mohtasim
Grisha Kruglov
Peixin Liu
ddematheu2
pavelprystinka