1082493 - B2G NFC: How to dispatch the NDEF received from another NFC device?

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: NFC, defect)

Description

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

In this bug I'd raise the question how to dispatch the NDEF received from another device?
Through ontagfound? Or like W3C NFC API add a onmessagereceived on the NFCPeer?
Or simply System message as usual?

Comment 1

[Krzysztof Mioduszewski[:tauzen]]

It looks like W3C is considering to simplify receiving NDEF messages and not pay attention if it was received from NFC peer or read from NFC tag [1]. It seems a bit similar to how we handle it right now via gaia system app NfcManager. 

[1] - http://lists.w3.org/Archives/Public/public-nfc/2014Oct/0002.html

Comment 2

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

I guess the 'event' parameter in onmessage will be very complicated, and it seems one parameter 'eventType' is missing, otherwise not sure how ontag/peerlost will be merged into this callback. And the proposal looks like our nfcd binary protocol, but that's not the API we'd like to deliever to the Web, and neither it has the same design pattern as our other API.

We prefer onFoo DOM callback for some event Foo, not a onmessage with the evt.type is Foo.
We are not doing a Message-based API.

Back to this bug, I'll prefer to add a onndefreceived DOM callback which will be notified when an NDEF is received from a P2P device.

Comment 3

[Krzysztof Mioduszewski[:tauzen]]

As an app developer, if I would like to receive certain NDEF messages regardless of their source I need to:
1. Define activity handler and proper activity filter to receive NDEF message if the app is not started. (handles both tag and P2P)
2. Define ontagfound handler to receive NDEF message read from tag, when the app is in foreground.
3. Define onndefreceived handler to receive NDEF message shared from P2P device, when the app is in foreground.

Is this what you have in mind?

Comment 4

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Krzysztof Mioduszewski[:kmioduszewski][:tauzen] from comment #3)
> As an app developer, if I would like to receive certain NDEF messages
> regardless of their source I need to:
> 1. Define activity handler and proper activity filter to receive NDEF
> message if the app is not started. (handles both tag and P2P)
> 2. Define ontagfound handler to receive NDEF message read from tag, when the
> app is in foreground.
> 3. Define onndefreceived handler to receive NDEF message shared from P2P
> device, when the app is in foreground.
> 
> Is this what you have in mind?

Yes, also onndefreceived should also fallback to System app if the foregound app cannot handle this, just like ontagfound. 
But once thing I haven't discussed yet is should we pass Handover in onndefreceived?
but that could be discussed in a seperate bug.

Comment 5

[Garner Lee]

(In reply to Yoshi Huang[:allstars.chh] from comment #4)
> But once thing I haven't discussed yet is should we pass Handover in
> onndefreceived?
> but that could be discussed in a seperate bug.

Briefly, the system should have a first crack at it in then handover case, as the reverse seems out of order for me for something as important as potentially setting up a data connection to another device.

If the app first handles it, it'll need an API to start the handover (assuming it's safe to do so):

      if (NfcHandoverManager.tryHandover(msg.records, msg.peer)) {
        return;
      }

or merely prevent it by ignoring it.

Comment 6

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Garner Lee from comment #5)
> (In reply to Yoshi Huang[:allstars.chh] from comment #4)
> > But once thing I haven't discussed yet is should we pass Handover in
> > onndefreceived?
> > but that could be discussed in a seperate bug.
> 
> Briefly, the system should have a first crack at it in then handover case,
> as the reverse seems out of order for me for something as important as
> potentially setting up a data connection to another device.
>
NFC won't set up any data connection, it's those Wifi/BT API to actually set up the connection.

So if those Wifi/BT APIs allow privilege apps could establish connections, NFC API should also allow those apps to exchange information.

Comment 7

[Garner Lee]

True. System can stay out of the way mostly. Currently:

bluetooth: {
  app: DENY_ACTION,
  privileged: DENY_ACTION,
  certified: ALLOW_ACTION
},


Making them privileged will potentially create wifi/bt config chaos app level. Two ideas:

1) Tap NDEF handover.
2) Either:
  a) new "manage" web activity that allows the app the ability to bring the normal settings dialog up, prepopulated with "apply" button, or
  b) simple dialog if a BT/Wifi management Promise based API is called:
     "Devices {X, Z} currently detected in use. Allow Wifi/BT requested change? [10 seconds...]"
     .then() use config normally.