🚨 Breaking Change Notice: Update to ISpeckleConverter Interface in 2.16

News & Updates
1

Dear @Insiders, (who are writing their own converters)

In the upcoming 2.16 release, we are introducing changes to the ISpeckleConverter interface.

Specifically, we’re adding two new bindings:

  • ConvertToNativeDisplayable()
  • CanConvertToNativeDisplayable()

These new methods complement the existing ConvertToNative() and CanConvertToNative() methods.

Definition of Displayable: We define “displayable” as any object with a displayValue. These methods were introduced to align connectors to receive object fallback geometry, mirroring their representation in our viewer.

What This Means for You:

  1. Implementation Requirement: While using these new bindings is not mandatory, creating a class with the ISpeckleConverter interface will require you to stub them out. Not doing so will result in a compilation error.
  2. Behavior Determination: If you decide to leverage these new bindings, the behaviour they implement will be specific to your host application, or you can see the logic of “displayable” described above.

Your IDE will likely flag the missing methods, prompting you to implement them. However, we wanted to give you a heads-up in advance. Here’s how you can stub them out:

/// <inheritdoc />
public object ConvertToNativeDisplayable(Base @object)
{
    throw new NotImplementedException();
}

/// <inheritdoc />
public bool CanConvertToNativeDisplayable(Base @object)
{
    throw new NotImplementedException();
}

Why We’re Introducing These Changes:

Beyond the overarching goal of standardising a fallback behaviour across connectors side-effect benefits that may be relevant for your applications:

  1. Enhanced Object Differentiation: These methods provide Connectors/Converters with the tools to distinguish between primary objects and objects included as properties of other objects (like profiles, analysis results, etc.). This allows receiving host app connectors to use their domain knowledge to decide if these objects should be displayed.
  2. Flexible Geometric Object Treatment: It’s now possible to treat geometric objects as generic display objects rather than first-class BIM content. This offers greater flexibility in how these objects are presented in the host application.

We understand the importance of smooth transitions when changes are introduced. We appreciate your understanding and collaboration as we continue to enhance the Speckle .NET SDK for better functionality and flexibility.

3 Likes