Closed Bug 920882 Opened 7 years ago Closed 6 years ago

[Gaia] Support shrinking UI for NFC sharing function


(Firefox OS Graveyard :: NFC, defect)

Not set


(blocking-b2g:1.3+, firefox28 fixed)

1.3 Sprint 5 - 11/22
blocking-b2g 1.3+
Tracking Status
firefox28 --- fixed


(Reporter: frlee, Assigned: gweng)



(Whiteboard: [FT:RIL])


(6 files, 2 obsolete files)

When users try to share URL/vCards/image/video via NFC tag function, shrinking UI is needed to indicate the sharing process has been started.
Blocks: 894320, 894676, 894678
blocking-b2g: --- → 1.3+
Whiteboard: [FT:RIL, NFCv1.3]
Hi Frances,
Here's the spec for shrinking UI, please refer to attachment.
I also attached an animation for you to reference,
Here's the link:

This looks like something that system platform team needs to help. 
Ivan, could you help to make sure this is in the backlog for system platform team? 

Thank you.
Flags: needinfo?(itsay)
Discussion on the UX draft:
1. If orientation happens in the shrinking UI, we agreed NOT to change the orientation. 
2. Both from sender's device and receiver's device, they will have the shrinking UI. 
3. Receiver will have slide in animation and sender will have swipe out animation. 
4. In the shrinking UI for both receiver and sender, there will have an indicator that indicate users to do the swipe action. 

1. Gaia team suggested to touch to share, not swipe to share.
5. Will have vibration during shrinking UI on both receiver and sender sides. 
6. Once we turn on Bluetooth(no matter it's BT pairing or BT transfer), Bluetooth won't be turned off.
Assignee: nobody → alive
Kevin, per our discussion, this engineering work will be tracked under NFC team to reduce the communication effort. Regarding the engineering resource tracking, Tim will regularly have the sync-up with system platform team members on their workload. I will also check if there is any impact on the tasks of system platform and your team regularly.
Flags: needinfo?(itsay)
See also

We're blocked by this bug and we block the following functional team work(per app).
Whiteboard: [FT:RIL, NFCv1.3] → [FT:RIL, 1.3:p1]
Meeting notes:

Concerning the P2P SENDER device display:

Upon hardware detection of another device, Gecko will fire a system message to system app/nfc_manager so that it can update the UI to indicate another NFC device is nearby.

Depending on User action on that UI, the system app fires a response to the gecko parent, which then relays "onpeerfound" or "onpeerlost" to the application. That event message from gecko to app is fired if, and only if, the application is in the foreground, and has the callbacks defined.

With the callback the application can take action (ie, initiate NFCPeer.sendNDEF(record) to the other device).
Blocks: 929352
Notes from an offline discussion with UX:

* The tilted window should make animation to shrink deeper then bounce back to the normal position.
* If any other activities emerge, like file transferring requests from other already paired Bluetooth devices, or the screen changed due to timeout or user pressed the power button, the whole NFC flow should be seemed as interrupted, and should be terminated immediately. 
* Apps should receive a notification that it should prepare to make a NFC/Bluetooth transferring, to let itself paused if it's necessary. This is especially needed when a user is playing a sone/video/slideshow near the end, because the next second user send it out, the content would change to the main page of the app, and make the sharing stuff become ambiguous.
(In reply to Greg Weng [:snowmantw] from comment #9)
> * Apps should receive a notification that it should prepare to make a
> NFC/Bluetooth transferring, to let itself paused if it's necessary. This is
> especially needed when a user is playing a sone/video/slideshow near the
> end, because the next second user send it out, the content would change to
> the main page of the app, and make the sharing stuff become ambiguous.

Android seems simply bring the app to background(pause/resume).
In this case we could do AppWindow.setVisible(false, true) to put a screenshot overlay.
So our platform can pause an app like that? Because the apps are still need to know the sharing request emerged. For example, if the vide app is playing a video, and the user suddently pair the NFC and start to drag it to send it out, the app at least should know the current video is the sharing target, not the next one changes during the sliding.

Of course it's not a proposal to create a new, special request to notify the app just for UX changing. I think that if the app already needs to know any NFC request in the sharing flow, it can do the pausing thing at the time.
This is irrelevant to NFC but visibility state control.
// In system
  AppWindow.setVisible means mozbrowserAPI:setVisible
// In app
  window.addEventListener('visibilitychange', function () {
    if (document.hidden) {
      // do pause
    } else {
      // do resume
Blocks: NFC-Gaia
Hi, do we have a clear view on the target milestone on this bug now? Thanks.
It seems better to finish this bug before sprint5. If you think it isn't reasonable, please update target milestone.
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Whiteboard: [FT:RIL, 1.3:p1] → [FT:RIL]
Duplicate of this bug: 929352
Assignee: alive → gweng
Attached file WIP patch (obsolete) —
Need to discuss the events from NFC P2P enable to the UI component, and how to check NFC sending is successful or failed. So I only set feed back, not review.
Attachment #8334479 - Flags: feedback?(alive)

window.dispatchEvent(new CustomEvent('nfc-p2pinit')); // If another device is close
window.dispatchEvent(new CustomEvent('nfc-p2pfin'));  // If the device is away
According to today's meeting, I would propose some notifications to notify the ShrinkingUI should be tilted or not, and the user has touched on it and sent it out. So the patch would be modified.
Comment on attachment 8334479 [details] [review]
WIP patch

What is going to be reviewed?
Attachment #8334479 - Flags: feedback?(alive)
Attached file WIP patch (obsolete) —
Add some notifications to control the shrinking UI, and to send notification to notify that user has sent it out.

I don't know whether this should be reviewed or not, because we may have some discussions with people are implementing NFC manager. So I set feedback flag first.
Attachment #8334479 - Attachment is obsolete: true
Attachment #8336020 - Flags: feedback?(alive)
Comment on attachment 8336020 [details] [review]
WIP patch

Find some detailed bug; need to do some adjust.
Attachment #8336020 - Flags: feedback?(alive)
About communication with ShrinkingUI:

ShrinkingUI will listen these events:

  'shrinking-start'        // Start shrinking
  'shrinking-stop'         // Stop shrinking
  'shrinking-receiving'    // Do receiving effects as UX spec

ShrinkingUI will send out this event:

  'shrinking-sent'         // User has tapped on app and dragged it out.
Attached file Patch
Follow the new event way to trigger shrinking effects.

BTW: The Travis dead on irrelevant test: event I remove all my code, it still failed.
Attachment #8336020 - Attachment is obsolete: true
Attachment #8337508 - Flags: review?(alive)
Comment on attachment 8337508 [details] [review]

Some more comments.
Attachment #8337508 - Flags: review?(alive)
Comment on attachment 8337508 [details] [review]

r+ with nits.

I'd like you have an unit test or integration test for this, please file a followup to do.
Attachment #8337508 - Flags: review?(alive) → review+
Attached image NFC_bg.png
Hi Greg,
Here is the background image for shrinking UI! 
Attached image nfc_arrow.png
Arrow updated.
Color: 00aacc
Ok, thanks.
Attached file
@1.5 assets updated.
Comment on attachment 8337508 [details] [review]

Because the screenshot method and some UX design added, Alive may take a look.
Attachment #8337508 - Flags: review+ → review?(alive)
Comment on attachment 8337508 [details] [review]

Attachment #8337508 - Flags: review?(alive) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Update spec due to bug 963010
Tap on Home button should be no function while NFC pairing.
You need to log in before you can comment on or make changes to this bug.