-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
RI: Fetch "Interests" tags from ReaderTagRepository #12490
Conversation
…nterests-api-results-from-repo
…nterests-api-results-from-repo
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
You can test the changes on this Pull Request by downloading the APK here. |
eventBusWrapper.register(this) | ||
|
||
ReaderUpdateServiceStarter.startService( | ||
contextProvider.getContext(), | ||
EnumSet.of(INTEREST_TAGS) | ||
) |
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'm registering to event bus inside the use case, I've not seen this practice elsewhere in the code. Let me know if you see any downside.
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.
@ashiagr - There is similar logic in #12454, but I used init & stop to set up the bus to support multiple requests at the same time. Not sure if you'll need to do that here, but wanted to mention it. Also, in the same PR, I have a ReaderRepositoryDispatchingUseCase
that I use for all the repo usecases to set up coroutine context.
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.
@malinajirka what do you think? Should we use init
& stop
pattern in this case? I'll make changes accordingly.
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.
Since this useCase doesn't support parallel request by its nature, I think the current implementation looks good. I don't think we need to change anything.
@@ -2,6 +2,7 @@ package org.wordpress.android.ui.reader.repository | |||
|
|||
sealed class ReaderRepositoryCommunication { | |||
object Success : ReaderRepositoryCommunication() | |||
data class SuccessWithData<out T>(val data: T) : ReaderRepositoryCommunication() |
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.
Passing interests directly to the VM via SuccessWithData
. We might want to keep a single Success
state with an optional data param. Lmkwyt.
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.
@ashiagr - I like this idea for those non-reactive repository situations and I can go with either option. In one situation we check for the class and the other a quick optional check.
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.
Looks like we'll have to keep just one Success state to avoid else
condition in when
clause as seen here.
private final ReaderTagList mInterestTags; | ||
private final boolean mDidSucceed; |
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.
Added boolean to detect if request succeeded similar to SearchPostsEnded
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.
Looks good so far. Nice work.
eventBusWrapper.register(this) | ||
|
||
ReaderUpdateServiceStarter.startService( | ||
contextProvider.getContext(), | ||
EnumSet.of(INTEREST_TAGS) | ||
) |
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.
@ashiagr - There is similar logic in #12454, but I used init & stop to set up the bus to support multiple requests at the same time. Not sure if you'll need to do that here, but wanted to mention it. Also, in the same PR, I have a ReaderRepositoryDispatchingUseCase
that I use for all the repo usecases to set up coroutine context.
@@ -2,6 +2,7 @@ package org.wordpress.android.ui.reader.repository | |||
|
|||
sealed class ReaderRepositoryCommunication { | |||
object Success : ReaderRepositoryCommunication() | |||
data class SuccessWithData<out T>(val data: T) : ReaderRepositoryCommunication() |
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.
@ashiagr - I like this idea for those non-reactive repository situations and I can go with either option. In one situation we check for the class and the other a quick optional check.
…ts screen is showing
@zwarm , @malinajirka - ready for another look 🙇♀️. |
# Conflicts: # WordPress/src/main/java/org/wordpress/android/ui/reader/repository/ReaderRepositoryCommunication.kt
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.
All tests pass as expected, nice work. I left one comment, but it won't stop approval. 👍
} | ||
} | ||
|
||
@Subscribe(threadMode = ThreadMode.MAIN) |
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.
@ashiagr Just curious if this could be a Background thread. It's been a while since I used GreenRobot, so maybe things have changed, but iirc the post request is not made on the Main thread, so it will thread switch to emit on Main. Or I may be completely off the mark. wdyt?
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.
Switched to BACKGROUND thread in ad7c6b0.
Parent Issue: #12027
This PR
ReaderTagRepository
to return Interest API results to the Interests VM utilisingReaderRepositoryCommunication
andFetchInterestTagsUseCase
Looking for an early feedback before moving ahead, so marking it as draft.To Test
Prerequisite - RI FF flag s enabled
To test remote request failure error, comment out
SuccessWithData
response and returnRemoteRequestFailure
here.ToDo
UPDATE: There are duplicate tags with "Comics" title in the feed. There shouldn't be such a case in the final feed. I'll put a "unique" check to fix it. - 2843b0f
I'm looking for a better solution for language change support. I've removed- 7ac80c2isStarted
check so that we can re-request interests from the server for the changed language but it now happens every time we toggle bottom tabs or rotate screen. I'm thinking to compare last and new language in the interests VM for this something like conditional re-request of tags here.FetchInterestTagsUseCase
not yet added. Will include along with other use cases to save interests and get user tags.PR submission checklist:
RELEASE-NOTES.txt
if necessary.