Open mecoFarid opened 2 years ago
and wonder why almost no care is given for such a big blocker.
This part blows my mind. How about you do some care?
We work around this by capturing a screenshot per page of a ScrollView / RecyclerView (screenshot->scroll->repeat).
@nispr Hey. I'm facing a similar issue now and I'd be grateful for a few more details of your workaround if you can remember it. I'm wondering how exactly you scroll the ScrollView page by page between the screenshots. I tried scrollBy(0, scrollView.height)
, hoping that should do the trick, but I ended up with an unexpected behavior like this:
@azabost Hi Andrzej, please pardon my delay. Did you figure it out? We use scrollBy(0, it.measuredHeight)
. However I remember I had lots of main <> instr thread synchronization issues, basically resulting in screenshots being taken even though the UI was not completely idle. So after each screenshot, there's quite a bit of desperate manual sync (pushing an empty task to main thread, or the like). Perhaps this is your issue?
Hmm, I don't think my issue was related to threading, but I might be wrong.
Anyway, I dealt with my specific situation completely differently, e.g. I don't have a ScrollView anymore and I compare Bitmaps instead of screenshots of any views, which fits my needs even better than before.
I guess the short explanation above is too ambiguous and may leave you wondering what I was doing and why I don't need a ScrollView anymore, so let me say a few more words just to let you understand my situation (and why it was so specific).
I was working on a piece of machinery that was originally supposed to build some Views/ViewGroups (in memory, not even displaying them anywhere), then turn all of them into a Bitmap and print it on a physical printer (i.e. the Android UI system was used to create the content of the printout). At some point, I thought it would be great to cover the logic I created with some screenshot tests. Since I was creating Views anyway, I reused most of the logic in an artificial Fragment to display them, take the screenshot of said Fragment with Shot (Shot uses this repo as a dependency), and compare the outputs. However, I was building many views so they didn't fit on the screen, therefore I added a ScrollView and that's how I ended up with this issue. Later on. I figured out I can use Shot to compare the Bitmaps instead of Views/Fragments/etc., so I brought another piece of my logic for turning the Views into Bitmaps and I started comparing them instead. Now, I don't even need a Fragment to host the Views anymore, let alone a ScrollView.
I would still be interested to know how to resolve the problem I had, but it's not that important to me now.
Expected behaviour
We should be able to capture large views even if parts of it is outside bounds of the window. E.g. views inside
ScrollView
Actual behaviour
Library captures only what is shown on the window and discards the rest of the view that is is outside the window
Steps to reproduce
Add multiple view(s) inside
ScrollView
until part of theScrollVIew
is placed outside the window then run the screenshot recorder task.We can resolve the issue by providing
viewHeight
tosetExactHeightPx()
method but that is not an actual solution. Problem is you will get this issue Max Pixel Error if provided dimension passes the limits set by library.I can't really find any proper workaround for this problem, this is a major problem given you test your device in different resolutions and wonder why almost no care is given for such a big blocker.