BUILDING A UNIFIED WEBRTC LIBRARY FOR XAMARIN.
1. INTRODUCTION TO THE ARTICLE
Up until now in this series, we have followed specific rules and steps in the quest to achieve the specific articles stated goals.
If you recall, to build the native iOS and Android WebRTC libraries, we had to follow sequential steps to successfully build and package the libraries.
In this tutorial, we will be doing things differently because, although our stated objective is to build a cross-platform Xamarin WebRTC library, how we achieve this entirely up to us. As a result, this tutorial requires a lot more thinking, designing, and programming of a solution to the stated objective. I will break down the article into sections and subsections were
necessary.
Itemized below are the main sections of this article:
1. INTRODUCTION TO THE ARTICLE.
2. USEFUL TOOLS, RESOURCES & CODEBASES USED.
3. THINKING BOARD.
4. DESIGN BOARD.
5. CODE EXECUTION.
6. AFTER THOUGHTS.
2. USEFUL TOOLS, RESOURCES & CODE BASES
1. Visual Studio 2019 for Mac -Required
2. Visual Studio 2019 for PC — Optional
3. JetBrains Rider for Mac or PC — Optional
4. Google WebRTC Android SDK Repo — Required
5. Google WebRTC iOS SDK Repo — Required
6. Valentingrigorean — apprtc-ios-xamarin — Optional but especially useful
7. WebRTC Unified Xamarin Repo — Recommended
3. THINKING BOARD
To develop a plan of action to design and build a Xamarin WebRTC library, you need to have a good understanding of three things:
i. General understanding of available WebRTC core functionalities in available libraries such as the JavaScript Library, this information can be gathered in the WebRTC-Guides
ii. A complete bird’s eye view of all WebRTC objects in the Android SDK. This can be achieved by exploring the Google WebRTC Android SDK Repo and using Visual studio’s Object Explorer or JetBrains Rider’s Assembly Explorer to see all object types in the previously created Xamarin Android Binding library.
iii. A complete bird’s eye view of all WebRTC objects in the iOS SDK: This can be achieved by exploring the Google WebRTC iOS SDK Repo and using Visual studio’s Object explorer or JetBrains Rider’s Assembly Explorer to see all object types in the previously created Xamarin i0S Xamarin Binding library.
Once you have looked through these 3 resources and built an understanding of all WebRTC Core objects, how they interact with each other and the roles they play in the facilitation of the communication between devices, you can then commence thinking of the ways to represent the WebRTC Objects in your library.
4. DESIGN BOARD
After reviewing all resources, I had at my disposal, I itemized things I noticed below:
i. Both the Android and iOS Xamarin libraries had similar objects i.e. PeerConnection, DataChannel, AudioSource etc. However, “RTC” was prepended to all objects in the iOS Xamarin libraries.
ii. In both Android and iOS libraries, their constituent objects typically inherited from other constituent objects otherwise they inherited from NSObject in iOS and Java.Lang.Object in Android.
iii. Although both Android and iOS libraries have similar objects, in some instances of these objects, certain properties found in one library was not found in another. Additionally, some instances of objects had dissimilar implementations in iOS and Android.
iv. The naming conventions of Event Handlers, Methods and some Properties in similar WebRTC Objects differed slightly in the iOS and Android.
With all this in mind, I developed a plan of action to consume the Xamarin iOS and Android bindings in a Unified Xamarin library. In its simplest form:
i. Create a multi-platform .NET Standard Project that targets both iOS and Android. This implies your solution explorer view will have a Shared codebase, an Android targeted codebase and an iOS targeted code base.
ii. Create Interfaces to represent WebRTC objects found in both Android and iOS. The methods and properties in these interfaces should be available in the platform specific level of the individual Xamarin bindings. If not available, do not put them in the Interface but save them for the implementations of the said Interfaces.
iii. Create Enums, Constants found in both Android and iOS.
iv. Create a platform agnostic converter that converters your objects to the appropriate Xamarin bindings objects and vice versa.
v. In the Platform targeted codebases, Implement the Shared Interfaces and object converters that are platform specific.
The Image below, illustrates my design decision:
5. CODE EXECUTION
The WebRTC library has several objects, hence to implement every object in its interface forms and class forms on both iOS and Android and also create converters for all of these to facilitate the uses in Xamarin Apps and the Xamarin binding library will take a lot more than a week to program.
Since this is a weekly series, I wrote code for some of the WebRTC objects I will be needing in the Xamarin Forms application. I implemented several WebRTC objects which include but are not limited to the following: DataChannel, AudioSource, VideoSource, AudioTrack, VideoTrack, PeerConnection, PeerConnectionFactory and DtmfSender. This is an ongoing process and will continue after this series of articles have been published. If you want to see the progress, you can find the repository here: Xamarin-WebRTC-Tutorial
6. AFTER THOUGHTS
Looking through the internet, WebRTC tutorials talk about two key Servers:
TURN Server & Signalling Server. There are several tutorials that show you how to build your own TURN Server, so I will not be discussing that in this Series.
Instead, I will be using a 3rd Party Commercial server: XIRSYS TURN SERVERS. Additionally, in several tutorials, the Signalling Server is implemented by building a simple JavaScript or Python Web Sockets Server or using Google’s Demo App RTC Signalling server.
Because I want this tutorial to use .NET based technologies only and potentially provide readers with a blueprint on how to create your own WebRTC Solution using only .NET Technologies, for the next article in the series, I will be leveraging the power of .NET Core and SignalR to build a custom Signalling Server.
Until next week. Take care.
