Fixed
Status Update
Comments
te...@gmail.com <te...@gmail.com> #2
ad...@google.com <ad...@google.com> #3
> We accept pull requests! :)
Is there a public repo somewhere? I don't see any obvious repo for it inhttps://android.googlesource.com , and it doesn't seem to be inside https://android.googlesource.com/platform/frameworks/support .
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
Is there a public repo somewhere? I don't see any obvious repo for it in
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
ph...@gmail.com <ph...@gmail.com> #4
Room supports immutability (it can use arg constructors) but does not directly support AutoValue. It is in the schedule but not high priority :/. Idk much about its internals at this stage so I'm not sure how we would implement it but should be totally doable.
Sorry we don't have the source release yet :/.
Sorry we don't have the source release yet :/.
ph...@gmail.com <ph...@gmail.com> #5
"It is in the schedule but not high priority" -- completely understandable.
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
ph...@gmail.com <ph...@gmail.com> #6
Add autovalue support also means you can easily achieve parcelable by https://github.com/rharter/auto-value-parcel . Please consider support this.
sh...@google.com <sh...@google.com> #7
AutoValue is really a handy way to ensure data integrity.
ad...@google.com <ad...@google.com> #8
Please add AutoValue support. AutoValue is a Google library with really good benefits such as toString() , hashCode() , AutoValue.Builder , checks at creation time if @NonNull values are null, etc.
vi...@google.com <vi...@google.com> #9
FWIW, issue 64206877 is not publicly accessible.
vg...@gmail.com <vg...@gmail.com> #10
@Yigit: That appears to be a private ticket. Any way we can have access to keep up with it?
vi...@google.com <vi...@google.com> #11
Have any updates?
vi...@google.com <vi...@google.com> #12
news?
vi...@google.com <vi...@google.com> #13
Is there any update? This is huge for app that absolutely enforces immutable entities.
fi...@google.com <fi...@google.com> #14
SqlDelight has out of the box support for AutoValue. Use it with SqlBrite and you've got *pretty good* parity with Room. With the lack of movement on this ticket, I'd suggest at least taking a look at those if AutoValue is important to you.
an...@lifesense.com <an...@lifesense.com> #15
Support on olways
ap...@google.com <ap...@google.com> #16
Sorry this used to be higher priority but other features got in the way (and to be honest, androidX migration took a lot more time than we thought).
I want to make 1 thing clear though, Room does support immutable entities. One of the reasons why this ticket lost some priority is that it is specific to AutoValue, not immutability. If you are using Kotlin, data classes give you the same power and Room supports them properly. (hence, there is an easy way to achieve immutability w/ Room).
The issue in this one is that we don't have out of the box support to discover AutoValue builders.
We still plan to do this, sorry that it is taking longer than we initially communicated.
I want to make 1 thing clear though, Room does support immutable entities. One of the reasons why this ticket lost some priority is that it is specific to AutoValue, not immutability. If you are using Kotlin, data classes give you the same power and Room supports them properly. (hence, there is an easy way to achieve immutability w/ Room).
The issue in this one is that we don't have out of the box support to discover AutoValue builders.
We still plan to do this, sorry that it is taking longer than we initially communicated.
ap...@google.com <ap...@google.com> #17
I'd like to piggy back onto this issue, because I've fun into a similar problem with immutability that does NOT involve autovalue. What I have found is either a bug or a missing feature, depending on your perspective.
Let's say I have a Kotlin data class with only `val` properties. I want to serialize this into my Room database, but I want to decorate it with a few other values, for example a timestamp so I know when it was last updated, and a userId because my database supports multiple users. Oh look! There's an annotation `@Embedded` that seems to do just want I want. I can create a new class specific to Room persistence, add the few new properties I want, and then "embed" the original object, and damn that was easy.
Oh no. Now my project won't compile. It seems that embedded objects must have public getters -- all my `val`s must now be `var`s. D:
Sigh. I guess I'll just write a new class that has _all_ the properties of the original, plus a few more, and write an extension function to transform from one to the other. Really glad Room saved me all that Sqlite boilerplate, so I now have time for Room-specific boilerplate ;-)
Let's say I have a Kotlin data class with only `val` properties. I want to serialize this into my Room database, but I want to decorate it with a few other values, for example a timestamp so I know when it was last updated, and a userId because my database supports multiple users. Oh look! There's an annotation `@Embedded` that seems to do just want I want. I can create a new class specific to Room persistence, add the few new properties I want, and then "embed" the original object, and damn that was easy.
Oh no. Now my project won't compile. It seems that embedded objects must have public getters -- all my `val`s must now be `var`s. D:
Sigh. I guess I'll just write a new class that has _all_ the properties of the original, plus a few more, and write an extension function to transform from one to the other. Really glad Room saved me all that Sqlite boilerplate, so I now have time for Room-specific boilerplate ;-)
ap...@google.com <ap...@google.com> #18
*public setters, not public getters
ap...@google.com <ap...@google.com> #19
#17 seems like a bug, we are supposed to handle Embedded fields in constructor parameters.
Can you file a bug with a sample project ?
We do have a test for having embedded as a constructor parameter, so maybe something else is wrong.
from one of our tests:
@Entity(tableName = "fc")
static class FullConstructor {
@PrimaryKey
public final int a;
public final int b;
@Embedded
public final MyEmbedded embedded;
FullConstructor(int a, int b, MyEmbedded embedded) {
this.a = a;
this.b = b;
this.embedded = embedded;
}
}
Can you file a bug with a sample project ?
We do have a test for having embedded as a constructor parameter, so maybe something else is wrong.
from one of our tests:
@Entity(tableName = "fc")
static class FullConstructor {
@PrimaryKey
public final int a;
public final int b;
@Embedded
public final MyEmbedded embedded;
FullConstructor(int a, int b, MyEmbedded embedded) {
this.a = a;
this.b = b;
this.embedded = embedded;
}
}
Description
NOTE: The device resolution is important because the number of elements visible and the number of elements added to the RecyclerView is specific. Please run this on an emulator of 1080x1920 (confirmed on Pixel API 27 and Nexus 5 API 25).
Repro steps:
1. Create an emulator with 1080x1920.
2. Launch the StaggeredBug sample on the emulator.
3. Click the button at the bottom of the view.
Callstack:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 13
at java.util.Arrays.rangeCheck(Arrays.java:1598)
at java.util.Arrays.fill(Arrays.java:2928)
at androidx.recyclerview.widget.StaggeredGridLayoutManager$LazySpanLookup.invalidateAfter(StaggeredGridLayoutManager.java:2878)
at androidx.recyclerview.widget.StaggeredGridLayoutManager.handleUpdate(StaggeredGridLayoutManager.java:1550)
at androidx.recyclerview.widget.StaggeredGridLayoutManager.onItemsUpdated(StaggeredGridLayoutManager.java:1526)
at androidx.recyclerview.widget.RecyclerView$6.dispatchUpdate(RecyclerView.java:1016)
at androidx.recyclerview.widget.RecyclerView$6.onDispatchSecondPass(RecyclerView.java:1027)
at androidx.recyclerview.widget.AdapterHelper.consumePostponedUpdates(AdapterHelper.java:121)
at androidx.recyclerview.widget.AdapterHelper.consumeUpdatesInOnePass(AdapterHelper.java:557)
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:3918)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView.java:3641)
at androidx.recyclerview.widget.RecyclerView.onLayout(RecyclerView.java:4194)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1741)
at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1585)
at android.widget.LinearLayout.onLayout(LinearLayout.java:1494)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323)
at android.widget.FrameLayout.onLayout(FrameLayout.java:261)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at androidx.appcompat.widget.ActionBarOverlayLayout.onLayout(ActionBarOverlayLayout.java:444)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323)
at android.widget.FrameLayout.onLayout(FrameLayout.java:261)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1741)
at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1585)
at android.widget.LinearLayout.onLayout(LinearLayout.java:1494)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323)
at android.widget.FrameLayout.onLayout(FrameLayout.java:261)
at com.android.internal.policy.DecorView.onLayout(DecorView.java:726)
at android.view.View.layout(View.java:17637)
at android.view.ViewGroup.layout(ViewGroup.java:5575)
at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:2346)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2068)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1254)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6337)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:874)
at android.view.Choreographer.doCallbacks(Choreographer.java:686)
at android.view.Choreographer.doFrame(Choreographer.java:621)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:860)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
Application terminated.
It seems like the call to ensureSize(positionStart + itemCount) in offsetForAddition isn't correct; maybe something like ensureSize(mFullSpanItems.size() + itemCount)?
To describe what's happening in the sample, clicking the button adds a chunk of elements to the ListAdapter but also modifies an existing element. The real-world use case is a list of category headers which expand when clicked. After applying the two changes to the adapter, the DiffUtil is creating two ops of [ADD, UPDATE]. The ADD operation modifies mFullSpanItems.mPosition to be something like [1, 2, 3, 4, 5, 11, 12, 13, 14]. The op also tries to ensure that mData is large enough but instead does nothing. The UPDATE op then does an array copy by utilizing the mPosition values from the previous op. These mPosition values are outside the bounds of the array.