There is no way to clear scheduled card selection scenario

[amessara-billettiqueservices]

Hello team,

We have a case where card selection scenario is dynamically configurable and can be cancelled. There is currently no API to do that (other than recreating the reader)

This can even end up in an exception if you are using a shared remote reader. If the first user registers a scenario and the second one doesn't do a "clear". The response received can't be handle by the seconde selection manager

07-10 15:28:47.182  3389  3389 D SmartcardNfcReader: New CardCardReader received type : CARD_MATCHED readerName : BluebirdReader
07-10 15:28:47.183  3389  3389 I System.out: java.lang.IllegalArgumentException: Argument [cardSelectionResponses] has a value [3] greater than [0].
07-10 15:28:47.199  3389  3389 I System.out: 	at org.eclipse.keyple.core.util.Assert.isInRange(Assert.java:205)
07-10 15:28:47.199  3389  3389 I System.out: 	at org.eclipse.keyple.core.service.CardSelectionManagerAdapter.processCardSelectionResponses(CardSelectionManagerAdapter.java:365)

Thank you for your help.

[andrei-cristea]

Hi Aghilas,

If I understand your use case correctly, you have a single observer attached to an ObservableCardReader. You initially created a CardSelectionManager and scheduled it on the reader. Later, you dynamically created a second CardSelectionManager and scheduled it on the same reader.

As a result, the second selection scenario replaced the first one. However, when the observer received the card response, it still delegated the parsing to the original CardSelectionManager, which had no selection cases configured, whereas the one that was actually executed contained three selection cases.

If this is an accurate description of your scenario, then the recommended approach is to:

1. Stop card detection.
2. Create and schedule the new selection scenario on the reader.
3. Update the observer so that it references the new CardSelectionManager instance.
4. Restart card detection.

Updating the selection scenario while card detection is already running is not supported. This is primarily because CardSelectionManager is intentionally not thread-safe, and allowing it to be modified concurrently could lead to inconsistent behavior.

Does this solution address your issue?

[amessara-billettiqueservices]

Hello Andrei,

Thank you for the quick reply as always.

Our specific use case is different. Simply put, we schedule a card selection on the reader within our application. However, if the application flow moves on to a different state, we need to cancel this scheduled selection so that the reader does not automatically trigger it.

At the moment, it seems there is no API available to achieve this cancellation gracefully, other than completely unregistering the reader and recreating a new instance (which we would like to avoid).

Thank you for your help.

[andrei-cristea]

If I understand correctly, you'd like to be able to cancel the triggering of a scenario during your application's lifecycle.

Among the different options we have considered, our preferred approach is to add a clearScheduledCardSelectionScenario() method to ObservableCardReader.

Regardless of the solution we choose, this change will impact the Reader Server-Side mode of the Keyple Distributed solution. As a result, the server will need to be updated before the client to ensure compatibility.

How urgent is this requirement for you? We're currently working on the next major release of the Terminal APIs, which is planned for this fall. Would it be acceptable for this fix to be included in that release, or do you need it sooner?

In the meantime, as a workaround, you could effectively cancel the current selection scenario by scheduling a new scenario containing a single selection case with no filters and configured in ALWAYS mode.

This dummy scenario would replace the previous one until the new API is available.