Scrolling issues about superslim

[PatrickDattilio]

This sounds like a StaggeredGridView, which is not yet supported.

[GoodSir42]

It sounds like one, but it is not ;) Due to the fact that staggered layouts are not yet supported I put the views in a grid. It works perfectly fine if the biggest item is not the first one in a grid row, so there must be some small measuring issue. I am trying to find it right now, but it's quite hard if you don't know where to look.

[TonicArtos]

Grid layout does handle different height items but makes the row fit the max row item height. I am not seeing this error in v0.4.4.

[GoodSir42]

I am, though (also using 0.4.4). How can I help you to reproduce this? Unfortunately I can not provide the project itself.

[GoodSir42]

Where's the max row height calculated? Perhaps I can fix it myself.

[TonicArtos]

GridSLM#fillRow(…)

[TonicArtos]

However, there seems to be a problem passing through margins in the layout params.

[GoodSir42]

Even if I remove the margins I can not scroll back to the top any more. I will have a look at this tomorrow if you can't reproduce it.

[TonicArtos]

Okay the margin issue is just a red herring, the margins were being stripped as they were passed through the grid layout layout param constructor.

Anyway, there is actually something strange going on with CardView. Sometimes cards are not measuring as the same size.

[TonicArtos]

Is the card view completely cut off? Or is text content cut off? If it is the latter, then I think it is basically the same issue as #56. I suggest making sure you are using different view type ids for views going to different layouts, and for headers too.

[GoodSir42]

The card view is completely cut off. I am also using different view types, but the views themselves are of a dynamic height. I will display some dummy values and post a few screen shots later.

[GoodSir42]

I just hit the autocompletion a few times to fill some text views. Here are my results:

If the second card is bigger than the first one everythingn is ok.

However if the first one is bigger the recycler view doe snot scroll any more and cards may be cut off if I scroll there slowly. If I scroll to the position with a fast movement I see the complete card (as in the image).

[TonicArtos]

Are those TextEdit views inside the cards? Maybe that is related.

[GoodSir42]

Yes, but the issue is not related. They were just the only ones I could fill easily.
I set the values by typing into a dialog and then call settext on the EditText later.

The issue also happens with LinearLayouts that I fill programmatically (that was the original reason). It really seems to depend on the size of the views.

[GoodSir42]

I also get weird values from getDecoratedBottom(). They seem to be changing based on the scroll speed.

[GoodSir42]

I think I found the issue that blocks the scrolling, but I don't think that this was the original problem...

Look at this commit in my fork, please: https://github.com/Eifelschaf/SuperSLiM/commit/90f6c8b4c0e9f203554a7874fe3c607f55c54325

Does this make sense? This change allows me to scroll up at least (still with the cut card)

[TonicArtos]

If that early return is the issue then it means the section bottom edge is not being calculated properly.

[TonicArtos]

Hang on, is this only happening for the very last item in the entire (super) layout, not just a grid layout?

[TonicArtos]

Aha, there we go.

[GoodSir42]

Yes, I think I nailed it down. The getAnchorAtEnd() return the last view, not the biggest in the last row :)
This is why it only appears in the grid layout..

[TonicArtos]

The reason for the cut off is that the grid is not computing the bottom edge correctly, so the scroll is not advancing to the real end of the layout.

[TonicArtos]

Yeah, getAnchorAtEnd should be passing through to the SLM.

[GoodSir42]

Do you think it's a big deal to get this fixed?

[TonicArtos]

Actually, it should be using getAnchorAtEnd, it should be asking the SLM directly for the bottom edge.

[TonicArtos]

It should be a minor fix. Give me a couple of minutes and I'll push a snapshot for you to test.

[TonicArtos]

Yeah, it was trivial to fix. I am just testing it now. There are some other small fixes that have been pulled together with this and I want to check it is all working together.

[GoodSir42]

Sure, take your time.

[TonicArtos]

Okay, I didn't come across any problems. Check the snapshot, if it is fine I'll push up the new version.

repositories {
    maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
}

dependencies {
    compile 'com.tonicartos:superslim:0.4.5-SNAPSHOT'
}

[TonicArtos]

sorry

[TonicArtos]

hangon

[TonicArtos]

Okay, I actually merged the fix in to the snapshot this time. You can test it now :)

[GoodSir42]

You are awesome! It works perfectly fine now.

[GoodSir42]

stop.. I just encountered it again. I have to re-check this...

[GoodSir42]

OK, the scrolling is fixed, but the card is still cut if I scroll slowly. Are you sure you forward the measurement calls everywhere?

[TonicArtos]

Yeah, I am seeing the bug in master after merging it, but not on the release branch. There is something I have to check.

[GoodSir42]

As I said: take your time :)

[TonicArtos]

Oh, hey, can you make sure to refresh the snapshot? Because there were two copies released close to each other, the unfixed one might be cached on your machine. Just to be sure.

[GoodSir42]

I only got it after the second release, but I will check again.

[TonicArtos]

I am definitely not seeing the bug anymore. I fixed the code divergence on master too.

[GoodSir42]

I just did a full rebuild with 0.4.5-snapshot and it's still there.. did you try scrolling slowly?

[TonicArtos]

Yeah, slow scrolling is fine here. I've tested with a number of views including EditText. I just noticed couple of bugs with EditText, but they are quite different (performance and keyboard interaction).

[GoodSir42]

I will quickly try a rebuild with the current source code. It's the early_release_4 branch, right?

[TonicArtos]

Yes

[GoodSir42]

Nope, still there, even with the latest source. I will have a look at it now and let you know if I find something more specific.

[GoodSir42]

As I thought: the scrollVerticallyBy method still uses the wrong view for measurement

[GoodSir42]

ahhh shit.. This may have been my fault...

[TonicArtos]

Okay. Here is what should be happening. On scroll a leading edge is calculated. For a scroll towards the end of the content that edge is the height of the view + the scroll displacement.

To fill the leading are in the scroll, the gridSlm should be measuring and laying out content row by row, up to that edge. The line (markerLine) up to which the grid has filled should be the bottom of the last grid row laid out.

The fix to this problem was an adjustment to use the SLM to calculate the end of the content (grid slm knows about rows, layout manager does not), rather than assuming the anchor position is at the bottom edge.

[GoodSir42]

OK. It's fixed. It was just some very weird behavior:

I removed all sectionmanager markups from my non-header views as they were ignored for layout anyways. Turns out that they are taken into account to get the slm for measurement now.

[TonicArtos]

and in v0.5.0 they don't matter again

[TonicArtos]

Actually, they were not quite always ignored. For the scroll indicator they are required in v0.4.x.

[GoodSir42]

great! Thanks! I will go with the current solution for now (multiple markup) and wait for 0.5 to change them.

[TonicArtos]

Yeah, sorry. It is a pain, I know. :(

[GoodSir42]

It's ok as long as it works :) Thanks for helping me.

[TonicArtos]

But now I have two more problems to fix for EditText.

[TonicArtos]

:) You're welcome, reporting bugs helps me too.

[GoodSir42]

If i can help you with the edit text just let me know.

[TonicArtos]

Thanks for offering. I am going to tackle it after #53. I will have to make a number of changes to the layout code so I might be able to fix it with that anyway.

[TonicArtos]

Alright, v0.4.5 should be available now.