FmSessionManager APDU Delegate Method NOT WORKING

[ZackParticipant]

Hello,

First, I think this is linked to a previous problem stated here

I am using the Flomio SDKv2.2 with the Flo BLE Plus with the Basic License for the SDK. I am using the “kReadUUID” option. Once, the UUID is found and the - (void)didFindTagWithUuid:(NSString *)Uuid fromDevice:(NSString *)deviceId withAtr:(NSString *)Atr withError:(NSError *) is fired, I use APDU write commands to write an NDEF record. I am getting a successful response in the logs saying Response apdu: 90 00. I am even getting that the NDEF record was found with the payload correctly formatted. However, the didRespondToApduCommand:(NSString *)response fromDevice:(NSString *)serialNumber withError:(NSError *)error is not firing properly when using the [self.readerManager sendApdu....] method.

Expected Result:
– Set up the NFC reader using kReadUuid
– Touch NFC card to the reader
– Reader detects this and fires -(void)didFindTagWithUuid:(NSString *)Uuid fromDevice:(NSString *)deviceId withAtr:(NSString *)Atr withError:(NSError *)
– Send APDU write command
– Get 90 00 in logs. Fires - (void)didRespondToApduCommand:(NSString *)response fromDevice:(NSString *)serialNumber withError:(NSError *)error
– Parse error/response

Actual Result:
– Set up the NFC reader using kReadUuid
– Touch NFC card to the reader
– Reader detects this and fires -(void)didFindTagWithUuid:(NSString *)Uuid fromDevice:(NSString *)deviceId withAtr:(NSString *)Atr withError:(NSError *)
– Send APDU write command
– Get 90 00 in logs. APDU delegate method does not fire
– Instead, get a - (void)didFindTagWithData:(NSDictionary *)payload fromDevice:(NSString *)deviceId withAtr:(NSString *)Atr withError:(NSError *)error fires saying it found raw data?

I have created a simple project on github that demonstrates the problem in case you want to clone and try it out yourself:
Github Test
NOTE: This write command on the project does write 4 bytes of data on data block 4 of a card

Thank you for the help!!!

• This topic was modified 7 years, 9 months ago by  Zack.

[ScottKeymaster]

Hi Zach,
I understand that the delegate method didRespondToApduCommand is not firing as it should.
We have worked on a solution for this in SDKv2.3 that would allow for NSString *response = [readerManager sendApdu: @"FF XX XX XX XX XX XX XX XX" toDevice: @"1234567"].
We can release a beta version soon to allow for this for your specific use case.

Kind Regards,
Scott

[ZackParticipant]

Hi Scott,

That would be great. All in all I love the reader. Very fast and efficient with battery life. But, I hope that the severity of this issue is pretty high and the release comes soon, as it is very hard to communicate to the user whether it successfully wrote the NDEF without being able to parse the response 🙂

[ScottKeymaster]

Have you tried reading the response using the kReadData state? The UUID is returned in this state, then you would send APDUs and ask the user to tap again to read the data and confirm the write apdus. Not ideal but may be worth the effort.
You can be sure that this is high priority issue but because we have many readers, it takes time to configure them.

Glad you are happy with the performance of the reader.
Kind Regards,
Scott

[ZackParticipant]

Scott,

This solution could work. But like you said, isn’t very ideal. Not to mention that you can’t really tell the user anything until the 2nd swipe. Even if the user removed the card mid write, I presume that the read data delegate would return that it successfully found raw data, and then we would have to parse the ASCII and determine whether this matches with our initial record we were trying to write. Not to mention, I already had created a wrapper class that uses the ReadData delegate for the NDEF reader portion of our application. Honestly I’m perfectly fine with keeping the broken code in the project as we are still in the early development phase. But, do you have a rough timeline as to when this will be released? (P.S. I won’t hold it against you 🙂 )

Thanks!

[ScottKeymaster]

Thank you. Because of all the different types of readers and platforms we support, we are spread quite thin. This will be released within the next month.

Kind Regards,
Scott

[ZackParticipant]

Okay sounds great! Like I said, you all are doing a fantastic job ESPECIALLY with the reader side of things and providing easy to use functions to interact with these devices.

If I don’t hear anything from you mid next month, I’ll bump this post back up and see what the status is!

Thank you for all of the help and I look forward to the new release coming soon.

[ZackParticipant]

Was wondering if I could get an update on this since its been approximately a month.

Thanks!

[RichardKeymaster]

Hi Zack, thanks for following up on this. We still haven’t published Flomio SDK v2.3 which aims at making the sendApdu method a synchronous blocking call but we have implemented some NDEF write functionality in an iOS app recently released. The App is called NFC Actions and available here. Could you check out the NDEF write workflow and functionality in the app to see if it’s something you can use?

If acceptable, then @Scott can guide you through how he implemented it using our SDK so you can achieve the same results in your app.

best,
Richard

[ZackParticipant]

Hey Richard,

Thanks for the response. I just really would like to have something that either would give me feedback from an asynchronous call or something that is synchronous. Kind of hard to update the User Interface if you can’t tell when the asynchronous apdu commands receive a response.

[RichardKeymaster]

I understand. I believe that we accomplish giving “feedback from an asynchronous call” within the NFC Action app write workflow. I’m trying to make sure you agree so that @Scott can lead you down the path of how he made it work. If the implementation still falls short of your expectations then we have to keep pushing for the v2.3 release.

let us know.
Richard

[ScottKeymaster]

Hi Zach,

The didFindTagWithData response is the response when sending APDUs. That is where you receive the error response, if there is no error it was correct. So you could use it to send an APDU, then if there will be a didFindTagWithData response and you can check if there is an error, if not it was successful.

Scott

[ZackParticipant]

Hi all,

Thank you all for the responses.

Scott – this makes sense now, as I was trying to determine why the delegate method was being fired with no data being found. However, how did you all handle this process in the Action app with a dynamic NDEF? Let’s say I am trying to send 80 bytes of data. I believe the Hardware restricts to writing a max of 16 bytes per apdu command. That’ll be 5 write commands. I can check to see if I get an error and update the UI this way. But how do you handle for all successful writes? Do you keep a success counter that increments in the didFindTagWithData?

PS: I’m assuming this is probably why you all are trying to move towards synchronous apdu calls

• This reply was modified 7 years, 8 months ago by  Zack.

[ScottKeymaster]

Hi Zach,

It’s an issue that we are intimately aware of! You can use some sort of thread blocking to wait for a response, Grand Central Dispatch is the most commonly used thread manager with iOS, but you could also use NSCondition

    [_responseCondition lock];
    _result = result;
    _resultReady = YES;
    [_responseCondition signal];
    [_responseCondition unlock];

It’s quite the pain. Your solution would be acceptable too, just count the correct responses, if one is incorrect, try rewrite the whole lot.

Scott

[ZackParticipant]

Okay thanks! I’ll try to see if I can come up with a solution in the meantime until v2.3 comes out. Are you all still looking to release this month?

Also, I’m not sure if you can document this anywhere, but it seems misleading to have a didRespondToApduCommand when the response actually feeds through didFindTagWithData. This is why I thought there was a bug within the SDK, as I expected the APDU response to come from the didRespondToApduCommand delegate method.

Thanks!
Zack

• This reply was modified 7 years, 8 months ago by  Zack.

[Author]

Posts