Migrating to IceLink 3

If you're coming from IceLink 2, you'll notice that a lot has changed in IceLink 3. While the Getting Started guide is a useful source of information for building your app, it's written for the benefit of developers without any IceLink experience. This guide is written for experienced IceLink 2 developers who want to get their application up and running with IceLink 3 as fast as possible.

How to Use This Guide

This guide is split in multiple sections, each focusing on a specific part of the SDK. The guide begins with the core parts of the SDK, such as establishing a conference and handling offers and answers. The later sections of the guide are related to extensibility options, such as custom render providers, and niche settings, such as disabling trickle ICE.

Each part of the guide will contain a brief description of the migration, as well as code samples for each platform showing the difference between the version 2 and version 3 SDK. There will also be a bullet-point Migration Steps section that provides step-by-step migration guidelines. Where possible, each part will also feature a More Information section, with links to other parts of the documentation site that may help you better understand the version 3 SDK.

This introduction covers a few general topics that don't fit nicely anywhere else and provides a small FAQ to answer some common questions that are too short to need their own section. If at any point, you feel the guide is missing something, reach out to our support team and we'll make sure that it gets added.

Updating Namespaces

IceLink 2 classes are separated into several libraries, each which has its own namespace:

  • FM: The Frozen Mountain common library, which contains functionality common to all Frozen Mountain Products, such as logging.
  • FM.IceLink: The base IceLink library.
  • FM.IceLink.WebRTC: IceLink library add-on to add more WebRTC compatibility and extensibility options.

With IceLink 3, these three libraries have been combined. As a result, there is only one namespace - FM.IceLink. This makes it easier to find a specific class because you don't have to guess the correct namespace. It also gives you more flexibility in how you use Frozen Mountain products. Because the common library is now bundled with each product, you can use different versions of Frozen Mountain products in the same project. A small example of how this change will modify your code is shown below.

// IceLink 2
FM.Log.Provider = new FM.ConsoleLogProvider(FM.LogLevel.Info);

// IceLink 3
FM.IceLink.Log.Provider = new FM.IceLink.ConsoleLogProvider(FM.IceLink.LogLevel.Info);
// IceLink 2
fm.Log.setProvider(new fm.ConsoleLogProvider(fm.LogLevel.Info));

// IceLink 3
fm.icelink.Log.setProvider(new fm.icelink.ConsoleLogProvider(fm.icelink.LogLevel.Info));
// IceLink 2
[FMLog setProvider:[FMNSLogProvider nsLogProviderWithLogLevel:FMLogLevelInfo]];

// IceLink 3
[FMIceLinkLog setProvider:[FMIceLinkNSLogProvider nsLogProviderWithLogLevel:FMIceLinkLogLevelInfo]];
// IceLink 2
FMLog.setProvider(FMNSLogProvider(logLevel: FMLogLevelInfo))

// IceLink 3
FMIceLinkLog.setProvider(FMIceLinkNSLogProvider(logLevel: FMIceLinkLogLevelInfo))
// IceLink 2
fm.log.setProvider(new fm.consoleLogProvider(fm.logLevel.Info));

// IceLink 3
fm.icelink.Log.setProvider(new fm.icelink.ConsoleLogProvider(fm.icelink.LogLevel.Info));


Migration Steps

  • Remove any project reference to FM.IceLink.WebRTC and FM.IceLink.
  • Replace any class from the FM and FM.IceLink.WebRTC namespaces with its equivalent from the FM.IceLink namespace.
  • Delete the library files associated with the FM and FM.IceLink.WebRTC libraries. This includes all DLL files, all JAR files, all lib*.a files and all JS files.

Changing JavaScript Class Names

IceLink 2 uses camelCase for most symbol names, including class names. This is out of step with JavaScript convention, which generally prefers PascalCase for class names. This something that we wanted to correct earlier but it was too disruptive to do in a minor release version. With IceLink 3, this is not a problem. The IceLink 3 JavaScript SDK uses class names written in PascalCase. The code below shows a simple example of this has changed.

// IceLink 2
var candidate = new fm.icelink.candidate();

// IceLink 3
var candidate = new fm.icelink.Candidate();


Migration Steps

  • Replace all camelCase class names with PascalCase.

Using Lambdas in Android and Java

The IceLink 2 API does not have any support for Java 8's functional interfaces. Instead, you must instantiate a delegate type, such as FM.SingleAction. In IceLink 3, the delegate types have been rewritten and the API now supports using lambdas inline for any callbacks or event handlers. Compare the two code samples below, which demonstrate the use of the lambda in version 3.

// IceLink 2
conference.addOnLinkCandidate(new fm.SingleAction<fm.icelink.LinkCandidateArgs>() {
    public void invoke(fm.icelink.LinkCandidateArgs args) {
        sendCandidate();
    }
});

// IceLink 3
connection.addOnLocalCandidate((c, candidate) -> {
    sendCandidate();
});


Migration Steps

  • No migration required, you can adopt the new format at your convenience.

Wrapping Up

With the foreword out of the way, you can start migrating your application. The next section deals with migrating the core features surrounding Starting a Conference.