2.28.0 and Later¶

Locking/Unlocking API changes¶

The behavior of DefaultTriggerLockCommand has changed. It used to let the locking device choose, which trigger lock action to take, but now always executes the lock's default action. The former behavior is available through the new AutoTriggerLockCommand and AutoTriggerLockCommandBuilder, which behave equally to the old and new version of DefaultTriggerLockCommand when used with locking devices implementing protocol version 0x3E or earlier. However, when used with newer locking devices, the AutoTriggerLockCommand lets the lock choose which action to take while the DefaultTriggerLockCommand requests the lock to execute its default action type.

In order to properly deal with differences between different versions of locking devices, the use of the new CompatTriggerLockCommandBuilder is encouraged instead of using AutoTriggerLockCommand or DefaultTriggerLockCommand.

The following table outlines the differences between the three:

Where no custom properties need to be passed, it's encouraged to use CommandExecutionFacade.triggerLockAsync() instead of CommandExecutionFacade.executeStandardCommandAsync().

Migration¶

Search your code for DefaultTriggerLockCommandBuilder and replace it with CompatTriggerLockCommandBuilder. If no special features of CompatTriggerLockCommandBuilder are used, consider using CommandExecutionFacade.triggerLockAsync instead of CommandExecutionFacade.executeStandardCommandAsync().

return bleLockCommunicator.executeCommandAsync(
    bluetoothAddress,
    physicalLockId,
    tlcpConnection -> {

        // MIGRATION START
        // Replace:
        //
        // TriggerLockCommand triggerLockCommand = new DefaultTriggerLockCommandBuilder()
        //     .build();
        //
        // return commandExecutionFacade.executeStandardCommandAsync(
        //         tlcpConnection,
        //         triggerLockCommand,
        //         ct);
        //
        // with:

        return commandExecutionFacade.triggerLockAsync(
                tlcpConnection,
                ct);

        // MIGRATION END

    }, ct)

Simplified KeyManager¶

The interface of the KeyManager was simplified. The asynchronous method KeyManager#queryLocalKeysAsync(String, CancellationToken) was replaced with a synchronous method KeyManager#getLocalKeys(String).

Migration¶

Replace KeyManager#queryLocalKeysAsync(String, CancellationToken) with KeyManager#getLocalKeys(String).

// Replace:
//keyManager.queryLocalKeysAsync(userId, cancellationToken)
//    .continueOnUI( (List<KeyDetails> keys) -> {
//        // display data
//        ....
//        return null;
//    })
// with:

List<KeyDetails> keys = keyManager.getLocalKeys(userId);

Streamlined representation of lock ID¶

Except for BleLock, everywhere the Base64-encoded representation of the TLCP lock ID is used. For consistency reasons, the Base64-encoded TLCP lock ID was added to the BleLock as well and the Byte representation was marked as deprecated. APIs accepting the Byte representation were marked as deprecated in favor of the Base64-encoded lock id, as well.

Migration¶

Replace the usage of BleLock#getLockId() with BleLock.getPhysicalLockId()

// Replace:
// byte[] lockId = bleLock.getLockId();
// bool isNearby = bleLockScanner.isLockNearby(lockId)
// bool isNearb = bleLockScanner.isLockNearby(lockId, rssi)
// BleLock lock = bleLockScanner.getLock(lockId)
// List<Lock> locks = bleLockScanner.getLocks(lockId)
// bleLockCommunicator.executeCommandAsync(bleAddress, Base64.encodeToString(lockId), tlcpConnection -> commandExecutionFacade.triggerLockAsync(tlcpConnection, ct), ct)

String lockId = bleLock.getPhysicalLockId();
bool isNearby = bleLockScanner.isLockNearby(lockId)
bool isNearb = bleLockScanner.isLockNearby(lockId, rssi)
BleLock lock = bleLockScanner.getLock(lockId)
List<Lock> locks = bleLockScanner.getLocks(lockId)
bleLockCommunicator.executeCommandAsync(bleAddress, lockId, tlcpConnection -> commandExecutionFacade.triggerLockAsync(tlcpConnection, ct), ct)