838027 - [Bluetooth File Transfer][User Story] Support for receiving video files over Bluetooth

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Bluetooth, defect, P1)

Description

[Peter Dolanjski [:pdol]]

UCID: Bluetooth-015

User Story:
As a user, I want to be able to receive video files (using already supported MIME types) from another mobile device or computer using Bluetooth to make it easier to obtain shared content.

Comment 1

[[e-mail], [e-mail]]

https://wiki.mozilla.org/Gaia/System/Bluetooth
Since we don't plan to support video file by Bluetooth in V1, it will not be opened from the notification tray. 

In side of implementation, we don't identify file type to support Bluetooth file transfer.(Bluetooth module should transfer any kinds of file.) When we received a file successfully, it exactly exists in your device. So, I think we could have a patch to open the received video file which is supported by Video app. Maybe we can use Video app's activities "view" or other activities which I need to trace.. I will be happy to provide the patch.

David,
Would you think it's possible to support received video file by Bluetooth? The scenario will be like the preview recorded video in Camera app.

Comment 2

[[e-mail], [e-mail]]

Note: Duplicated with Bug 815864.

Comment 4

[Casey Yee]

Some additional interaction details:

When you have successfully received a video file through Bluetooth you should be able to:
1. Tap on the Bluetooth file receive notification to open the file directly.
2. The Video file should be added to the list of Videos within the Video app.

Comment 5

[Casey Yee]

Proposing another change here.   

Because we will need to support the ability to transfer multiple files at a time.  I recommend that when tapping on the notification of received video files that we take the user to the video app thumbnail view.  

The user should see the newest received files at the top so that they don't have to hunt through the list for the videos that they just received.

Comment 6

[[e-mail], [e-mail]]

For the feature request, I will need David and Dale's suggestion. We'll need to implement an activity 'browse' with type 'video' in the Video app. Then, Video app needs to support sorting received videos by time stamp. We could use media storage to sort them. If David and Dale are not available without any mind, I'm happy to take care the implementation in Video app.(NeedInfo David and Dale)

BTW.

I have to friendly remind that Bluetooth file transferring always processes a file from one device to another device one-by-one. It's a protocol limitation. For our notification, it will show a message for each completely transferring task now. If user tapping on the specific notification of received video, we should browse the specific item with focus. Because it could be other received videos completely dynamically. The videos will be generated in thumbnail view. It could confuse user for viewing which tapping file from notification. 

If we want to combine the notification of Bluetooth transferring files in the future, we'll meet an issue about Music, Video, Photo content type in a combo notification. It could need a simply browser page for Bluetooth transferring files. Because we don't know what files or type are going to be opened.

Thanks.




For the long tern, I thin

Comment 7

[David Flanagan [:djf]]

(In reply to Ian Liu [:ianliu] from comment #1)

> David,
> Would you think it's possible to support received video file by Bluetooth?
> The scenario will be like the preview recorded video in Camera app.

Currently the video app implements a "view" activity to play videos specified by URL. It should be easy (I think) to modify gallery/js/view.js to also support an 'open' activity where the video is specified as a blob.  Or we could just reuse the 'view' activity and change the implementation to accept a blob or a url.


(In reply to Ian Liu [:ianliu] from comment #6)
> For the feature request, I will need David and Dale's suggestion. We'll need
> to implement an activity 'browse' with type 'video' in the Video app. Then,
> Video app needs to support sorting received videos by time stamp. We could
> use media storage to sort them. If David and Dale are not available without
> any mind, I'm happy to take care the implementation in Video app.(NeedInfo
> David and Dale)

The video app sorts videos correctly when its starts. But videos added while running get appended at the end of the list. To fix this, the videoAdded() function must be modified to insert the new thumbnail at the right spot. It looks like the video app does not keep a list of all the videos it knows about, and instead stores the data for each video in closures where it is inaccessible. So you'll need to store the modification date for each video on a data- field or maintain an array of video data.  Not a hard change to make, but not a trivial one, either.

Comment 8

[David Flanagan [:djf]]

(In reply to Casey Yee [:cyee] from comment #5)
> Proposing another change here.   
> 
> Because we will need to support the ability to transfer multiple files at a
> time.  I recommend that when tapping on the notification of received video
> files that we take the user to the video app thumbnail view.  
> 

Casey,

I objected to the same idea for multiple photos because when we receive a file, we know exactly what file has been received and can display it directly. But if we just open the gallery or video app, we have to wait for them to scan for the new file or files.

If we're going to pursue this, then we should modify the 'browse' activity for Gallery (and implement it for Video) so that it optionally accepts a list of names of new files, and processes those files immediately before scanning for others.

This is probably something that I would best be able to implement, so feel free to assign to me if you decide to go this way.

This is non-trivial, but wouldn't be super hard. It would improve the camera-to-gallery transition that we currently have where scanning is necessary.

The alternative (again, as I proposed for photos) is to modify the Gallery and Video open activities so that they can handle multiple files. It would work like the preview mode in the camera.

In this case, since we're talking about launching something from the notification tray, launching the full gallery or video app might make more sense, however, because it is not clear to me how an inline activity should work here... What does the back button do, for example?

Ian: after a notification has been issued, can the app that created it remove it or modify it?  It seems to me that if a video is received, the system issues a "video received" notification. Then, if the user has not clicked on it, and another video is received, the system would remove the notification and issue a new one that says "2 videos received". It could maintain a separate count for photos, videos and audio files.  Could that work?

Comment 9

[[e-mail], [e-mail]]

(In reply to David Flanagan [:djf] from comment #8)
> (In reply to Casey Yee [:cyee] from comment #5)
> > Proposing another change here.   
> > 
> > Because we will need to support the ability to transfer multiple files at a
> > time.  I recommend that when tapping on the notification of received video
> > files that we take the user to the video app thumbnail view.  
> > 
> 
> Ian: after a notification has been issued, can the app that created it
> remove it or modify it?  It seems to me that if a video is received, the
> system issues a "video received" notification. Then, if the user has not
> clicked on it, and another video is received, the system would remove the
> notification and issue a new one that says "2 videos received". It could
> maintain a separate count for photos, videos and audio files.  Could that
> work?

It's a good question and relative with 'NotificationHelper' module. There is no way to modify or remove created notification from APP side. If we want the feature about update/modify notification, we should fire another issue for this section. It will need many UX input to build the feature. Josh may know more information for notification spec.

Even if we could modify the created notification, I think we should think about how to manage the multiple received files first. What's the criteria for management notification? (Group of Music, Video, and Photo?) In fact, Bluetooth module can send and receive any type of files. If we have some criteria to manage multiple type of received file, it won't be able to take care of all use case. I still think that maybe having a simple transferred list in a page for the long tern. User could feel more clear and click each item to open the specific file. Looks like another issue for supporting multiple file in the future.

We still need Casey to make the behavior more clearly in the leo+ stage.

Comment 10

[Peter Dolanjski [:pdol]]

Adding Casey for input on UX given the points above.

Comment 11

[Casey Yee]

OK Guys, thanks for the detailed explanations here.  I agree with many of the points here and because of the level of effort from a UX and Dev standpoint, I'm encouraged to keep this one as simple as possible and revisit at a later stage.

Let's go with just having separate received file entries in the notifications tray.  This will avoid any complexities with revoking/changing notification entries and any of the logic needed to support that as per Ian.

We'll also keep with opening the images directly into full-screen view in the gallery app from the notification rather than gallery grid view as per Davids suggestion.

Comment 12

[Casey Yee]

Also, just realizing that this bug is regarding the video app not gallery.  Doesn't really change anything as the behavior should be consistent in both of these apps.

Comment 13

[[e-mail], [e-mail]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

Pointer to Github pull-request

Comment 14

[[e-mail], [e-mail]]

Comment on attachment 722177 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

* Support sorting videos by date in Video App.
* Support 'browse' activity with type 'videos' in Video App.
* Support checking video files type which are received by bluetooth to request 'browse' activity.

Both David and Dale can be the reviewer.
Could you please help to review my pr?
Thanks.

Comment 15

[[e-mail], [e-mail]]

(In reply to Ian Liu [:ianliu] from comment #14)
> Comment on attachment 722177 [details]
> Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517
> 
> * Support sorting videos by date in Video App.
> * Support 'browse' activity with type 'videos' in Video App.
> * Support checking video files type which are received by bluetooth to
> request 'browse' activity.
> 
> Both David and Dale can be the reviewer.
> Could you please help to review my pr?
> Thanks.

Implement the feature according Comment 4 and Comment 5.

Comment 16

[David Flanagan [:djf]]

(In reply to Ian Liu [:ianliu] from comment #15)
> 
> Implement the feature according Comment 4 and Comment 5.

Hmm. Too bad that Casey's comment 11 didn't come sooner!  I'll review it as is, but I suspect we're going to want to use the open or view activity instead of this new browse activity.

Comment 17

[David Flanagan [:djf]]

Comment on attachment 722177 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

r- because of a number of small issues on github.

I would prefer to see this feature implemented with the open activity, but it wouldn't hurt to have the browse activity too.  And if time is short, we could implement it with browse.

I think an open activity should launch view.html just like the view activity does. I think there would be only minor changes necessary in view.js to make the code work the blob from the open activity.

I like the changes to the video app to insert new videos in the proper position in the list, and I think it is worth landing those even if we get rid of the browse activity. Perhaps they can be broken out into a different bug?

Note that Alive's work for bug 842898 will probably cause merge conflicts with this bug, so you and he may want to coordinate your landings.

Comment 18

[Dominic Kuo [:dkuo]]

Bug 838655 is for video app to support "open" activity to play video blobs.

I think in comment 12 Casey was trying to say the final ux should be just play the received videos after users tap on the notifications, right?

If so, video app will be ready after bug 838655 is fixed, which I have sent a patch already.

Casey, would you please commnet again to clarify our confusion? thanks.

Comment 19

[[e-mail], [e-mail]]

David,

Thanks for your reviewing effort. I refine most of these issues according your suggestion. I still have some question about identify video or audio of mp4 format. Since we need Casey to clarify our confusion, I'll refine the pr again according his confirmation. We could WIP on Github.

Comment 20

[Casey Yee]

Dominic, you are correct.  I recommend for this version we keep things simple and directly open the video from the notification.

Comment 21

[Dominic Kuo [:dkuo]]

(In reply to Casey Yee [:cyee] from comment #20)
> Dominic, you are correct.  I recommend for this version we keep things
> simple and directly open the video from the notification.

Cool, and bug 838655 is fixed so the open activity of video app is ready in gaia master.
I think we are pretty close to finish this issue and let's wait for Ian's patch.

Comment 22

[[e-mail], [e-mail]]

Comment on attachment 722177 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

Since bug 838655 is fixed, I have refined my pr to use 'open' activity according Comment 20. Let's ignore 'browse' activity.

Comment 23

[[e-mail], [e-mail]]

Comment on attachment 722177 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

I want to refine a function. Set r-..

Comment 24

[[e-mail], [e-mail]]

Comment on attachment 722177 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

I separate "sorting video file by date" to Bug 850574. Let's deal with opening video file by Bluetooth file transfer in the issue only.

Evelyn,
Could you please help to review my pr?

Comment 25

[Evelyn Hung]

Comment on attachment 722177 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8517

r=me, what this patch does is simply open received file according to its mime type. For browsing video issue, let's move our discussion to another bug if Casey think it's a must-have feature.

Ian, please label/comment 3gp format broken issue you found as a dependency, so QA can track the status after this patch landing. Thanks!

Comment 26

[[e-mail], [e-mail]]

Thanks for David and Evelyn's reviewing effort.
We can merge the pr to close the issue.
https://github.com/mozilla-b2g/gaia/pull/8517

Since the feature landed, QA team will try to verify the issue. Because there is a blocking issue (Bug 850542 - Video tag does not accept 3gp files which are passed via web activity), QA cannot verify the issue via FFOS phone in sending side. 

It depends on recording video in 3gp format via Camera app. And we are able to share recording video via Gallery app only.(Please reference the repro steps in Bug 850542.)

If you want to experience the feature, please share other format instead of 3gp.
I have done some test for *.mp4 format. It works normally.


Note for sending video files via Video app.
Bug 838028 - [Video][User Story] Support for sending video files over Bluetooth

Comment 27

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted commit 7ae6f639c00da38257f1f80e03586961750d902f as:
v1-train: f6666d130bba2a15b6ccc21cb1f74242805afc5d

Comment 28

[Jason Smith [:jsmith]]

I believe John was working on getting test cases for this, right?

Comment 30

[Walter Chen[:ypwalter][:wachen]]

verified fixed in pvt pub v1train 2013/04/17 build unagi

Comment 31

[Stephany Wilkes]

Need to make sure what was implemented is in line with existing UX...

Please see this pattern here (receiving is on page 6):
https://www.dropbox.com/s/fo28slp3juqyoux/Bluetooth-Sharing_v3.pdf

This one contains the patterns for transfers in the utility tray, which is applicable to Bluetooth. 
https://www.dropbox.com/s/6y3urw3g2x7levx/Transfer-Progress.pdf

This covers previewing and saving incoming transfers:
https://www.dropbox.com/s/vbxes8onsv58ir7/meta-pattern-previews.pdf

It would be great if all of you who are in Madrid could get together and review what's been implemented here against these patterns and specs. I'll flag Casey to get it going. 

Thanks all!