Status Update
No update yet.
Comments
ma...@google.com
sg...@google.com
Hello, can you please attach a sample that reproduces your error?
ke...@kraken.tech
I’ve attached two screen recordings demonstrating the mediator's behavior during the first and second launches after installation. Additionally,
ro...@t-online.de
Based on first_launch_after_installation.mp4, your paging state is indeed showing null for nextKey, so it makes sense that Paging concluded there are no more items to load.
So I think the question is why the PagingState contains only an empty page and null values. My guess is either
- RemoteMediator REFRESH actually returned empty data - what is the returned
allNewsItemsvalue on initial REFRESH? - RemoteMediator REFRESH successfully loaded data and inserted it into database, but Paging hasn't processed that yet by the time Append is triggered, so PagingState is empty.
The second case doesn't seem likely though.
If you attach an executable app, I can look into this further.
Otherwise, you may gain more insight through Paging logs with adb shell setprop log.tag.Paging VERBOSE. You can also try implementing RemoteKeys in this
ke...@kraken.tech
Hey! I ran into this same issue. It is in fact the second case you mentioned and is documented
I've published a repo
Description
Description:
In both the legacy dialog fragment
MaterialDatePicker, and now the ComposeUi implementation of aDatePicker, time has been operated on via UTC millisecond timestamps. Within these components the UTC timestamps are localized to the end user via the current system TimeZone.For example, the composable
DatePickerhas a hard dependency on the system timezone in this call toLocalDate.now()The hard dependency on the system timezone is restricting to consumers of these components who expect to display localized datetimes outside of the timezone an end user is currently located in.
An ideal solution would be to make the currently experimental
DatePickeroperate on aLocalDateorLocalDateTime. Alternatively passing in a desired TimeZone to localize UTC timestamps in would suffice, but is less than ideal.Use Case:
The consumers of our application will perform time-related operations for timezones which they are not currently located in. For example, I am currently located in
America/New_Yorkbut it is expected that I would be able to perform datetime operations (like choosing a date in a picker) for the timezonePacific/Auckland. For this reason we have a pattern of localizing allInstants in our application to a local variant before we render that information to the end user.Since the time difference between the
America/New_YorkandPacific/Aucklandtimezones is 18 hours, our picker has the potential to nearly always be off by one day if using the system time zone.