Breaking change in 6.10.0 kotlin access to Embrace.getInstance().deviceId

[jt-gilkeson]

In 6.9.2 and prior in kotlin you could call:
Embrace.getInstance().deviceId

In 6.10.0 it says it can't find that declaration and wants you to call the old school getDeviceId() ?

Didn't see this in the release notes, was it intentional?

[bidetofevil]

Hi @jt-gilkeson - thanks for the report! I'll take a look. We did some cleanup and hadn't noticed this changing on our end, likely because getDeviceId(() is the intended API which is still based in Java.

I'll have a look at other cases and update the release notes based on this.

[bidetofevil]

So it looks like the underlying implementation that backs the getDeviceId() method in the interface was a regular function rather an a property that has a getter implementation, while all the other properties exposed like currentSessionId was reimplemented as the latter. That left deviceId as the outlier.

How it is exposed via the Embrace object in Kotlin likely changed when we moved Kotlin versions to 1.8.x.

I'll add that to the release notes and remedy this in the code to make it consistent with all the other getter functions on the interface.

[bidetofevil]

BTW, lastRunState has the same issue. I will also note this

[bidetofevil]

Hi @jt-gilkeson - I've updated the release notes to reflect this. We may restore the previous behaviour in 6.11 to preserve the consistency of the API, but this and other synthetic properties will not be exposed as such in the next major version, at least not as an immutable property. The deviceId can change depending if the SDK is enabled, so we'll either make this mutable or leave it only accessible as a method.

[bidetofevil]

One more addendum - I can confirm that we will restore access through the synthetic property for both of these in our next release. We will reevaluate these going forward, but they will be semantically correct in the next major version

[bidetofevil]

FYI, this fix was released as part of 6.11.0