Status Update
Comments
de...@gmail.com <de...@gmail.com> #2
mo...@google.com <mo...@google.com>
pr...@firstup.io <pr...@firstup.io> #3
de...@gmail.com <de...@gmail.com> #4
private void refreshAllLiveData() {
AppDataBase YOUR_DATABASE_WHICH_YOU_BUILD = .....
SupportSQLiteDatabase writableDatabase = YOUR_DATABASE_WHICH_YOU_BUILD.getOpenHelper().getWritableDatabase();
//get the database count;
Cursor cursor = writableDatabase.query("SELECT count(*) FROM sqlite_master WHERE type = 'table' AND name != 'android_metadata' AND name != 'room_master_table';");
int tableCount = 0;
while(cursor.moveToNext()) {
tableCount = cursor.getInt(0);
}
for (int i = 0; i < tableCount; i++) {
//update version table with the incremented count because room modification log stores tables with ids instead of names
writableDatabase.execSQL("INSERT OR REPLACE INTO room_table_modification_log VALUES(null, "+(i)+")");
}
YOUR_DATABASE_WHICH_YOU_BUILD.getInvalidationTracker().refreshVersionsAsync();
}
-----
This is a workaroud for refreshing all live datas, I still prefer to use a proper API you implemented.
Thanx
hq...@gmail.com <hq...@gmail.com> #5
de...@gmail.com <de...@gmail.com> #6
ha...@gmail.com <ha...@gmail.com> #7
You can fix this by having different item view type's as per your need.
ry...@google.com <ry...@google.com> #8
Recycler view expects to have same height for same view type.
This is not true. There is no requirement that items of a given view type all be the same height.
ha...@gmail.com <ha...@gmail.com> #9
dm...@gmail.com <dm...@gmail.com> #10
I don't think RecyclerView has any expectations for the size of its views. It's more likely that ComposeView updates its bounds a frame later than it should, or something like that
va...@pelmorex.com <va...@pelmorex.com> #11
h9...@drdiary.co.kr <h9...@drdiary.co.kr> #12
What should I do to resolve the issue?
[Deleted User] <[Deleted User]> #13
de...@gmail.com <de...@gmail.com> #14
People are facing this issue when doing a partial migration to Compose. Is there a timeline on when this can be fixed?
se...@google.com <se...@google.com>
se...@google.com <se...@google.com> #15
We do not have a timeline on an expected fix, please continue using the workaround listed in b/240449681#5 until this is prioritized.
We have the reproducer in
If anyone is reading this and the workaround in #5 doesn't work, please post a minimal reproducer to help us better triage / fix this.
bo...@sph.com.sg <bo...@sph.com.sg> #16
I have the same issues. You can disable the recycling using holder.setIsRecyclable(false). Yes, might as well don't use recyclerview since it is not recycling but you have no choice when migrating xml to compose partially. Or you just can just rewrite everything in Compose. I filed few tickets to Google years back and never get fixed, they only focus to work on new features, fixing bugs never their priority. This should be your consideration when using Google product/services.
Description
Version used: 1.3.0-beta01
Devices/Android versions reproduced on: Pixel 6 Pro/Android 12
Sample project:
Using the latest RecyclerView beta and Compose 1.2.0, if I fill a RecyclerView with items backed by ComposeView and those views are of varying heights, the RecyclerView will noticeably jump when scrolling from the bottom of the list back to the top.
Presumably, the problem is related to when Compose determines the height of the ComposeView and when RecyclerView needs the height of the item in the list. So far, I haven't found a solution or workaround for this problem.
The linked sample project shows a simple RecyclerView with items alternating between one and two lines of text.