-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scroll indicators update - positioning correction, support for both indicators at the same time #229
base: master
Are you sure you want to change the base?
Conversation
be4e9de
to
38a274b
Compare
38a274b
to
9f1538c
Compare
…a commented-out stub that could help fix that later
Codecov Report
@@ Coverage Diff @@
## master #229 +/- ##
==========================================
+ Coverage 52.15% 52.86% +0.71%
==========================================
Files 87 87
Lines 3160 3210 +50
==========================================
+ Hits 1648 1697 +49
- Misses 1512 1513 +1
Continue to review full report at Codecov.
|
…nd not only didSet)
hey @ephemer :) I improved a lot here, addressing all the smaller comments you had. Unfortunately, I still have a concern: if you check |
@janek we could override But to me that's an issue that's totally separate from this PR. If you would like to update that let's do it for a practical (rather than idealistic) reason: right now I don't think it matters for us |
cool, that's what I was thinking, too, for the implementation. Glad I had the right idea (and the right idea to ask). In that case, this is ready for re-review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @janek, code-wise the library code seems fine but the tests are very shonky as is.
The tests contain false assumptions and hardcoded outdated values which don't mean anything. Sometimes we're calling an identical assertion twice (what's the point in calling XCTAssertEqual
on two static values twice?), even though the second time the reality is that the underlying values have changed. It's not up to scratch as written.
Please try to rewrite the new tests in more finer-grained ones that test one thing, that are clearly named so it's obvious what to fix if they break, that don't rely on hardcoded values if possible, and that test the absolute minimal amount possible while still ensuring behaviour. And please be careful to get the new indexes after changing the order of an array.
UIKitTests/UIScrollViewTests.swift
Outdated
let indexOfInsertedView2 = scrollView.subviews.index(of: viewToBeInserted1)! | ||
|
||
// If we try to insert at a position occupied by or above indicators, | ||
// the inserted view should 'slide down' and assume the highest position below indicators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, these comments are helpful thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but this should just be its own standalone test. it tests one single behaviour that obviously must be true. if we insert a subview it should always be behind the indicators. end of test. if that breaks we know what to fix. does that make sense?
UIKitTests/UIScrollViewTests.swift
Outdated
let indexOfInsertedView1 = scrollView.subviews.index(of: viewToBeInserted1)! | ||
|
||
// This might seem weird, but that's what happens in iOS: | ||
// the inserted view and the one that was in its place before will have the same index |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible this is only weird because of how the test is written?
It doesn't seem that weird to me that the indexes will overlap once we insert a new subview if we're not getting the new indexes after inserting the subview?
What am I missing here? It seems like we should get the new indexes here which would be less confusing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're not missing anything, I can't believe I missed this! 🤦♂ thanks!
UIKitTests/UIScrollViewTests.swift
Outdated
|
||
|
||
let viewToBeInserted2 = UIView() | ||
scrollView.insertSubview(viewToBeInserted2, at: 5) // position currently occupied by scroll indicator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this test is too long. this could be two or three separate tests which would be much clearer if one of them fails
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this and all the other very valid concerns. I rewrote the test(s) in a way that hopefully takes into account all of them.
UIKitTests/UIScrollViewTests.swift
Outdated
XCTAssertEqual(indexOfInsertedView1, 1) | ||
XCTAssertEqual(label2Index, 1) | ||
XCTAssertEqual(label3Index, 2) | ||
XCTAssertEqual(horizontalIndicatorIndex, 3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is misleading at best: all of these indexes will be incorrect now, so what's the point in asserting what their old value was? I'm really not happy with this, as written
UIKitTests/UIScrollViewTests.swift
Outdated
|
||
XCTAssert(label2Index > label1Index) | ||
|
||
XCTAssertEqual(label1Index, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the point in adding three subviews? we already have other tests that test the behaviour of addSubview
. we're just writing more test code that we have to maintain.
how is this different to the case at the bottom?
UIKitTests/UIScrollViewTests.swift
Outdated
let label2Index = scrollView.subviews.index(of: view2)! | ||
let label3Index = scrollView.subviews.index(of: view3)! | ||
|
||
XCTAssert(horizontalIndicatorIndex > label1Index) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how is this different to the case at the bottom?
UIKitTests/UIScrollViewTests.swift
Outdated
|
||
let horizontalIndicatorIndex = scrollView.subviews.index(of: scrollView.horizontalScrollIndicator)! | ||
let verticalIndicatorIndex = scrollView.subviews.index(of: scrollView.verticalScrollIndicator)! | ||
let label1Index = scrollView.subviews.index(of: view1)! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it makes sense to put this into a variable, because (as mentioned below) it will be invalid as soon as we insert another view.
XCTAssertGreaterThan(
scrollView.subviews.index(of: scrollView.horizontalScrollIndicator),
scrollView.subviews.index(of: view1)
)
thanks @ephemer! I didn't reply to all of your comments, but I took them into account when rewriting tests. It's definitely a big improvement, and I'm quite happy. Also very happy to perfect them if there is anything else that you see could be improved :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! I am stoked with how great these new tests you wrote are looking now! Thanks for your work on this @janek
scrollView.addSubview(mockView) | ||
|
||
XCTAssertGreaterThan( | ||
scrollView.subviews.index(of: scrollView.horizontalScrollIndicator)!, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests look seriously amazing now. Great work @janek!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's too nice! thanks a lot!!
Corrects positioning, adds configurable indicator insets, adds conditional positioning when one/both indicators are visible.
Type of change: Bug fix + feature
Todos
scrollIndicatorInsets
(as per apple docs)Expected behavior
Scroll indicators should now position and style themselves in a way indistinguishable from Apple's.
Testing Details
Tested visually on NativePlayer with some additional marker views for better confidence.
Tested with a smaller dedicated app, both visually and numerically.
Screenshots
Current (desired) positioning of indicators:
Please check if the PR fulfills these requirements