-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Async media: Notifications for async publish #5881
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
Async media: Notifications for async publish #5881
Conversation
397039b to
46fca06
Compare
|
Good job @aforcier! Generally speaking the code looks good, I only found these things that might be improved:
|
…dia-temporary-notifications # Conflicts: # WordPress/src/main/java/org/wordpress/android/ui/posts/services/PostUploadService.java
As discussed we should deal with this in a separate PR (and after we know the rest of the design requirements for notifications). For context, this isn't completely straightforward since the in-progress notification and the 'post uploaded' notification are very different. The in-progress notification is an ongoing notification pinning the service to the foreground to prevent the system from killing the service. Once the upload completes we don't need to pin the service to the foreground anymore (and it should be stopped if there's nothing left to upload), so that one is just a normal notification. We should rework this so the 'uploaded' notification is dismissed if we're uploading the same post again (but, as mentioned, at a later point). |
So there are a few things going on here, I'll separate them out.
Changing the status from Draft to Publish makes this a 'published' post, and as you say since we didn't actually hit UPDATE, uploading the post automatically when exiting the editor would publish a draft, which is probably not what the user intended (or if it is we probably should not assume it). So it's correct not to queue up a post upload, and instead just save locally and update the post model in the db (from the
I may have missed your meaning here - isn't this expected behavior? At least for Aztec, where we have reattachment. For the visual editor, we'll take care of this when we disable opening any post that has uploading media in general.
We're currently only showing progress notifications if the post is supposed to be uploading - if we're just updating the post locally, and the media uploads are proceeding (and you can re-open the post right away and see them still uploading), I'm not sure any messaging is needed in this case. We'll bring this up in the i2 design discussion with @bysl though. |
|
PR updated with changes to the base branch (had to make some changes to accommodate notification error messaging for media cancellation). |
Agh you're right! my bad - sorry |
|
Thanks for the important notes and clarifications here @aforcier ! Will re-test and get back with comments if I should make any 👍 |
|
🔥 |
Adds some notification support for async post publishing (#5880). #5880 should be merged first, and then the base branch of this PR updated.
This is intended to be temporary, to give us some visual feedback on what's happening (post waiting for media to finish --> post itself publishing), and also to show an error notification when a post upload is cancelled because it had failed media. It's temporary because the upload UI is getting a major overhaul as part of the async media project, and that will supersede these changes.
To test:
Run the same cases as in #5880. You should get an immediate notification when pressing 'Publish', and you should get an error notification if a media item fails while the post is queued to upload.
cc @mzorz @daniloercoli