Iso7816Chaining class

ISO 7816-4 response chaining, wrapped around a transceive function you already have.

Neither CoreNFC nor android.nfc.tech.IsoDep follows a chain for you. A card that answers 61xx is saying "here is the first frame, ask again for the rest", and a caller that does not know to loop keeps the first frame and the status word and never learns that the answer was cut in half. 6Cxx is the mirror image: the card rejected the Le it was sent, named the length it wants, and ran nothing at all. Every serious reader ends up writing the same two loops, so they are written once here.

This is opt-in on purpose, and it is deliberately not wired into transceive or Iso7816.sendCommand. Protocols layered on top of ISO 7816 run continuations of their own: Mifare DESFire signals "more frames" with its own AF status and expects the reader to answer AF, and secure messaging wraps and unwraps each command and response as a unit. A transport that silently issued GET RESPONSE underneath either of them would splice bytes into the middle of a frame the layer above is still assembling, and corrupt an exchange that was working. Chaining belongs where the caller knows the card is speaking plain ISO 7816-4, which is here.

It takes a function rather than a tag, so it works against both platforms without knowing either exists. iOS hands over a parsed response already:

final chain = Iso7816Chaining(ios.Iso7816.from(tag)!.sendCommandRaw);

Android hands over raw bytes with the status word still on the end, which Iso7816ResponseApdu.fromBytes splits:

final isoDep = android.IsoDep.from(tag)!;
final chain = Iso7816Chaining((command) async => Iso7816ResponseApdu.fromBytes(await isoDep.transceive(command)));
final response = await chain.sendCommand(selectApdu);

Constructors

Properties

Methods

Operators

apdu library