- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Oct 2020 13:27:12 +0000
- To: public-web-nfc@w3.org
OK, now we have `navigator.nfc` that contains `ndef` of type `NDEFReader` (exposing scan(), write(), onreading, onreadingerror). I will make a branch from here to explore option 2 from #602 [comment](https://github.com/w3c/web-nfc/issues/602#issuecomment-707945243). That is, `navigator.nfc` would contain `ontagfound`, `onerror`, and `ndef` of type `NDEFReader` that contains `read()` and `write()`. Scanning (NFC polling) is separated from reads, `ignoreRead` is not needed any more since there is no automatic content read from tags, and internal slots for pending read and write are not needed, either. Reading and dispatching algorithms become much simpler. Also, this would be closer to the Android NFC API usage flow, and more future proof. This would permit later improvements, such as the `ontagfound` event could contain NFC technologies supported, but since that is restricted to NDEF at the moment, we can use a simple event. However, we could use flags already available from Android, such as `writeable`, `formattable` etc. Future NFC tech could get their API namespace under `navigator.nfc`, for instance `navigator.nfc.isodep` exposing `transceive()` etc. The same `navigator.nfc.ontagfound` could be used (with expanded content, so backwards compatible). Also, a `navigator.nfc.ontagreleased` event could be added later, if a developer need arises (it's quite common in other APIs, but will only add here when there are clear use cases for it). The minimal delta from this point that supports the current functionality would be quite small, but let's see how -- GitHub Notification of comment by zolkis Please view or discuss this issue at https://github.com/w3c/web-nfc/pull/601#issuecomment-708401074 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 October 2020 13:27:14 UTC