-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Async media: Publish/Save while uploading media #5880
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.
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
Conversation
| } | ||
| } | ||
|
|
||
| public static boolean hasPendingMediaUploadsForPost(PostModel postModel) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops meant that! thanks :)
There was a problem hiding this comment.
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).
|
Minor comments left here @aforcier - checking functionality now |
# Conflicts: # WordPress/src/main/java/org/wordpress/android/ui/posts/PostsListFragment.java # WordPress/src/main/res/values/strings.xml
60d765c to
f18488f
Compare
# 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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Conflicts: # WordPress/src/main/java/org/wordpress/android/ui/posts/PostsListFragment.java
|
Ready for another look, @mzorz! |
|
Case A: OK |
Eeek. Doesn't look async related though, I'm able to reproduce this in |
👌 Opened issue #6026 |
Adds support for publishing/saving posts while they have media uploads in progress.
Caveats:
MediaUploadServicewere destroyed while uploading media) - will be handled in a future PRTo test:
A:
B:
Draft, and you'll get a 'Published' notification)C:
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