Re: common NFC API draft / base for discussion

Here's some feedback based on the latest draft

9. NDEFRecord

The binary representation of a NDEFRecord changes depending on the position
in the message, the length encoding, and chunking. These are details that
are better left to NDEFMessage implementation rather than the NFEFRecord.

I propose the following definition

[Constructor(byte tnf, DOMString type, byte[] payload, DOMString id)]
interface NDEFRecord {
    byte tnf;
    DOMString type;
    byte[] payload;
    DOMString id;
}

TNF is required. Type, payload and id should all be optional.

This NDEFRecord definition will make it easier for people to implement
custom types like the TNF_External Android Application Record (AAR).

8. NDEFMessage

I'd like an NDEFMessage to be constructed with NDEFRecord[] or the byte[]
representation.

Add getBytes() which would be responsible for encoding NDEFRecords.

Android, Windows Phone and BlackBerry all deal with byte[] for reading and
writing NDEFMessages

Android constructs a NdefMessage with bytes[] or NdefRecord[]
http://developer.android.com/reference/android/nfc/NdefMessage.html#NdefMessage(byte[])

Windows Phone write or share tag byte[] with
ProximityDevice.PublishBinaryMessage
http://msdn.microsoft.com/en-us/library/windows/apps/br241212.aspx

BlackBerry Webworks (share byte[])
http://developer.blackberry.com/html5/api/blackberry.invoke.html#.invoke

The BlackBerry NDK has more comprehensive NFC libraries
http://developer.blackberry.com/native/reference/bb10/nfc_libref/topic/manual/nfc_lib_nfc_conceptual_overview.html

6. NFCTag

Consider adding optional meta data info? Tag Size, Tag Type, Technology
Type, Locked State, Lockable
This is not available on all platforms be would be nice to access when
available.

12. NDEFRecordMIME

NDEFRecordMIMEMedia may be a better name

When the caller has a NDEFRecordMIME, the record (and message) will have
been parsed already. Can this return a byte[] instead of a NFCRequest?

1. Introduction

Example 1 - show the tag being passed to the function


Thanks,

Don Coleman

https://github.com/chariotsolutions/phonegap-nfc
https://github.com/don/Ndef



On Mon, Apr 15, 2013 at 1:41 PM, Dave Raggett <dsr@w3.org> wrote:

> Thanks Luc,
>
> I have added a link to the editor's draft from the NFC home page, see:
>
>    http://www.w3.org/2012/nfc/#**roadmap<http://www.w3.org/2012/nfc/#roadmap>
>
> It is interesting that you've avoided exposing the detailed types of tags
> in favour of Text, URI, and MIME record types. That seems like a good idea
> as it steers clear of the variations in how such details are expressed,
> e.g. in Android. We probably need to take a look at the details of the
> Android SDK to see whether the draft API can be implemented on top of it.
>  I will also ask my contacts working on PhoneGap (Apache Cordova) and
> webinos to see what comments they have. Any other platforms, we should be
> checking for the details of their NFC platform?
>
> Best regards,
>
>   Dave
>
>
> On 15/04/13 18:04, Luc Yriarte wrote:
>
>> Hi all,
>>
>>
>> Following is a base for discussing a common NFC API draft:
>>
>> http://htmlpreview.github.io/?**https://github.com/w3c/nfc/**
>> blob/master/proposals/common/**nfc.html<http://htmlpreview.github.io/?https://github.com/w3c/nfc/blob/master/proposals/common/nfc.html>
>>
>>
>> There are a few consequent changes regarding the Intel NFC proposal:
>> - Use of EventTarget / EventHandler and Request interfaces, in alignment
>> with the SysApps working group.
>> - Adding NDEF MIME records, and support of binary payload.
>> - Support for SmartPoster records
>> - Support for bluetooth / wifi handover
>> - Moving the NFCAdapter interface functionalities to the NFCManager
>> interface.
>>
>>
>> As of now, we have insulated the web API from most of the NFC forum
>> spec, so the app developer doesn't have to care about NFC tag type, or
>> decoding a TNF in order to find a record type, and so on. The assumption
>> is that a developer would use the high level API for the common use
>> cases, and fallback on binary records for more exotic uses. This is a
>> design choice, and it is definitely open to discussion.
>>
>>
>> All comments welcome,
>>
>> Luc
>>
>>
>>
>>
>
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/**Raggett<http://www.w3.org/People/Raggett>
>
>