Enable custom list child interactions#314
Enable custom list child interactions#314gdomingues wants to merge 13 commits intoAdevintaSpain:masterfrom
Conversation
|
Hello, anybody available in order to review the pull request? |
|
Thanks for the reminder! We'll review it as soon we can 😊 |
0816efe to
fa6bb08
Compare
|
Hey @rocboronat , I merged master branch to this branch, solved the conflict but now the CI check is failing even though apparently the tests are passing:
Not sure who can help with that |
|
Hum...! That's on our side, then. Thanks a lot for the hassle! |
Sloy
left a comment
There was a problem hiding this comment.
Done! The review took a little bit 😅
|
Thank you so much for your PR, @gdomingues! And of course, sorry for the late answer. |
| fun doOnListItemChild(@IdRes id: Int? = null, position: Int, @IdRes childId: Int, viewAction: ViewAction) { | ||
| performMagicAction(id, position, | ||
| recyclerAction = actionOnItemAtPosition<ViewHolder>(position, clickChildWithId(childId)), | ||
| listViewAction = clickChildWithId(childId) | ||
| recyclerAction = actionOnItemAtPosition<ViewHolder>(position, onChildWithId(childId, viewAction)), | ||
| listViewAction = onChildWithId(childId, viewAction) |
There was a problem hiding this comment.
Thank you for adding this functionality. As a user, what if I wanted to identify the child view using a ViewMatcher? Perhaps this function should use onChildWithMatcher instead of onChildWithId for greater flexibility from an end-user perspective?
|
@Sloy @rocboronat I have left a comment about how I think this could be improved but should we consider merging the PR if there are no issues with it as it is? This functionality would be quite useful to us. Thanks. |
What I did
This pull request is basically a reissue from #297. I had to recreate this pull request because for some reason the other branch got crazy when I tried to rebase it on top of master after the migration to AndroidX.
Add new feature that allows us to perform a custom
ViewActionon a child view of a list item, with a similar idea and API to the feature introduced by #280.I have added an example to README.md:
The method
BaristaListInteractions.clickListItemChildwas "rerouted" to use the newly introduced method.ListsChildClickTestclass was renamed toListsChildTest, and tests for the new feature were added to that file.A call to
closeKeyboard()was added right after the activity is launched inListsChildTest, because some click tests were randomly failing when trying to click on the button when the soft keyboard is opened. In some scenarios of this test class the firstEditTextrequest focus right after the activity is created, which causes the keyboard to show up automatically in case it's enabled for the device. Then instead of closing the keyboard for each test in which that occurs, I'd rather always do it after launch and save time from people who need to add new tests to this class in the future.