Status Update
No update yet.
Comments
du...@google.com
possible dup
du...@google.com
coming back to this issue. I see this is because we just cannot really drag handle behind the screen (because the "pointer" of the handle is where we select the text, so the handle need to be out of the screen to select the last letter).
That being said, if being super careful I'm able to select the whole first word even with no padding (sometimes takes a few attempts).
Siyamed, how do you deal with this in the platform text? Frankly, I expect no text to be at the very edge of the screen in the real apps, and since it's possible to select by just raising the selection handle higher (positionning at the line above seelcted the whole line) idk how big the problem is.
Anyway, reassigning to Siyamed to investigate the selection in the platform for clues or ask someone from the text team to do it.
ti...@chainels.com
Thanks.
Can you please elaborate on the first sentence?
I see this is because we just cannot really drag handle behind the screen (because the "pointer" of the handle is where we select the text, so the handle need to be out of the screen to select the last letter).
I did not understand dragging the handle behind the screen.
du...@google.com
In the Gmail app for example (see image) the selection handle will get clipped to accommodate the selection, which is unlike what is happening here (see second image).
du...@google.com
Can you please elaborate on the first sentence?
to Siyamed: Sure. This is basically what exploringbinary showed in their screenshots. the start handle selects the text based on its top right corner (where the sharp pointer edge is), so in order to select the text near the edge of the screen we have to essentially drag the handle out of screen bounds, so it's top right corner is at 0 x axis. I recommend to explore how we handle this case in the platform.
re screenshots: interestingly enough, your screenshots have a margin for a gmail, that's why it's possible. I assume we can clip the handle as well, but it won't help to solve the
Description
Component used: Paging
Version used: 3.0 alpha-04
Devices/Android versions reproduced on: n/a
Today (after many hours of debugging) I seem to have found a bug in latest alpha version of the Paging library. In my app I still have various lists that are not yet migrated to the new v3 API's, but since the documentation states it's backward compatible I figured that was okay.
Those lists use the database + remote pattern. One such list displayed strange behavior, it seemed to call all the boundary callbacks correctly, do the API call, and insert the new items in the database, however the items in the RecyclerView did not change.
The only difference that I could find between that list and other lists that were functioning correctly, is that it used a
mapfunction on theDatasource.Factoryreturned by RoomI think I found the underlying issue. The data source does not seem to be invalidated when using a map function.
DataSourcehas two variants ofaddOnValidationCallback. An open functionThe Kotlin version is actually called in
LegacyPagingSourceHowever when using a map/mapByPage function on the factory returned by room, the source is
WrappedDataSourceWrapperPositionalDataSourcefor example) only the non Kotlin version ofaddOnValidationCallbackis overridden, and thus if called with the Kotlin version,addOnValidationCallbackis never called on the source of the wrapper.I could see when debugging that indeed
onInvalidatedCallbacksis empty.Hopefully this is actually the cause of the behavior I'm seeing. The Paging code is quite complex so I could be missing something else.