Status Update
Comments
cl...@google.com <cl...@google.com>
[Deleted User] <[Deleted User]> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
an...@google.com <an...@google.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
[Deleted User] <[Deleted User]> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
an...@gmail.com <an...@gmail.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
an...@google.com <an...@google.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
[Deleted User] <[Deleted User]> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
no...@gmail.com <no...@gmail.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
mm...@gmail.com <mm...@gmail.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
fl...@gmail.com <fl...@gmail.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
ko...@gmail.com <ko...@gmail.com> #11
va...@gmail.com <va...@gmail.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
si...@gmail.com <si...@gmail.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
bi...@moveinsync.com <bi...@moveinsync.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
an...@google.com <an...@google.com>
[Deleted User] <[Deleted User]> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
ni...@gmail.com <ni...@gmail.com> #16
ko...@gmail.com <ko...@gmail.com> #17
Do you accept contributions for this issue?
an...@google.com <an...@google.com> #18
Hello. Thanks, but no contributions are needed as this functionality is in progress already. We will keep you updated
ko...@gmail.com <ko...@gmail.com> #19
Is there a tracking change for it in the AOSP repo?
al...@google.com <al...@google.com> #20
Raising to P1
since this has been open for so long with no updates.
Back to Compose team for review since we have not heard from the assignee in the ~2 months it has been assigned.
ko...@gmail.com <ko...@gmail.com> #21
Only a few lines of code are needed to implement this:
- Add new parameter to
LazyListState
constructor (and torememberLazyListState
):
private val updateScrollPositionIfFirstItemMoved: Boolean = true // default to true to not break existing code, but it might be worth changing to false by default
- Update function
LazyListState.updateScrollPositionIfTheFirstItemWasMoved
to this:
internal fun updateScrollPositionIfTheFirstItemWasMoved(
itemProvider: LazyListItemProvider,
firstItemIndex: Int
): Int = if (updateScrollPositionIfFirstItemMoved) {
scrollPosition.updateScrollPositionIfTheFirstItemWasMoved(itemProvider, firstItemIndex)
} else {
firstItemIndex
}
Repeat this for LazyGridState
so the grids also can opt-out of this behavior.
There, fixed that for you.
an...@google.com <an...@google.com> #22
ap...@google.com <ap...@google.com> #23
Branch: androidx-main
commit 517482736873b04a504e85769234e059fdbc6fe7
Author: Tyler Wasniowski <tylerjames@google.com>
Date: Fri Mar 22 18:21:37 2024
Add requestScrollToItem to LazyListState.
When requestToScroll is called, we store the last requested scroll position. During the next measure pass, we will consume the last requested scroll position, scrolling there instead of to the following the previous first visible item key. The next measure pass, unless requestToScroll is called again, will still maintain index based on the first visible item key.
Relnote: For each measure-pass, the client may now opt-out of maintaining index based on the key by calling requestToScroll. This does not change existing behavior in anyway unless requestToScroll is called.
Change-Id: I98036297fdf1bdf73125c6713fe746d71d6d94a8
Test: LazyListRequestScrollTest
Fixes: 209652366
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/LazyColumnDragAndDropDemo.kt
M compose/foundation/foundation/integration-tests/lazy-tests/src/androidTest/kotlin/androidx/compose/foundation/lazy/list/LazyCustomKeysTest.kt
A compose/foundation/foundation/integration-tests/lazy-tests/src/androidTest/kotlin/androidx/compose/foundation/lazy/list/LazyListRequestScrollTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyDsl.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyList.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyListState.kt
ap...@gmail.com <ap...@gmail.com> #24
How should I call requestScrollToItem
to completely opt-out from maintaining index based on the key? It seems it needs to be called every measure-pass.
ty...@google.com <ty...@google.com> #25
Re
Please take a look at the test cases in
And yes, it does need to be called every time after the data changes, but before the next measure pass to ensure that you always have your desired behavior. Otherwise, every time it is not called before the measure pass, it will default to the old behavior of maintaining the first visible item by key.
va...@gmail.com <va...@gmail.com> #26
The solution that has been implemented does not fully cover our use cases. We cannot know when items change as we receive them asynchronously. Also, it is too cumbersome to add this function call to every place in the code that may change the order of items. Please implement a flag that will completely disable the behavior of maintaining the first visible item.
ty...@google.com <ty...@google.com> #27
Re:
What is your use-case? Given your desire for "a flag that will completely disable the behavior of maintaining the first visible item", do I understand correctly that you would like to maintain the same index when the data changes?
va...@gmail.com <va...@gmail.com> #28
Our use case is a list of items of various types that are sorted arbitrarily by domain-level business logic. There multiple (3+) types of interactions with list items which trigger an asynchronous update of the list that the composable receives. The composable doesn't know how the index will change on each operation. The list may be reordered, items may be removed, added, put to the end or to the top of the list. As such, it is not possible to call requestScrollToItem
within a single measure pass. And yes, the requirements are such that although the list is changing, the position of the user (scroll state) should always stay the same.
to...@gmail.com <to...@gmail.com> #29
If I may talk about some basic use case is having a list sorted by date of modification or date of last played.
The user is in the middle of the list, trigger an action on an item that can be delayed, like playing or changing something via a dialog or whatever, the database change the data is refreshed the item have changed position, the list scrolls to that item.
In a few cases it's not wanted, typically the user is doing operations at the end of a list to update things on the oldest stuff and every time he's jumped at start, or he want to play oldest stuff in order and the list keeps jumping ....
ko...@gmail.com <ko...@gmail.com> #30
I'm not the OP but my use case would be a to-do list where marking the first item done should not scroll the list to the end where the checked item gets moved to upon completion. The current solution is way too cumbersome for such a basic task.
ty...@google.com <ty...@google.com> #31
Great, thanks for that detail in
Re
It sounds like your use-cases best match the test-case requestScrollToItem_withFirstVisibleIndex_firstVisibleItemMoved_staysScrolledAtSameIndex
I will give a code-snippet below to show the template for the solution to these use-cases. I will then provide some detail below the snippet on how this solution works.
val state = rememberLazyListState()
// The content is inside of its own fun, so it gets recomposed when [list] changes and
// thus also triggers SideEffect.
@Composable
fun Content(list: List<T>) {
LazyColumn(state = state) {
items(list, key = { ... }) { ... }
}
SideEffect {
state.requestScrollToItem(index = state.firstVisibleItemIndex)
}
}
Content(list = list)
The solution above uses SideEffect
Adding list: List<T>
as a parameter to a @Composable
fun
, will cause the fun
to be recomposed when the list
changes.
Since the recomposition will always happen after the data changes, but before the next measure pass, SideEffect
will be called after each data change, before the next measure pass. This will essentially fully opt-out of maintaining the scroll position based on key, and rather will maintain the currently scrolled index and offset.
Does that fully answer your questions/concerns?
to...@gmail.com <to...@gmail.com> #32
Some of us lives in the future and use immutablelists.
And how does this handle state restoration? Specially if there's a delay on the query and so initial redraw have no data, state is skipped but you force a scroll, then it's broken.
There's so many side effects and things to handle this manually that it's still more an hack than something stable that won't bite in the future.
ko...@gmail.com <ko...@gmail.com> #33
I did manage to solve this earlier with one of the test cases but the point is still that it is a very complex API for such basic use cases. There should be a flag that completely disables the auto-scrolling behavior (see
va...@gmail.com <va...@gmail.com> #34
Solution from #31 is not an acceptable one to me. You suggest to trigger a scroll operation on every recomposition, which in a complex screen will happen much more frequently than when just the list is mutated. This solution is subpar in terms of performance and honestly looks like a hack. Doesn't the compose official documentation discourage the usage of SideEffect function? Then why is this suggested as a default solution for 116+ people who upvoted this topic?
an...@google.com <an...@google.com> #35
This solution is subpar in terms of performance
In most cases recomposition of the composable containing LazyColumn
will anyway trigger remeasure for lazy column. Then calling requestScrollToItem
is not making it worse. Also remeasuring lazy column is not as expensive as you think. We basically do this operation on every frame when the list is scrolling and this operation is heavily optimized.
And how does this handle state restoration?
We are not aware of any issues related to that. requestScrollToItem called with the same index/offset shouldn't change the behavior here. Please file a separate bug if you think there is an issue.
We are not saying that we will never introduce additional api to completely switch to maintaining the scroll position by index. For now we introduced requestScrollToItem
api which is very flexible and keeping the same index is just one of many possible use cases for it. We are also slightly surprised it is considered to be so common to want to stay on the same index. This logic is not working great with reorderings. Every time there are new items added before the first visible one it is causing a visible to the user content jump.
To sum up, if you want to always stay on the same index, those are three options we can offer at the moment:
- You can use SideEffect and request scroll to the same position everytime list composable is recomposed:
@Composable
fun MyList(list: List<Int>) {
val state = rememberLazyListState()
LazyColumn(state) {
items(list, key = { it }) {
...
}
}
SideEffect {
state.requestScrollToItem(
index = state.firstVisibleItemIndex,
scrollOffset = state.firstVisibleItemScrollOffset
)
}
}
- If you don't use immutable lists and the list might be updated without recomposition then you can try this pattern.
Here we wrap it into withoutReadObservation because without that reading state.firstVisibleItemIndex or state.firstVisibleItemScrollOffset will subscribe us to each scroll position updates causing us to do unnecessary work.
val list by remember { mutableStateListOf<String>() }
val state = rememberLazyListState()
LazyColumn(state) {
Snapshot.withoutReadObservation {
state.requestScrollToItem(
index = state.firstVisibleItemIndex,
scrollOffset = state.firstVisibleItemScrollOffset
)
}
items(list, key = { it }) {
...
}
}
- If you fully control all the list modifications you can just call requestScrollToItem manually every time you change the list and want to stay on the same index. For example from the button click lambdas.
We understand that it might still look too complex for some of you and you would just expect to have something like rememberLazyListState(maintainScrollPositionByKey = false)
instead.
But we are not yet sure it is a scaleable enough API as there are many different context specific use cases, in some of them it is reasonable to stay on the same key, in others to stay on the same index, but in rare cases you might want to just end up on a completely different position after the data set change.
We will still monitor the feedback and are open to consider introducing more APIs to make common use cases simpler.
to...@gmail.com <to...@gmail.com> #36
For the state restoration the lazy have hacks to not restore with paging for example when there's no items to avoid loosing the state, it wait for at least one item present.
With the side effect and no data yet restored it will try to scroll to an item that is not yet there so will fail, so will corrupt the state or crash or will have unpredictable effect.
This is something that needs to be taken in account.
Then there's the other API that was refused but can't find back the previous issue, it's proper control of that state restoration delay, since if you have an header and a paging source, the data is still restore too early and we need to do
val emptyState = remember(lazyPagingItems.itemCount) {
LazyGridState(
firstVisibleItemIndex = lazyGridState.firstVisibleItemIndex,
firstVisibleItemScrollOffset = lazyGridState.firstVisibleItemScrollOffset,
)
}
LazyVerticalGrid(
state = if (lazyPagingItems.itemCount == 0) emptyState else lazyGridState,
)
And now we need to mix both of those and hope there's no other things that will bite us.
Another question, is what happens when a fling is running and the content is changed, if currently this is properly handled and the fling keeps going, now it will behave differently.
Lazy stuff is complex enough with many quirks to handle already, adding something ultra invasive as this kind of forced scroll will be problematic at some moment and will be insanely hard to debug.
an...@google.com <an...@google.com> #37
For the state restoration the lazy have hacks to not restore with paging for example when there's no items to avoid loosing the state, it wait for at least one item present. With the side effect and no data yet restored it will try to scroll to an item that is not yet there so will fail, so will corrupt the state or crash or will have unpredictable effect.
As I said, I expect the new requestScrollToItem() to not change this behavior. The scroll position will not be "corrupted" while we don't have any items, in the same way as it works right now. If it is not what you experience please file a separate bug.
al...@workjam.com <al...@workjam.com> #38
ty...@google.com <ty...@google.com> #39
You need a compose foundation version of
yb...@gmail.com <yb...@gmail.com> #40
I tried the solution in #35 but if there's a scroll in progress when list changes, scrolling abrubtly stops.
ty...@google.com <ty...@google.com> #41
Re
If you'd like, you can first check the LazyListState
for isScrollInProgress
yb...@gmail.com <yb...@gmail.com> #42
That's what I ended up doing as a workaround. But now when list changes, LazyList tries to maintain scroll position if scroll is in progress. So it ends up scrolling to an unexpected position. It's very rare that this creates a problem, but I would still prefer a proper fix.
fr...@gmail.com <fr...@gmail.com> #43
I've a LazyColumn with bidirectional pagination. The data is loading completely asynchronously and I don't know how many items I'll get with after a successful request.
I'm adding a ProgressIndicator in both directions while I've not reached the end (in any directions).
As I'm adding items forward the list will always auto-scroll to show the ProgressIndicator, as it has a unique key and is always the first item.
I've tried playing with requestScrollToItem() but I can't make it works properly, when inserting the data at index 0 (reverse layout) the lazyListState.firstVisibleItemIndex is always 0.
Could we have a simple api to Opt-out? even if it's not flexible, it'd help a lot...
Or if you have any idea how to manage this ProgressIndicator without messing the scrolling.
I had the same code with a RecyclerView and it was working like a charm.
Thanks.
Description
Description:
When using a LazyList with keyed items the scroll position is maintained based on the key. It would be great if there would be a way to opt out from this behavior when using keyed items.
Use Case:
I want to be able to switch the first visible item without changing the scroll position.