Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Editing from local serialized Story #445

Closed
13 of 20 tasks
mzorz opened this issue Jul 18, 2020 · 2 comments
Closed
13 of 20 tasks

Editing from local serialized Story #445

mzorz opened this issue Jul 18, 2020 · 2 comments
Labels
[Type] Enhancement An improvement to existing functionality. [Type] Task Something that needs be done, but is not necessarily a feature/bugfix itself.

Comments

@mzorz
Copy link
Contributor

mzorz commented Jul 18, 2020 •
edited
Loading

In order to allow editing, this is how things will work:

Quick summary of convos from this week around how to handle Stories after they’ve been published.

  • After a story has been published it will appear in the blog post list
  • For the initial release story posts won’t be differentiated from other posts in the list
  • Tapping on a story in post list opens the block editor with a static representation of the story block (based on the image block)
  • Tapping the edit icon opens the story editor experience
  • If the story being opened was created on the same device a user will be able to modify and edit objects in the story*
  • If the story was created on a different device we’ll display a message letting the user know that editing functionality for the story is limited.
    *To be determined if this will be included for the initial release or shortly thereafter. Need to determine how much extra effort is required.

Screen Shot 2020-07-18 at 19 46 01

Technical description / flow EDIT: THIS CHANGED! Read below 👇🏻

  • every time a Post is published, we save its serialized Story data and a calculated Post content hash to shared preferences.
  • Also check: maybe the background picture / video for each slide will need to exist as local Media, otherwise we can't let the user edit it. Also, I think the content provider URIs provided by apps like Google Photos are only valid for some time, so if they want to edit again the background image / video will no longer be accessible (they can only by adding them to the app again).
  • when the user taps on a story post list item (how we detect this has as story is for now by inspection) we check if there's a matching serialized story in shared prefs for this Post. If there is such a thing, we inflate the Story and load it on the Story Creator. Only do this if the hash calculated on the Post content results in the same hash, because we can't possibly allow editing on a Post that has been edited.
  • if not, we create a new Story with the background slides being the same as per in the Post, and show the Dialog that says "Limited Story Editing".
  • then again every time they tap UPDATE, the Post gets saved, a hash gets calculated for the Post content and stored along with the serialized Story data.

Also:

  • deleting a Post will need to check whether there's shared pref for this post, and also delete that information.

NEW definitions for technical implementation after conversations with @aforcier, @bjtitus :

We no longer check the Post hash or make any checks prior to opening a Post. We just let them open posts and edit them freely.
We'll be using the flattened produced mediaId as the key to Story slides.

SAVING:

  • when a user saves a Story, we also save to a local (per device) repository the serialized Story slide (frame) and keep the flattened media's mediaID resulting (this is NOT the background image / video mediaId, but the new media resulting from saving in the composer). This ID is the one being kept in the block as well. [key = flattened mediaID -> serialized slide.]
    The repository should be something that is easy to use on each platform. Caveat: remember that mediaIds are also dependent on the siteId.

EDITING:

  • when a user opens a post that contains a story block and taps on the block's tools icon to edit it, we do this:
    -> mobile gutenberg passes the mediaFiles attribute from the block to the host app through the bridge
    -> for each mediaId we go and check with our local repository to see if we have a match for this siteId/mediaId.
    -> if we have a match and the original background media as pointed to by the serialized object is also still available, bingo this is a fully editable slide.
    -> if we don't, we can still present the flattened background image with its mediaId and warn the user with the dialog ("Limited story editing"). We may want to adjust the wording there because it may have been the case the story was actually fully created on this device, but somehow the original background image for a given slide is now not available (for example, with Google Photos temporal Uris?)

ToDo checklist

  • represent the Story block on mobile gutenberg (Implement the actual Gutenberg Story block on WPAndroid #504)
  • * (tied to this one above) show video placeholder (a per what the Video block does) in the case the Story contains only videos (just point to the first slide)
  • build the bridge to determine the icon tool has been tapped
  • now pass the content to the bridge (mediaFiles array)
  • on WPAndroid, resolve how to inflate the serialized slides
  • prior to this, also save the serialized slide that is easily retrievable with siteId-mediaId key representing a unique slide.
  • show saving / uploading states for the Story block in mobile gutenberg (i.e. when you edit in the composer then tap on DONE then mobile gutenberg should be able to represent the story block being processed / saved / uploaded as all of this happens.
  • check edge case: have a story with some errored story frames and then try to edit it in mobile gutenberg. Represent the block with failed / errored and when they tap the icon, set the error properly. This means we need to serialize the SaveResult and save if to prefs as well.
  • if we have a non-editable frame (prefs hasn't been found or the flattened image is not retrievable anymore) -> show warning dialog
  • once the user is done editing, we need to implement a callback on the EditPostActivity and back through the bridge to replace the Story block with the new one the user just created.
  • also we need to connect the FrameSaveService's StorySaveResult in the upload bridge to not create a new Post but only use the existing, modified Post.

Other:

For Later:

These items are being worked on the following PRs:
@mzorz mzorz added [Type] Enhancement An improvement to existing functionality. [Type] Task Something that needs be done, but is not necessarily a feature/bugfix itself. labels Jul 18, 2020
@aforcier
Copy link
Collaborator

Small note here to update the "Limited Story Editing" dialog to say "This story was edited..." instead of "created" so we're also covering messaging for the case where the story was created on the same device, but has been edited elsewhere.

@mzorz mzorz mentioned this issue Sep 2, 2020
Closed
@aforcier aforcier mentioned this issue Oct 7, 2020
Closed
@mzorz mzorz mentioned this issue Oct 14, 2020
Merged
3 tasks
@mzorz mzorz mentioned this issue Oct 21, 2020
Merged
3 tasks
@mzorz mzorz mentioned this issue Dec 24, 2020
Open
3 tasks
@mzorz
Copy link
Contributor Author

mzorz commented Dec 24, 2020

Closing this one as everything is tracked elsewhere as noted in this issue's description

@mzorz mzorz closed this as completed Dec 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Type] Enhancement An improvement to existing functionality. [Type] Task Something that needs be done, but is not necessarily a feature/bugfix itself.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mzorz @aforcier