Skip to content

Conversation

@aforcier
Copy link
Contributor

@aforcier aforcier commented May 11, 2017

Adds support for publishing/saving posts while they have media uploads in progress.

Caveats:

  1. Doesn't handle cancelled images (this could only happen if the MediaUploadService were destroyed while uploading media) - will be handled in a future PR
  2. There's no messaging of what's going on (other than the 'Uploading...' state of the post card in the list) until the post upload completes and we see a notification. The upload UI is getting an overhaul as part of the async experience (in future PRs). In the meantime, I'll open a separate PR adding plain notifications for async uploads for demonstration purposes.
  3. This breaks reattachment, in the sense that you can't re-open a post once you've exited the editor, until it finishes uploading

To test:

A:

  1. Create or edit a post, and add media
  2. While media are uploading, press Publish (or Update)
  3. The post should be in 'Uploading' state in the post list
  4. Wait for the post to finish uploading (the state will update, and you'll get a 'Published' notification)
  5. Open the post, and confirm that all media are uploaded and not local

B:

  1. Create or edit a post, and add media
  2. While media are uploading, exit the Editor
  3. The post should be in 'Uploading' state in the post list
  4. Wait for the post to finish uploading (the state will update to Draft, and you'll get a 'Published' notification)
  5. Open the post, and confirm that all media are uploaded and not local

C:

  1. Repeat A and B, but induce an error in the image upload
  2. The post should be saved as a local draft
  3. Opening the post should have the failed media in 'failed' status

Also check that uploading/closing the editor with already failed media behaves the same as before, and that non-media uploads work correctly.

cc @mzorz and @daniloercoli

}
}

public static boolean hasPendingMediaUploadsForPost(PostModel postModel) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we pass the postID here instead of the Model? given that's the only thing being accessed within this method after all

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should - a style rule of using FluxC is to always use models wherever possible. This avoids ambiguities we used to have where you get passed an id that could represent either a local id or a remote id.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 for now ;)

*/
@SuppressWarnings("unused")
public void onEventMainThread(PostEvents.PostUploadCanceled event) {
if (isAdded() && mSite.getId() == event.localSiteId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand mSite shouldn't be null, but reading the onCreate sequence it seems this class is registered for FLuxC event listening before the mSite property is initialized in updateSiteOrFinishActivity(). While that might deserve further analysis, I'd say at least for the sake of this PR we check mSite is different than null here to avoid a NPE.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with the null check - note though that this isn't a FluxC callback - it's the old WordPress-internal event bus we still use for some internal actions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops meant that! thanks :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in f18488f (I also made updateSiteOrFinishActivity() get called first, which should prevent any events being handled before we've finished setting up mSite).

@mzorz
Copy link
Contributor

mzorz commented May 11, 2017

Minor comments left here @aforcier - checking functionality now

aforcier added 2 commits May 24, 2017 12:41
# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/ui/posts/PostsListFragment.java
#	WordPress/src/main/res/values/strings.xml
@aforcier aforcier force-pushed the feature/async-media-plus-publish branch from 60d765c to f18488f Compare May 24, 2017 17:30
aforcier added 2 commits May 26, 2017 18:48
# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/ui/media/services/MediaUploadService.java

if (event.canceled) {
// TODO: If a media upload for a post was cancelled, we might want to cancel the post upload, too
// Not implemented
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we cancel the post upload here then? If this event only means the user triggered the cancel action, then I think we're safe to cancel the post upload as well

Copy link
Contributor Author

@aforcier aforcier Jun 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I added a TODO was so we could think out this use case a bit more - currently there's no way for this to be called (can't cancel a media upload outside the editor, and re-opening a post with uploading media will cancel the post upload, so cancelling at that point will also not call this).

But I think it makes sense to just add the behavior with some logging so we can tell this is happening if we're confused about something in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 3d25a37 and 962627f.

@aforcier
Copy link
Contributor Author

aforcier commented Jun 5, 2017

Ready for another look, @mzorz!

@mzorz
Copy link
Contributor

mzorz commented Jun 6, 2017

Case A: OK
Case B: OK
Case C (B): turning airplane mode ON after exiting the Editor leaves the post list with the new post with the spinning wheel forever, see video here https://cloudup.com/ct3G73l8-Hd

@aforcier
Copy link
Contributor Author

aforcier commented Jun 6, 2017

Turning airplane mode ON after exiting the Editor leaves the post list with the new post with the spinning wheel forever, see video here https://cloudup.com/ct3G73l8-Hd

Eeek. Doesn't look async related though, I'm able to reproduce this in develop - shall we open a new issue (if you confirm it's the same bug in develop)?

@mzorz
Copy link
Contributor

mzorz commented Jun 8, 2017

Eeek. Doesn't look async related though, I'm able to reproduce this in develop - shall we open a new issue (if you confirm it's the same bug in develop)?

👌 Opened issue #6026

@mzorz mzorz merged commit f149062 into feature/async-media Jun 8, 2017
@aforcier aforcier deleted the feature/async-media-plus-publish branch June 8, 2017 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants