Skip to content

Conversation

@shiki
Copy link
Contributor

@shiki shiki commented May 1, 2019

Closes #9568.

This adds auto-upload of Local Drafts when any one of these happens.

Scenario Before After
Swipe to refresh swipe to refresh before gifcask 2019-05-01 14_22_45 swipe-to-rrefresh-after
Connection is restored connection restored before gifcask 2019-05-01 14_24_51 connection restored after
Post List is opened post list open before gifcask 2019-05-01 14_23_43 post list open after

The auto-upload never happens if the Post List is not open. I think this is one of those things that we will need to have an architectural and design discussion about soon.

Not Covered Yet

For this PR, I wanted to focus on the process flow and architecture so I intentionally did not include these.

I have updated the description of #9568 to list those that have not been covered yet.

FluxC PR

There is a companion FluxC PR for this: wordpress-mobile/WordPress-FluxC-Android#1243.

Testing

  1. Create a draft post while offline.
  2. Leave the Editor before going back online. Do not Publish the post.
  3. Try the scenarios described above.

Release Notes

  • If there are user-facing changes, I have added an item to RELEASE-NOTES.txt.

Status

shiki added 14 commits April 29, 2019 14:28
The method `LocalDraftUploadStarter.uploadLocalDrafts` is called when:

- The internet comes back online
- The Posts activity is shown
- When the user performs a pull-to-refresh in any of the Posts tabs
- Removed unnecessary `@Provides` 🤦‍♂️
- Using a simple `getPostsForSite()` method for now. This should probably be replaced with a FluxC method
It does not need to be a singleton right now. Perhaps later.
In this way, we can guarantee that `site` is not `null`.
The `mocked*` can be misleading because the returned instances are not mocks. It is the parameters that are mocked.
@shiki shiki added [Type] Bug [Status] Needs Design Review A designer needs to sign off on the implemented design. labels May 1, 2019
@shiki shiki added this to the 12.5 milestone May 1, 2019
@shiki shiki requested review from malinajirka, maxme and megsfulton May 1, 2019 20:34
@shiki shiki self-assigned this May 1, 2019
Copy link
Contributor

@malinajirka malinajirka left a comment

Choose a reason for hiding this comment

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

Thanks @shiki;)! Good job - the code looks good and it works as described! I've left a couple of in-code comments.

The auto-upload never happens if the Post List is not open. I think this is one of those things that we will need to have an architectural and design discussion about soon.

I believe, even if we decide to create a sync service or something similar we'll still be able to reuse most of this code. ;)

For this PR, I wanted to focus on the process flow and architecture so I intentionally did not include these.
Auto-upload in Pages.

I think the LocalDraftUploadStarter will upload even pages as postStore.getLocalDrafts(site) returns both posts and pages. If you meant, that you haven't added the logic to start the LocalDraftUploadStarter from the pages list screen, then ignore this comment :).

SideNote: I've also noticed the ConnectionStatusLiveData emits changes even when the internet connection changes from LTE -> Wifi or other way round. We might want to consider adding getDistinct(). Wdyt?


fun start(site: SiteModel) {
/**
* @param postListEventsListenerEnabled This is only provided to make this class testable in unit tests.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we might want to consider wrapping fun listenForPostListEvents(..) with an injectable class and inject it into the PostListMainViewModel (inject mocked version in unit tests). I'd rather avoid @ VisibleForTesting unless we really need it. Wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for noticing this. This was the part that I didn't like much. An injectable class would probably be better. I might end up making PostListEventListener public or refactoring it a bit. I'll think about it. 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Used a Factory in e26e540.

}

val localDrafts = postStore.getLocalDrafts(site)
localDrafts.forEach { UploadService.uploadPost(context, it) }
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the internet connection broadcast receiver can send multiple updates within a short timeframe. If I'm not missing anything this code will put multiple instances of the post into the UploadService queue. Should we check for example PostUploadHandler.isPostUploadingOrQueued. I know it'd be far from fool proof solution, but it might at least reduce the number of duplicate requests? Wdyt?

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 might have misread UploadService.unpackPostIntent. I saw the usage of PostUploadHandler.isPostUploadingOrQueued in there and just assumed that it will ignore posts that are currently in the queue. I should have tested that.

My original plan for this class was for it to be a @Singleton and manage its own queue so it will not do a query and upload in a short timeframe. I abandoned that to keep it simple and get your feedback. 🙂 Which turned out to be a good decision. I'll wait for the discussion with Maxime and everyone else before moving forward.

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 ended up just using UploadService.isPostUploadingOrQueued in fa94f00. I figured we'll get to the complicated queuing portion in #9846.

@shiki
Copy link
Contributor Author

shiki commented May 2, 2019

Great review, @malinajirka!

I think the LocalDraftUploadStarter will upload even pages as postStore.getLocalDrafts(site) returns both posts and pages.

Answered in this FluxC conversation.

I've also noticed the ConnectionStatusLiveData emits changes even when the internet connection changes from LTE -> Wifi or other way round. We might want to consider adding getDistinct(). Wdyt?

Good catch! Discussed in this conversation.

@mattmiklic
Copy link
Member

Design-wise this looks pretty good, I have two things I noticed:

  1. When the local draft begins to upload, the status changes from "Local Draft" to "Uploading Post." My first reaction was to fear that my draft was being published, not just saved as a draft on the server. Could we change this to "Uploading Draft" so it's clearer that it's still a draft?

  2. I think in the original design of this progress bar, the intention was for it to be flush against the bottom edge of the post's card background. Can we remove the extra space below the progress bar? Here's an example of what it looks like now and what I'm requesting.

progress-indicator-margin

@malinajirka
Copy link
Contributor

Thanks @mattmiklic! I'll jump in as it's more related to the recent post list changes than to this PR.

When the local draft begins to upload, the status changes from "Local Draft" to "Uploading Post." My first reaction was to fear that my draft was being published, not just saved as a draft on the server. Could we change this to "Uploading Draft" so it's clearer that it's still a draft?

Makes sense;). We can certainly do that, I'd suggest creating a separate ticket as it seems unrelated.

I think in the original design of this progress bar, the intention was for it to be flush against the bottom edge of the post's card background. Can we remove the extra space below the progress bar? Here's an example of what it looks like now and what I'm requesting.

I discussed this issue with Sylvester. The problem is the bottom padding is added there by the system (it's a part of the progress bar). We could somehow workaround it, but we ran out of time for the project so we decided to keep it as it is for now.

@shiki shiki added [Status] Needs Discussion The issue needs to be discussed by the team before it can be resolved. and removed [Status] Needs Design Review A designer needs to sign off on the implemented design. labels May 3, 2019
@shiki
Copy link
Contributor Author

shiki commented May 3, 2019

Thank you, @mattmiklic! I created #9790 for the label rename.

@megsfulton
Copy link

Agree with @mattmiklic's feedback. Otherwise looks good!

This method is what is used for uploading in Post List → Retry and it fixes the issue with uploads failing if they have a media.
shiki added 2 commits May 8, 2019 15:28
This is so we can mock it in unit tests. It does not currently work in unit tests because of the `EventBus` usage.
…9568-upload-local-drafts

# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/viewmodel/helpers/ConnectionStatusLiveData.kt
#	build.gradle
shiki added 2 commits May 10, 2019 12:37
@shiki shiki removed the [Status] Needs Discussion The issue needs to be discussed by the team before it can be resolved. label May 13, 2019
@malinajirka
Copy link
Contributor

@shiki Just to make sure we are on the same page and we are not waiting on each other :P. This is still marked as "Not Ready for Review".

@shiki
Copy link
Contributor Author

shiki commented May 14, 2019

@malinajirka Thanks for checking. Yep, I'll fix the conflicts, retest, and let you know when it's ready.

@shiki
Copy link
Contributor Author

shiki commented May 14, 2019

@malinajirka This is now ready for review again. 🙂

Copy link
Contributor

@malinajirka malinajirka left a comment

Choose a reason for hiding this comment

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

Thanks @shiki ! I've reviewed the changes and tested the app again and everything looks good to me;)! Good job!

@malinajirka malinajirka merged commit 147e3d1 into develop May 14, 2019
@malinajirka malinajirka deleted the issue/9568-upload-local-drafts branch May 14, 2019 13:50
@yaelirub yaelirub added the 5 label Jun 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Offline Support: Local drafts aren't synched when going back online.

7 participants