-
-
Notifications
You must be signed in to change notification settings - Fork 365
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
Automatic Scroll on Search added #988
Automatic Scroll on Search added #988
Conversation
Any suggestions for code improvements, behavior change are highly appreciated. |
Please take a look @vbuberen @cortinico |
Thanks for sendign this over @4shutosh This week I'm quite busy with KotlinConf, I won't be able to review this before the end of the conference. I can check it just after π |
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 @4shutosh π
Looks good mostly!
I just have a few comments, looking forward to everyone's opinion.
...rc/main/kotlin/com/chuckerteam/chucker/internal/ui/transaction/TransactionPayloadFragment.kt
Outdated
Show resolved
Hide resolved
...rc/main/kotlin/com/chuckerteam/chucker/internal/ui/transaction/TransactionPayloadFragment.kt
Outdated
Show resolved
Hide resolved
<com.google.android.material.floatingactionbutton.FloatingActionButton | ||
android:id="@+id/fab_to_next" | ||
android:layout_width="wrap_content" | ||
android:layout_height="wrap_content" | ||
android:backgroundTint="@color/chucker_fab_background_colour" | ||
android:contentDescription="@string/chucker_scroll_buttons_for_search" | ||
android:src="@drawable/chucker_ic_arrow_down" | ||
android:visibility="gone" | ||
app:fabSize="mini" | ||
app:layout_constraintBottom_toBottomOf="parent" | ||
app:layout_constraintEnd_toEndOf="parent" | ||
app:tint="@color/chucker_color_on_primary" | ||
tools:visibility="visible" /> | ||
|
||
<com.google.android.material.floatingactionbutton.FloatingActionButton | ||
android:id="@+id/fab_to_previous" | ||
android:layout_width="wrap_content" | ||
android:layout_height="wrap_content" | ||
android:layout_marginEnd="4dp" | ||
android:backgroundTint="@color/chucker_fab_background_colour" | ||
android:contentDescription="@string/chucker_scroll_buttons_for_search" | ||
android:enabled="false" | ||
android:rotation="180" | ||
android:src="@drawable/chucker_ic_arrow_down" | ||
android:visibility="gone" | ||
app:fabSize="mini" | ||
app:layout_constraintBottom_toBottomOf="parent" | ||
app:layout_constraintEnd_toStartOf="@id/fab_to_next" | ||
app:tint="@color/chucker_color_on_primary" | ||
tools:enabled="false" | ||
tools:visibility="visible" /> | ||
|
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.
While the FABs do seem to provide an efficient usage of the real estate on the screen I feel displaying a summary of the filtered search results vis-a-vis the current highlighted search result would be more disambiguous.
For e.g <Searched Text> 3/11
We could chose to display the search results info summary by extending the App Bar to also include the icons(chevrons) which could be used to traverse through the filtered search results.
@cortinico @vbuberen thoughts?
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.
We could chose to display the search results info summary by extending the App Bar to also include the icons(chevrons) which could be used to traverse through the filtered search results.
This would be preferred IMHO. Specifically having the # of occurrences would be helpful (see my video in top comment also).
Also I would refrain from using FloatingActionButton
as they're specific to MDC and I'm looking into having MDC being used as a compileOnly
dependency. So using classes directly inside the XML file makes things a bit harder.
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.
Yeah, I agree.
Will do the changes to summarise the search results in the app bar, along with the navigation chevrons.
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.
Great work @4shutosh
I've been playing a bit with this feature and I believe, as @ArjanSM suggested, we need a bit more of a visual clue on the # of occurrences.
For example, look at this flow where all the occurrences are next to each other:
video-1682250533.mp4
Having no visual clue makes it impossible to know if there are "more" occurrences later. Also, I think we might highlight differently the selected occurrence (like with a different color).
<com.google.android.material.floatingactionbutton.FloatingActionButton | ||
android:id="@+id/fab_to_next" | ||
android:layout_width="wrap_content" | ||
android:layout_height="wrap_content" | ||
android:backgroundTint="@color/chucker_fab_background_colour" | ||
android:contentDescription="@string/chucker_scroll_buttons_for_search" | ||
android:src="@drawable/chucker_ic_arrow_down" | ||
android:visibility="gone" | ||
app:fabSize="mini" | ||
app:layout_constraintBottom_toBottomOf="parent" | ||
app:layout_constraintEnd_toEndOf="parent" | ||
app:tint="@color/chucker_color_on_primary" | ||
tools:visibility="visible" /> | ||
|
||
<com.google.android.material.floatingactionbutton.FloatingActionButton | ||
android:id="@+id/fab_to_previous" | ||
android:layout_width="wrap_content" | ||
android:layout_height="wrap_content" | ||
android:layout_marginEnd="4dp" | ||
android:backgroundTint="@color/chucker_fab_background_colour" | ||
android:contentDescription="@string/chucker_scroll_buttons_for_search" | ||
android:enabled="false" | ||
android:rotation="180" | ||
android:src="@drawable/chucker_ic_arrow_down" | ||
android:visibility="gone" | ||
app:fabSize="mini" | ||
app:layout_constraintBottom_toBottomOf="parent" | ||
app:layout_constraintEnd_toStartOf="@id/fab_to_next" | ||
app:tint="@color/chucker_color_on_primary" | ||
tools:enabled="false" | ||
tools:visibility="visible" /> | ||
|
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.
We could chose to display the search results info summary by extending the App Bar to also include the icons(chevrons) which could be used to traverse through the filtered search results.
This would be preferred IMHO. Specifically having the # of occurrences would be helpful (see my video in top comment also).
Also I would refrain from using FloatingActionButton
as they're specific to MDC and I'm looking into having MDC being used as a compileOnly
dependency. So using classes directly inside the XML file makes things a bit harder.
...rc/main/kotlin/com/chuckerteam/chucker/internal/ui/transaction/TransactionPayloadFragment.kt
Outdated
Show resolved
Hide resolved
...rc/main/kotlin/com/chuckerteam/chucker/internal/ui/transaction/TransactionPayloadFragment.kt
Outdated
Show resolved
Hide resolved
listOfScrollableIndex.isEmpty() -> { | ||
// scroll to top | ||
currentSearchScrollIndex = 0 | ||
payloadBinding.payloadRecyclerView.smoothScrollToPosition(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.
I'm unsure this is good from the UX point of view (i.e. the user is searching and you keep on scrolling up and down).
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 prefer the implemented way, quickly jumping to the position. However, I can think of two solutions here.
We can increase the initial delay.
Or we can only scroll after the IME_ACTION_DONE or keyboard closed - along with the summary of search results in the app bar.
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.
Sorry my comment was related to the re-scroll to top once listOfScrollableIndex.isEmpty
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.
Oh okay, yeah let's not scroll in that condition. Will do the change.
CHANGELOG.md
Outdated
@@ -15,6 +14,7 @@ Please add your entries according to this format. | |||
* Added ability to export transactions to a file programmatically, LOG or HAR. | |||
* GraphQL OperationName header to transaction title [#69], [#116] | |||
* Added support for Android 13 and notifications permission handling | |||
* Added scroll to highlighted text search in response screen [#988]eye |
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.
* Added scroll to highlighted text search in response screen [#988]eye | |
* Added scroll to highlighted text search in response screen [#988] |
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.
My bad
@4shutosh can you also resolve the conflicts? |
yes, on it. |
This looks great! π
This happens if you try to search for "active" in the
You can reproduce this on the |
Haven't tried to find a solution for point 2 yet, but not able to figure out 1 after quite a few tries. It happens only after we've done the search once in a transaction fragment, go back, and go to another request transaction screen. I believe something wrong with the instance of the fragment, or while making the copy of Any help regarding the same will be highly appreciated. |
Both the points are fixed now @cortinico. Implemented substring level highlighting for the body lines of the response. My doubt regarding the misbehaving fragment instance was correct. Please review, and let me know if any other changes are required. |
Hey there. I am joining a bit late, but would like to leave some general feedback.
|
Please let's do this in a separate PR as @vbuberen mentioned |
Reverted to old viewpager implemented. Search summary moved to fragment, below the tab layout. I suspect some misbehaving highlighting on the requests page, please check if possible. Will test it, and fix if found something. Please take a look @cortinico, let me know if any changes are required. |
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.
Please take a look @cortinico, let me know if any changes are required.
Looks great to me @4shutosh
I've done some manual testing and all looks great to me!
Awesome @4shutosh @cortinico . |
π· Screenshots
π Context
Scroll to Search content added, fixes #388
π Changes
Scroll to search item in response screen added
π Related PR
π« Breaking
No
π οΈ How to test
Open Response Screen, ideally where the whole body covers more than the screen size, and search for something that is not visible in the current scroll state to see the change.
After searching if found, the recycler view is automatically scrolled to the position, making it easy to test/evaluate the response. Earlier, just the text was being highlighted making it hard to find in a lengthy response.
β±οΈ Next steps