search

semlette / nfc_in_flutter

Cross-platform flutter plugin for reading and writing NFC tags. Not maintained anymore - not looking for new maintainer, fork instead.
MIT License
120 stars 119 forks source link

remove languageCode in TNF_WELL_KNOWN #21

Closed hasanbasri1993 closed 4 years ago

hasanbasri1993 commented 4 years ago

i suggest to remove this, because it will add a languageCode to payload. i reference to NFC Tool, gototags

semlette commented 4 years ago

Isn't this exactly what the .data field on NDEFRecord does?

hasanbasri1993 commented 4 years ago

just enough add languageCode in payload, no need in data

semlette commented 4 years ago

In my first reply I had misunderstood what you were trying to do.

You can remove the language code by calling NDEFRecord.text with the languageCode argument set to an empty string. nfc_in_flutter versions before 2.0.3 (released today) accidentally ignored the languageCode argument, but it should be working fine now.

I am closing the PR as the functionality can be accomplished using the languageCode argument of NDEFRecord.text.

hasanbasri1993 commented 4 years ago

Please unclose this PR n merge

the languageCode was add in payload in API.dart line 378 So don't need put languageCode again in Data, NfcInFlutterPlugin.java line 491,494

hhhmm,, not good looking

i tried return NDEFRecord.text(record.payloadController.text, languageCode: ""); image

should be like this image

_Originally posted by @hasanbasri1993 in https://github.com/semlette/nfc_in_flutter/pull/21#issuecomment-563303356_

semlette commented 4 years ago

The NDEF specification requires that a well-known text record begins with

The Android code that constructs the NdefMessage is correct, however the Flutter part that constructs the Map the NdefMessage is constructed from, is not. The 2.0.3 release did not fix the issue as you said, however neither will your PR (not completely anyway). The language code is being inserted incorrectly, as it is concatenated with the payload (line 378 of api.dart as you said as well). When NDEFRecord._toMap was called, it didn't set the language code in languageCode, which would cause the Android code to set the language code to en, which wouldn't be the correct language code.

Your PR would have solved the problem, if the languageCode given to NDEFRecord.text is always 2 characters long. However the first byte (the language length byte, I call it the status byte) would be incorrect if the language code is not 2 characters long. Because languageCode was not set in the NDEFRecord._toMap Map, the language code would default to en which would set the status byte to signal the language code will be 2 characters long. If you were then to set the languageCode argument to an empty string or something not 2 characters, it would still signal the language code is 2 characters long. The same problem would also occur on iOS.

I have reverted the changes I made in v2.0.3 and tried to fix them in the languagecode-fix branch. Please see if that fixes the issue.

semlette commented 4 years ago

I have done a lot of tests on the languagecode-fix branch and confirmed that it fixes the issue. I will be merging it to master and it will be in the next release.