GSKStretchyHeaderView icon indicating copy to clipboard operation
GSKStretchyHeaderView copied to clipboard

Redraw issue when in inactive tab

Open jdanthinne opened this issue 7 years ago • 5 comments

It seems that when used in an inactive tab, the headerView doesn't seem to correctly redraw when the tableView is reloaded.

Here's a precise example.

In this first case (correct behaviour), I scroll down the down the table, and the headerView (the faces and dates) begin to scroll and I let the headerView hidden at half its height. If I click on another face while staying in the same tab, the table is reloaded, and the headerView correctly position itself at its original position, full size. artboard

In the second case (wrong behaviour), I scroll down the table at the same position, then I CHANGE TAB, click on another face (which trigger the same refresh function on every tab via the NotificationCenter), then if I go back to the previous tab, the headerView is at the correct position, but is strangely clipped!. artboard 2

The only/ugly workaround I found is to force redraw by doing this:

subjectsAndPeriodView.maximumContentHeight += 1
subjectsAndPeriodView.maximumContentHeight -= 1

Any advice on how to trigger the redraw correctly? Thanks!

jdanthinne avatar Apr 11 '18 06:04 jdanthinne

I have a similar issue when I scroll it and segue away from the page and pop back to the page with the stretchy view that the scrolled part seems to be blank.

Did you manage to solve it?

andrebng avatar May 22 '18 10:05 andrebng

Unfortunately, no…

jdanthinne avatar May 22 '18 10:05 jdanthinne

I think its the scrolled part that is blank.

I partly fixed it by setting the maximumContentView again (setMaximumContentHeight none-animated) in the viewWillDisappear so it scrolls back to its original position.

andrebng avatar May 22 '18 11:05 andrebng

Hi,

sorry for not answering before, but I'm having very little time lately to dedicate to this project. I just had a look at the implementation of -setMaximumContentHeight: and it's forcing a relayout of the scrollView when it changes. This is hacky but you could try calling -gsk_layoutStretchyHeaderView:contentOffset:previousContentOffset: manually.

If you could provide a small sample project that includes the bug (via a PR for the example project), I could have a look this week.

Thanks!

gskbyte avatar May 23 '18 08:05 gskbyte

The hacky function seems private… The only public function available is gsk_transplantSubviews.

capture d ecran 2018-05-28 a 12 44 31

jdanthinne avatar May 28 '18 10:05 jdanthinne