fix(android): fix global header/footer title in ListView

[m1ga]

Issue

I don't think it is widely used but you can add a headerTitle/footerTitle in the ListView instead of the ListSection. When I was working on the test suite PR (#14158) I saw that that test was failing.

12.6.1.GA:

The issue is that the content section has no view (as it is just the global headerTitle, so it doesn't have items) and that messes up the constraints. The "global header view" is visible as it creates a view.

Fix

As I don't know at this point which kind of headerTitle (section or global) I just check if there are views inside the content section. If not I create an empty view and add it. That will keep the constraints working

Test

<Alloy>
	<Window id="index" layout="vertical">
		<ListView id="list" headerTitle="Global Title" footerTitle="Global footer" height="Ti.UI.SIZE"/>

		<ListView id="list" height="Ti.UI.SIZE">
			<HeaderView>
				<View height="25" backgroundColor="teal">
					<Label>Global Header View</Label>
				</View>
			</HeaderView>
		</ListView>

		<ListView id="list">
			<ListSection>
				<HeaderView>
					<View height="25" backgroundColor="teal">
						<Label>Section Only Header View</Label>
					</View>
				</HeaderView>
			</ListSection>

			<ListSection headerTitle="Only header title">
				<ListItem title="Item 1" backgroundColor='pink'/>
			</ListSection>

			<!-- <ListSection footerTitle="Only footer title" backgroundColor='green'/> -->

			<ListSection>
				<ListItem title="Section item 1 : no header/footer"/>
				<ListItem title="Section item 2 : no header/footer"/>
			</ListSection>

			<ListSection>
				<HeaderView>
					<View height="50" backgroundColor="pink">
						<Label>Section with :: Header Footer View</Label>
					</View>
				</HeaderView>

				<FooterView>
					<View height="25" backgroundColor="green">
						<Label>Section with Header :: Footer View</Label>
					</View>
				</FooterView>
			</ListSection>

			<ListSection>
				<HeaderView>
					<View height="50" backgroundColor="magenta">
						<Label>Section 2 : Header View</Label>
					</View>
				</HeaderView>

				<ListItem title="Section footer/header : Item 1"/>
				<ListItem title="Section footer/header : Item 2"/>

				<FooterView>
					<View height="25" backgroundColor="orange">
						<Label>Section 2 : Footer View</Label>
					</View>
				</FooterView>
			</ListSection>

			<ListSection>
				<ListItem title="Section 3 : Item 0"/>
				<ListItem title="Section 3 : Item 1"/>
				<ListItem title="Section 3 : Item 2"/>
				<ListItem title="Section 3 : Item 3"/>
				<ListItem title="Section 3 : Item 4"/>
				<ListItem title="Section 3 : Item 5"/>
				<ListItem title="Section 3 : Item 6"/>
				<ListItem title="Section 3 : Item 7"/>
				<ListItem title="Section 3 : Item 8"/>
				<ListItem title="Section 3 : Item 9"/>
				<ListItem title="Section 3 : Item 10"/>
				<ListItem title="Section 3 : Item 11"/>
				<ListItem title="Section 3 : Item 12"/>
				<FooterView>
					<View height="25" backgroundColor="red">
						<Label>Section 3 : Footer View</Label>
					</View>
				</FooterView>
			</ListSection>
		</ListView>
	</Window>
</Alloy>

[hansemannn]

@prashantsaini1 Can you please take a look?

[prashantsaini1]

I'll take a look at it this week, but I feel this can be resolved using ConstraintLayout like we fixed other, without adding additional empty views.

[m1ga]

Keep in mind the view is only there as a fallback when you don't have any items, so a ListView with only a ListView header. As soon as you have items it will be overwritten with those anyways.

[prashantsaini1]

I have been checking it currently and found that this fix is a temporary hack. Checking further for a proper fix.

[prashantsaini1]

Found the issue:

• headerTitle/footerTitle were not delegating layout updates to their parent due to android:layout_width="0dp" when there are no ListItem cells.

Fix:

• Revert your code and set android:layout_width="wrap_content" on both headerTitle and footerTitle, and it works fine!

[m1ga]

I've tried that already. It will break the headers/footers in the example code. See:

[prashantsaini1]

If you actually meant to take over the entire width, just like in your earlier fix screenshot, then match_parent should do the job. I am testing it out right away.

[m1ga]

yes, the sections should go over the whole space. You can also checkout the listview examples in KitchenSink:

If I remove my fix and change "0dp" to wrap_content for header & title it will look like this:

and it should still look like this (12.6.1.GA):

[prashantsaini1]

Actually when we set the headerTitle and footerTitle, it should rather wrap itself than occupying the whole width. The only issue I see here is that it's in centre than on left.

[prashantsaini1]

Tried multiple stuffs, could make them render to left but not full width. These titles' TextView are being set a background which makes it wrap if we don't set its width to 0dp. With 0dp, it does not trigger layout again without your hack. So for now, we can go with this.

For long term I suggest two options:

1. We drop support for headerTitle/footerTitle in favour of HeaderView/FooterView to have complete flexibility. Titles seem too obsolete and do not take account of dark/light modes. It's just a static white colour on grey background as of now.
2. Internally create and add a Ti.UI.Label into existing HeaderView/FooterView which is already there but hidden.

[m1ga]

Sounds like a good plan 👍

As mentioned before: this is was never reported by anyone so far. I just saw this issue in the test suite as most people have items in their listviews or use headerViews (because of the reasons you've described).

[hansemannn]

@prashantsaini1 Can you please review this and approve if matching?

[prashantsaini1]

• Adding an empty View will cause issue in this case as this empty View will be added every time the cell is recycled and reused.

I have tested the proper fix today for this issue with some further improvements. Opening a new PR soon.

[prashantsaini1]

@m1ga Here is the fresh PR with all required changes. The first commit in new PR is the actual fix of the problem we discussed here.

@hansemannn cc.

[m1ga]

closing in favor of #14175