Scroll covers too small area (half a screen)

[corneln-roweb]

Hi Cris,

I may be using it wrong, but still I'm informing on something I noticed regarding Scroll action.
I am not sure I understand the purpose of

I am sure it may make sense for most screens where text is more condensed.
In my test app scenario I use some blocks/containers of a dashboard on which you can tap.
The problem is that the scroll does not cover enough portion of the screen to make the yet invisible elements visible. So the searched container never gets into view and does not exist, from the tests point of view.
You can see more here:
https://www.youtube.com/watch?v=52sNgJgH3Qc
and here how the scroll-to elements are built: https://monosnap.com/file/84tTamL8D1XfhSEH3smplCVAVgV9pL

I tried both kind of scroll, by ID and text and by text only.
Not sure if the formula you use can be tweaked or parametrized further, so you can decide if you need the 50% screen scroll of 70% or 90%.

I also have a second app to test this with:

1. The view of the scroll: https://take.ms/vOHgT. Partially made by the library vs the total scroll that would be needed in order to click on the element.
2. The UI attributes: https://take.ms/gNme8
3. The code and result https://take.ms/zLHdX. When not using the id also the scroll seems total. When using the id also (the recommended way) the scroll seems only half way and the element is not actually found.

Please let me know if more information is needed to understand the scenario.

Thank you,
Cornel Neacsu

[ctrevarthen]

Hi Cornel, thanks for the very detailed examples! I’ll dig into it this week.

[ctrevarthen]

Hi @corneln-roweb,

I just released version 1.12.1 of the library. It does 2 things:

1. Adds a ScrollFactor parameter to existing Scroll functions. This allows you to do what you suggested by scrolling either 25%, 50%, 75%, or 100% of the screen at a time, while still looking for the requested text each time. You can add ScrollFactor.XLARGE as a parameter to the scollListToElement function, for example, in order to make sure the entire screen scrolls each time your test doesn't find the matching element in the list.

2. Adds documentation for Swipe functions (sorry, I forgot to document before). Swiping might be an alternative if scrolling lists of items does work for you. Swiping will take into account the entire height or width of the screen to perform the action. You'd need to put this function into a loop yourself, where you swipe, then check for an element on the screen, then swipe again if not found. It's not all-in-one like the Scroll functions, but might work better for non-standard situations.

Please let me know how this works out for you!

[Coconeacsu]

Hi @ctrevarthen,

I tried the new jar version and:

1. ScrollFactor looks very nice and definitely improves my scenario a lot.
2. Indeed, if I use just Scroll first in the initial screen (first and second box visible only) the library fails saying that it cannot find the element. However, it seems enough to just scroll up a bit (by scrolling to third element or by your hint of Swipe.swipe(SwipeDirection.BOTTOM_TO_TOP)) then the Scroll.scrollListToElementWithText with ScrollFactor.XLARGE knows how to swipe multiple times to the last element in the screen (eleventh).
   I understand much more now why this happens. This is because the FrameLayout of third and fourth elements are visible but not their inner TextView.
   The library cannot do magic in this case since there is no text in the screen and it seems we reached the bottom of the screen, as already visible in the initial printscreen https://monosnap.com/file/84tTamL8D1XfhSEH3smplCVAVgV9pL.

I am attaching a log file where the fifth element was not found by direct scroll attempt (class="android.widget.TextView" text="first" and class="android.widget.TextView" text="second" are visible) but nothing else Fifth.log.

I am happy however with combining Scroll and Swipe, it does the job. Thank you for a great upgrade you made.

As a token of gratitude, I can offer testing it more and providing other (hopefully worth-considering) ideas, if you feel its useful.
Otherwise, I am really grateful for this library, Chris. Great job!

Thank you,
Cornel

[ctrevarthen]

Hi @corneln-roweb - glad you were able to find a way to get it working!

I would gladly welcome new ideas to make the library more useful. Please feel free to create new issues and I'll take a look!

Thanks!

Chris