Closed Bug 1053732 Opened 10 years ago Closed 10 years ago

B2G NFC: Use dictionary in MozNDEFRecord Constructor

Categories

(Firefox OS Graveyard :: NFC, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.2 fixed)

RESOLVED FIXED
2.1 S4 (12sep)
Tracking Status
b2g-v2.2 --- fixed

People

(Reporter: allstars.chh, Assigned: allstars.chh)

References

Details

Attachments

(4 files, 2 obsolete files)

In Bug 960510 we make the type, id and payload parameters optional in MozNDEFRecord Constructor, part of this also because W3C NFC API also make them optional [1]. So we could simply call 'new MozNDEFRecord(tnf)' for the the EMPTY NDEFREcord. However in most cases the 'id' paramter is null, so many developers will do new MozNDEFRecord(tnf, typeArray, undefined, payloadArray) or new MozNDEFREcord(tnf, typeArray, new Uint8Array(0), payloadArray). But the better way is to make it nullable, so we can do new MozNDEFRecord(tnf, typeArray, null, payloadArray); So I am wondering should we make these parameters Optional and Nullable? [Constructor(octet tnf, optional Uint8Array? type, optional Uint8Array? id, optional Uint8Array? payload)] interface MozNDEFRecord Or simply Nullable is enough? [Constructor(octet tnf, Uint8Array? type, Uint8Array? id, Uint8Array? payload)] interface MozNDEFRecord Request feedback from smuag for this, @smaug, can you provide some suggestions for us? Thank you. [1]: http://w3c.github.io/nfc/proposals/common/nfc.html#ndefrecord-interface
Assignee: nobody → allstars.chh
I would put all the optional stuff to a dictionary. dictionary NDEFRecordOptions { optional Uint8Array? type, optional Uint8Array? id, optional Uint8Array? payload } [Constructor(TNF tfn, optional NDEFRecordOptions options)] interface MozNDEFRecord { ... } then one could say: new MozNDEFRecord(some_tnf); or: new MozNDEFRecord(some_tnf, { palyload: some_array}) etc.
Flags: needinfo?(bugs)
Oh, those properties in the dictionary don't need to be nullable, I think, so drop '?'. Properties in the dictionary are optional by default.
(In reply to Olli Pettay [:smaug] from comment #1) > I would put all the optional stuff to a dictionary. > > dictionary NDEFRecordOptions { > optional Uint8Array? type, > optional Uint8Array? id, > optional Uint8Array? payload > } > > [Constructor(TNF tfn, optional NDEFRecordOptions options)] > interface MozNDEFRecord { > ... > } > > then one could say: new MozNDEFRecord(some_tnf); > or: new MozNDEFRecord(some_tnf, { palyload: some_array}) > etc. Thanks smaug, this is even better. I'd work on this proposal. But maybe I will move tnf into the dict as well, and let it have default value. dictionary NDEFRecordOptions { octet tnf = 0; // default to tnf_empty optional Uint8Array type; optional Uint8Array id; optional Uint8Array payload; }; Also I noticed you used 'TNF' in the constructor, I'd check if we should use use enum for 'tnf' and file another bug for this.
Summary: B2G NFC: Make type, id and payload null in MozNDEFRecord Constructor → B2G NFC: Use dictionary in MozNDEFRecord Constructor
Attachment #8475728 - Flags: review?(dlee) → review+
(In reply to Yoshi Huang[:allstars.chh] from comment #3) > Also I noticed you used 'TNF' in the constructor, I'd check if we should use > use enum for 'tnf' and file another bug for this. Filed Bug 1055560
Attachment #8475726 - Flags: review?(bugs) → review+
Comment on attachment 8475727 [details] [diff] [review] Part 2: NfcService update Oh, wait, why we need both MozNDEFRecordOptions and NDEFRecord dictionaries? which both have the same properties, just a bit different types (some nullable) We should be able to have just one, which works in all the needed cases.
Attachment #8475727 - Flags: review?(bugs) → review-
(In reply to Olli Pettay [:smaug] from comment #9) > We should be able to have just one, which works in all the needed cases. Hi Smaug, Yeah, Kyle also asked this when he reviewed it. https://bugzilla.mozilla.org/show_bug.cgi?id=933588#c32 === Quoted from Kyle === ::: dom/system/gonk/NfcOptions.h @@ +8,5 @@ > +#include "mozilla/dom/NfcOptionsBinding.h" > + > +namespace mozilla { > + > +struct NDEFRecordStruct Why can't we just use the generated DOM dictionaries here? Is it because of the JS values? === End of Quote. === However I tried in https://bugzilla.mozilla.org/show_bug.cgi?id=933588#c37 Because the constructor of generated DOM dict is private, to pass it to nsRunnable I have to construct it manually again. Or there's any suggestion to pass it to nsRunnable? Thanks
Kyle is asking in the header file but Smaug is asking on the WebIDL. I'll file another bug for removing NDEFRecord from NfcOptions.webidl.
Attached patch Part 2: NfcService update v2. (obsolete) — Splinter Review
Also updated NfcContentHelper as record.id could be null, and the value in our dict cannot be nullable.
Attachment #8475727 - Attachment is obsolete: true
Comment on attachment 8479695 [details] [diff] [review] Part 2: NfcService update v2. Review of attachment 8479695 [details] [diff] [review]: ----------------------------------------------------------------- Hi, Smaug Sorry for asking wrong question to you before. Now this patch has addressed your Comment 9. Could you help to review this again for me ? Thank you.
Attachment #8479695 - Flags: review?(bugs)
Attachment #8479695 - Flags: review?(bugs) → review+
Comment on attachment 8480419 [details] [review] Gaia Pull Request Gaia PR for updating MozNDEFRecord. @Ben, could you help review Part 1: Browser app change for me? @Francisco, could you help to review Part 2: Contacts app change ? And @Alive, could you help to review Part 3: System app change ? Thank you
Attachment #8480419 - Flags: review?(francisco)
Attachment #8480419 - Flags: review?(bfrancis)
Attachment #8480419 - Flags: review?(alive)
Comment on attachment 8480419 [details] [review] Gaia Pull Request Is this for 2.0? The browser app is being deleted in 2.1.
Attachment #8480419 - Flags: review?(bfrancis) → review+
(In reply to Ben Francis [:benfrancis] from comment #16) > Comment on attachment 8480419 [details] [review] > Gaia Pull Request > > Is this for 2.0? The browser app is being deleted in 2.1. No, not for 2.0. It's should be landed on the master(currently it's 2.1) I don't know when the browser app will be removed, if it's removed when I try to merge this, I'll remove this commit. Thanks
Attachment #8480419 - Flags: review?(alive) → review+
Comment on attachment 8480419 [details] [review] Gaia Pull Request Contact change looking good, thx!
Attachment #8480419 - Flags: review?(francisco) → review+
Add checkin-needed for Gaia commit since I'd like to land Gaia part only when Gecko part lands in m-c. Thanks
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: