Skip to content
This repository has been archived by the owner on Jan 10, 2024. It is now read-only.

[BUG] ImageView of NewsViewCardHolder assigned to wrong news #1597

Open
kunzef opened this issue Jul 12, 2023 · 0 comments
Open

[BUG] ImageView of NewsViewCardHolder assigned to wrong news #1597

kunzef opened this issue Jul 12, 2023 · 0 comments
Labels

Comments

@kunzef
Copy link
Contributor

kunzef commented Jul 12, 2023

Describe the bug
In a certain state the startpage of the application hides the image of NewsCard while it should been shown. If the startpage is in said state the image gets hidden when refreshing or clicking Restore cards. It is show again when refreshing or clicking Restore cards. a second time. This repeats infinte times meaning every second refresh the image of the NewsCard is not shown.

To Reproduce
Steps to reproduce the behavior:

  1. On the startpage drag one of the news elements to a different position
  2. Click on Restore cards
  3. Click again on Restore cards or refresh the startpage
  4. See error

Expected behavior
The image view should always be shown when there is an image.

Suspected cause
I was only able to cause this bug when changing the order of the cards on the startpage. After this change and a reset to the initial positions the bug appears. After digging a bit deeper I discovered that one can "reverse" the bug. Meaning to change the initial visibility of the ImageView of the NewsCard to gone in the card_news_item.xml and only displaying the ImageView if there is an image included in the news. See below for the changed code in NewsViewHolder.kt.

if (imageUrl.isNotEmpty()) {
    imageView?.visibility = VISIBLE
    loadNewsImage(imageUrl)
} else {
    //imageView?.visibility = GONE
}

Doing these changes leads to the bug being "reversed" meaning that now the news without an image has one. See screenshots for a visual representation.
I also did some logging to further nail down the cause of the issue. The logs can be found under Logs in this issue. The logger has been added to the bindNews function of the NewsViewHolder.kt. It logs the uniqueDrawingId of the ImageView as well as the title of the NewsIte. See this code: Utils.logWithTag("VError", "${imageView?.uniqueDrawingId} + ${newsItem.title}"). We can see that in the inital state there are two DrawingIds for each news that change when clicking Restore cards or refreshing. But these DrawingIds always stay with the same news. For simplicity I only included three cycles but the pattern repeats in infinity. But if we now change the order of the cards and then reset them to the originial positions we can see that although the same DrawingIds are used they are now on every second refresh/restore assigned to the wrong news. This means that the ImageView associated with the news is wrong. The ImageView only seems to be wronlgy assigned on a "layout" level as the ImageView I can access in the code of the App is always the correct one. I suspect the reason for this is some error in the assignment of the ViewHolder to the NewsCard which is done incorrectly in the CardAdapter or somewhere else. This would also explain why in either scenario only one NewsCard is incorrect as for the normal bug the ImageView of the news without image is hidden programmaticly and for the reversed bug the ImageView of the news with the image is set to visible and loaded programmaticly.

Screenshots

Normal bug (hidden ImageView) Reversed bug (shown ImageView)
WhatsApp Image 2023-07-12 at 16 24 19 (1) WhatsApp Image 2023-07-12 at 16 24 19

Logs
Before chaning order/position of the cards.

2023-07-12 14:27:53.906 16200-16200 VError                  de.tum.in.tumcampus                  V  209 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:27:53.924 16200-16200 VError                  de.tum.in.tumcampus                  V  221 + Fachschaft Kompakt (01/2023)
Restored cards
2023-07-12 14:27:58.537 16200-16200 VError                  de.tum.in.tumcampus                  V  342 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:27:58.548 16200-16200 VError                  de.tum.in.tumcampus                  V  351 + Fachschaft Kompakt (01/2023)
Restored cards
2023-07-12 14:28:00.781 16200-16200 VError                  de.tum.in.tumcampus                  V  209 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:28:00.789 16200-16200 VError                  de.tum.in.tumcampus                  V  221 + Fachschaft Kompakt (01/2023)
Restored cards
2023-07-12 14:28:03.131 16200-16200 VError                  de.tum.in.tumcampus                  V  342 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:28:03.137 16200-16200 VError                  de.tum.in.tumcampus                  V  351 + Fachschaft Kompakt (01/2023)

After changing order/position of the cards.

Restore cards
2023-07-12 14:30:44.935 16200-16200 VError                  de.tum.in.tumcampus                  V  342 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:30:44.942 16200-16200 VError                  de.tum.in.tumcampus                  V  351 + Fachschaft Kompakt (01/2023)
Restore cards
2023-07-12 14:30:49.632 16200-16200 VError                  de.tum.in.tumcampus                  V  221 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:30:49.638 16200-16200 VError                  de.tum.in.tumcampus                  V  209 + Fachschaft Kompakt (01/2023)
Restore cards
2023-07-12 14:30:57.354 16200-16200 VError                  de.tum.in.tumcampus                  V  342 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:30:57.364 16200-16200 VError                  de.tum.in.tumcampus                  V  351 + Fachschaft Kompakt (01/2023)
Restore cards
2023-07-12 14:31:05.836 16200-16200 VError                  de.tum.in.tumcampus                  V  221 + Commonroad Motion Planning Competition for Autonomous Vehicles
2023-07-12 14:31:05.846 16200-16200 VError                  de.tum.in.tumcampus                  V  209 + Fachschaft Kompakt (01/2023)

Smartphone (please complete the following information):

  • Phone: Pixel 6
  • OS version: 13
  • Language: German

Remarks
For the specific case with the NewsCard it is possible to surpress the bug by adding an extra call to set the visibility to visible for a NewsCard that should have an image. This uses the always correct reference in the code to override the incorrect reference on the "layout" level. See this commit for details.

@kunzef kunzef changed the title [BUG] [BUG] ImageView of NewsViewCardHolder assigned to wrong news Jul 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant