Fixed
Status Update
Comments
sk...@gmail.com <sk...@gmail.com> #2
Thanks for the thorough report - you're right about the problem, and the workaround looks good - it even handles the fast cases for initialization and setList(null) nicely.
Fix and tests submitted internally, should go out with next paging release.
Fix and tests submitted internally, should go out with next paging release.
yb...@google.com <yb...@google.com> #3
Actually, I'd like to know more about what failed here and why.
I'm curious if InstantTaskExecutorRule is putting paging into an unexpected state - do you have a sample project that reproduces the issue?
When hitting this outside of a test, are you specifying any custom executors, possibly ones which run main thread tasks immediately instead of posting them?
I'm curious if InstantTaskExecutorRule is putting paging into an unexpected state - do you have a sample project that reproduces the issue?
When hitting this outside of a test, are you specifying any custom executors, possibly ones which run main thread tasks immediately instead of posting them?
yb...@google.com <yb...@google.com> #4
I don't have a sample project that hits this.
The problem does not happen very often outside of the test scripts, but we are not running any custom executors. The PagedListAdapter gets the data through a LivePagedListProvider from room db.
The problem does not happen very often outside of the test scripts, but we are not running any custom executors. The PagedListAdapter gets the data through a LivePagedListProvider from room db.
sk...@gmail.com <sk...@gmail.com> #5
This specific issue should be fixed with the Paging Alpha 4 that just released.
Filedhttps://issuetracker.google.com/issues/70351983 to track testing around InstantTaskExecutorRule.
Filed
Description
Version used: 1.1.0-alpha1
Devices/Android versions reproduced on: Compiled with API 27
This worked with Room 1.0.0, but now fails probably because it doesn't look past the first constructor when searching for one to use.
```
data class MyComplexClass @JvmOverloads constructor(
@field:Relation(parentColumn = "uid", entityColumn = "uid", entity = OtherThing::class)
var otherThings: Set<OtherThing> = setOf(),
@field:Embedded
val mainThing: MainThing)
```
Now it fails the build with `Error:(70, 2) error: Fields annotated with @Relation cannot be constructor parameters. These values are fetched after the object is constructed.` even though there is a valid constructor that only accepts a `MainThing` object and a valid setter that sets the `@Relation` field.