May Product Release x.2.0

WebSync 4.2.0, IceLink 2.2.0, and TheRest 2.2.0 are publicly available. All products have had their examples re-worked to be easier to find/deploy and cover more relevant use cases. MonoDroid and MonoTouch have been renamed to Xamarin.Android and Xamarin.iOS per Xamarin's product name changes. Other major changes include:

• WebSync has new demos - Collaborative Mapping, ExtJS Stock Ticker, Multipage Chat, and Photo Phun.
• WebSync has new examples for native Android and PHP.
• TheRest has a new example for native Android.
• IceLink received a ton of bug fixes and improvements.
• IceLink now has WebRTC libraries for Java, Android, .NET Compact, Xamarin.iOS/Android, Windows Phone 8, and Windows 8 (VP8 newly available on Java).
• IceLink now has server support for all platforms. Any device can become a relay node!
• IceLink has more descriptive error messages, particularly when a connection fails due to Community restrictions.
• IceLink has a vastly improved API for ConnectionHubs - more intuitive, more flexible, and easier to use.

One important item to note is that the API for IceLink ConnectionHubs have changed. Previously, ConnectionHubs were "started" and "stopped" which meant different things depending on the provider. The WebSync provider, for example, subscribed to a channel when the hub was started, and unsubscribed when it was stopped; new clients joining the same channel were linked, and existing clients leaving were unlinked. The problem was that this concept didn't translate well to other session negotiation technologies.

The new ConnectionHub API gets rid of "Start" and "Stop" and replaces it with "Link" and "Unlink". Hubs still abstract away the session negotiation and exchange of offers, answers, and candidates, but don't force the concept of starting and stopping on the provider. The WebSync provider, for example, now allows you to subscribe to a channel in your own code, and call "Link" when a client joins the same channel or "Unlink" when a client leaves the channel. This separates the concept of a link "trigger" from the link establishment process itself - a little more coding on your part, but tons more flexibility. ConnectionHubs simply manage a set of connections. You decide what creates or destroys them.

// OLD WAY (less code, less intuitive, less flexibility)

var client = new Client();
client.Connect();

var hub = new ConnectionHub(client, "/channel");
hub.Start(streamDescriptions)
{
    OnLinkInit = (e) =>
    {
        // peer initializing a new connection
    }
}

// NEW WAY (more code, more intuitive, more flexibility)
var client = new Client();
var hub = new ConnectionHub(client, streamDescriptions)
{
    OnLinkInit = (e) =>
    {
        // peer initializing a new connection
    }
}

client.Connect();
client.Subscribe(new SubscribeArgs("/channel")
{
    OnClientSubscribe = (e) =>
    {
        var peer = e.SubscribedClient;
        client.Link(new PeerClient(peer.Id, peer.BoundRecords));
    },
    OnClientUnsubscribe = (e) =>
    {
        var peer = e.UnsubscribedClient;
        client.Unlink(new PeerClient(peer.Id, peer.BoundRecords));
    }
});

All the examples and documentation have been updated to reflect the new API. Should you have any questions, please feel free, as always, to contact us!

Visit the Downloads page!