840059 - [MMS][User Story] Photo display from message

Status: RESOLVED FIXED

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

Description

[Peter Dolanjski [:pdol]]

UCID: Messages-058

User Story:
As a user, I want to be able to initiate the display of a photo directly from a message (sent or received).

Comment 1

[Borja Salguero [:borjasalguero]]

Is gonna be a standalone implementation or we are going to use 'Gallery' Activity?

Comment 2

[Casey Yee]

I'll take your judgement on this one.   Tapping on a received image should show the images in full-screen.  This will not be the same as gallery since it does not have the same controls for editing, sharing, deleting, etc.

Tap-and-hold a image from within the message will give options to the user to save the image to gallery.

Comment 3

[Borja Salguero [:borjasalguero]]

For all Media types (Video, Image, Audio....) I am concerned about implementing a 'standalone' and not reusable component only for SMS/MMS App, overall because we have a Gallery, Video & Music Apps which should have the same (emails could have images, video, audio... how are we going to handle this?).

Comment 4

[Dietrich Ayala (:dietrich)]

Per partner and release-driver discussions, marking blocking- until all MMS functionality in bug 849867 is complete, allowing it all to be uplifted at once to avoid SMS bustage.

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

leo+ as this is a part of MMS and part of v1.1 to be included in leo+ queries. No_UPLIFT for now before the whole MMS is completed

Comment 6

[Maria Angeles Oteo (:oteo)]

Right now, Ayman is redefining the playback related functionality on MMS Wireframes based on the Browser Downloading ones done by Rob https://www.dropbox.com/s/aolxy3mzrdfvg17/browser-downloading.pdf 
Due to that, we believe they are a good starting point to start the implementation of those capabilities. 

A rough description of the expected behaviour:

When an MMS contains an image file, a visual indication should be shown to indicate the availability of such a content. When the user taps on that visual indication, the proper "view activity" is invoked and since now on everything is tackled by the "handler" activity: 


The image file is opened by the gallery, while the picture is viewed, the user has the option to "save" that content, if the user selects that option, a banner indicating the success/failure of the operation is shown when completed. If the user cancels the "view" operation, he is returned to the thread detail screen in SMS Application. All this code should be implemented by an activity (I suppose in the audio player). 

If the image file has not been properly retrieved, this option will not be offered to end-users. If that is the case, the attachment will indicate there was an error. Clicking on that indication will ask the user for confirmation to try to download the file ("There was an error downloading attachment. Retry Download?").

Comment 7

[Borja Salguero [:borjasalguero]]

As agreed in Madrid assigned to Steve https://wiki.mozilla.org/Gaia/SMS.

Comment 8

[Paul Yang [:pyang] (away)]

test case in moztrap #6763

Comment 9

[Corey Frang [:gnarf]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/9489

Comment 10

[Corey Frang [:gnarf]]

The patch I just submitted gets the image opened in the gallery, now we just need to implement a save button in the gallery open

Comment 11

[Julien Wajsberg [:julienw]]

Comment on attachment 743697 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/9489

r=me, thanks

Comment 12

[Julien Wajsberg [:julienw]]

master: 1ab9bc88799b4af10fef8a810570e23402934bb3

Comment 13

[Corey Frang [:gnarf]]

Still needs "saving" logic put into it to really close up this user story, but we can open the images now.

Comment 14

[Julien Wajsberg [:julienw]]

corey, this will need another patch, please file another bug then :)

Comment 15

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

I was not able to uplift this bug to v1-train.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x -m1 1ab9bc88799b4af10fef8a810570e23402934bb3
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 16

[Julien Wajsberg [:julienw]]

v1-train: 338ac3c77eff850d382344d79cdbcab66bb8857d