Fix icon placement for section switches #3787
Conversation
|
This is due to Faltenreich/SkeletonLayout#47 ... I wonder whether we shouldn't think about a more generic solution though. |
|
I had to create the skeleton manually in https://github.com/openhab/openhab-android/blob/main/mobile/src/main/res/layout/activity_chart.xml#L18-L22. |
Yes, but that solution is weird as well (views usually don't control their parent), and doesn't help with the fact that automagic skeleton creation is fundamentally broken (see #3786 (comment) and Faltenreich/SkeletonLayout#47). As far as I can tell, there are 3 possible solutions:
I don't really like the first option (it's a lot of effort since we have a large number of layouts, and I still find it's somewhat of a hack as mentioned above), but I'm torn between the second and the third one currently. |
The 'automagic' skeleton addition caused two issues: - Misplaced icon in section switches (openhab#3773) This was caused by constraints in the widget's ConstraintLayout referencing the WidgetImageView's ID, which was no longer present after replacing it by the SkeletonLayout - Skeleton and image shown at the same time (mentioned in openhab#3786) This was caused by WidgetAdapter and SkeletonLayout both simultaneously modifying the visibility flag of the WidgetImageView, again caused by silent replacement of WidgetImageView by SkeletonLayout Fix both issues by changing the approach: Instead of silently replacing the view, make WidgetImageView inherit from SkeletonLayout and make it redirect external calls to an internal ImageView instance. Fixes openhab#3773, openhab#3786 Signed-off-by: Danny Baumann <dannybaumann@web.de>
maniac103
force-pushed
the
sectionswitch-icon-fix
branch
from
1d1e203 to
201d492
Compare
|
Changed the approach and implemented option 2 (NB: for diff review, it's helpful to ignore whitespace changes in the diff viewer, since most part of the diff is reindention). |
This broke when WidgetImageView was changed to no longer be derived from ImageView in openhab#3787. Since WidgetImageView passes all view attributes to its internal ImageView instance, let the framework know that this is the case. Signed-off-by: Danny Baumann <dannybaumann@web.de>
This broke when WidgetImageView was changed to no longer be derived from ImageView in openhab#3787. Since WidgetImageView passes all view attributes to its internal ImageView instance, let the framework know that this is the case. Signed-off-by: Danny Baumann <dannybaumann@web.de>
This broke in openhab#3787 Fixes openhab#3802 Signed-off-by: Danny Baumann <dannybaumann@web.de>
This broke when WidgetImageView was changed to no longer be derived from ImageView in #3787. Since WidgetImageView passes all view attributes to its internal ImageView instance, let the framework know that this is the case. * Make WidgetImageView.InternalImageView.loadProgressCallback nullable It's invoked via ImageView() -> setImageDrawable() -> prepareForNonHttpImage(), at which time the initializer of loadProgressCallback hasn't run yet. Signed-off-by: Danny Baumann <dannybaumann@web.de>
Fix issues with WidgetImageView skeleton placeholder
The 'automagic' skeleton addition caused two issues:
This was caused by constraints in the widget's ConstraintLayout referencing the WidgetImageView's ID, which was no longer present after replacing it by the SkeletonLayout
This was caused by WidgetAdapter and SkeletonLayout both simultaneously modifying the visibility flag of the WidgetImageView, again caused by silent replacement of WidgetImageView by SkeletonLayout
Fix both issues by changing the approach: Instead of silently replacing the view, make WidgetImageView inherit from SkeletonLayout and make it redirect external calls to an internal ImageView instance.
Fixes #3773, #3786