Search highlight function includes two steps: Scroll list to target position first, then notifyItemChanged to it.
We use a Handler.postDelay to implement this. However, when scheduled runnable starts, the original target position could have changed due to preference list update, calling recyclerview's methods after that will be easy to cause an exception.
This CL ensures highlight position every time before calling recyclerView update, which also contribute to origin fix of RecyclerView IllegalArgumentException to a certain extent.
Test: atest, also test some search results, and see the correct behavior
Fixes: 246411107
Change-Id: Ifa758ce3718b047138079246cdfce99fdf66d5b2
Attempt to remove the animator as early as possible to avoid a RecyclerView crash.
Bug: 246411107
Related bug: 184214085
Test: manual.
Change-Id: I8fcb06836217f4de200a53bb88a1a0b5e42bbe21
- Define an attribute for highlightable menu keys
- List the keys for Settings menu entries
- Support parsing the attribute
Bug: 199017944
Test: robotest
Change-Id: I5759bff591c79d498fffb8b2c2b57f2cb66c4421
This cl fixes two kinds of issues.
1) Highlight two different preferences while clicking a search result.
2) Preference only is highlighted one time.
For the first problem, we don't allow to reuse view holder in the
highlight scenario, and then allow it later.
The root cause of second problem is scrolling to target preference
needs x milliseconds. Thus, we should wait a few milliseconds, and
then start to highlight preference.
Test: Test some search results, and see the correct behavior
Fix: 186060148
Fix: 186010165
Fix: 187886982
Change-Id: I7df3e34efe39ee386fe9ce91d7d6c52cf390e2e7
From the log, the crash happens while RecyclerView is doing
animation stuff. In Settings case, we didn't use any animation
in the list, so the simplest solution is to disable the ItemAnimator
completely.
Test: Check if origin listview behavior is affected.
There's no crash after user comes back from subpage.
Fix: 184214085
Change-Id: If0988cb8e036ce5af1b8d2aa0d4ab77effd476e2
Since the Andorid S, we introduce the CollapsingToolbarLayout
, the highlighted funcation might break for unkown reason.
I observed that broken cases with overlapping issue on tool bar.
The possible root cause is the interation bwtween
CoordinatorLayout v.s CollapsingToolbarLayout v.s Recycler
view.
This cl is definetly a workaround to prevent this issue.
I try to collapse the tool bar with an animation before
we start to scroll the list. This makes the overall transition smooth
but always collapse the tool bar.
Fix: 177968297
Test: Click a lot of search results, and screen should highlight
settings correctly.
Change-Id: Id9c32b642433dcc39c179a2cc83a06e77cc47888
Check a key of preferences also.
Bug: 172699068
Test: Manual
make RunSettingsRoboTests
ROBOTEST_FILTER=HighlightablePreferenceGroupAdapterTest
Signed-off-by: Taesu Lee <taesu82.lee@samsung.com>
Change-Id: I9bb0ea68de0ab1bcc2134345905644d869f69e28
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
- Fragments should not have advanced button when coming from search.
Change-Id: I10a192216b7ff702e73b791acbcc1eb1d71cb407
Fixes: 73348428
Test: robotests
- Moved HighlightableAdapter to its own class
- Replaced ripple with blue background
- Bluebackground only stays for 5 seconds. After that it's replaced by
?attr/selectableBackground
Misc fixes.
- Fix NPE in UserSettings
- Update char limit on a new string
Change-Id: I4687e54e71fd7b9243f520b7630563df58be23d4
Fixes: 71715698
Fixes: 72761974
Test: robotests
