Wednesday, June 21, 2017

Meet Our Customers: goFLUENT

"Lightstreamer technology is a vital part of our products and has enabled us to offer top-notch services." - A short interview with Edward Watson, Digital Marketing Manager/Specialist at goFLUENT, a leading eLearning company, which leveraged Lightstreamer for their Virtual Classroom solution.

Lightstreamer enabled the creation of a reliable and secure real-time chat/messaging system, working seamlessly behind proxies and firewalls on both the web and mobile apps.

Friday, February 10, 2017

What's New With Lightstreamer 6.1

We are very excited to announce general availability of Lightstreamer Server 6.1, which includes many new features and improvements.

Lightstreamer now speaks a brand new protocol, called TLCP. The Android and Java SE client libraries use the new protocol and natively support WebSockets. The iOS client library has become more Swift-friendly. A new client library is available for Microsoft .NET PCL, replacing older .NET, Windows Phone, and WinRT libs. In addition, several fixes and optimizations have been added to most components.

It's super easy to check out Lightstreamer 6.1. You can either download the installation package, or run the official Docker image, or launch the official AWS AMI.

Tuesday, January 31, 2017

One More Step Towards Swift Developers

The Swift language is designed to be as interoperable as possible with Objective-C. This goal is generally fulfilled, but an area still remains where the two languages don't interoperate as well as one would expect: exception handling.

Objective-C provides complete try-catch-finally semantics for exception handling, with full stack unwinding. While Cocoa and CocoaTouch conventions discourage their use for runtime errors (originally for performance reasons), they are of common use also in Apple's frameworks for programmer errors (i.e. logic errors, such as accessing an out-of-bounds element of an NSArray).

Swift, on the other hand, provides similar do-try-catch semantics, but its errors (do not call them exceptions) are actually passed back as an out parameter and does not provide a stack unwinding mechanism. Moreover, as of Swift 3.x, Objective-C exceptions are left completely out of Swift error handling: they are uncatchable in this language, and cause a direct crash of the application or the service. For the rationale behind this choice, and its corresponding discussion, see this dissertation on the Swift GitHub repository.