[TIMOB-14971] iOS7: Grouped TableView - First Header has wrong height

GitHub Issue	n/a
Type	Bug
Priority	Medium
Status	Closed
Resolution	Done
Resolution Date	2018-02-18T20:40:10.000+0000
Affected Version/s	Release 3.1.2
Fix Version/s	n/a
Components	iOS
Labels	Header, TableView, dev-investigate, ios7
Reporter	Thomas Neerup
Assignee	Unknown
Created	2013-08-26T07:49:10.000+0000
Updated	2018-08-06T17:34:46.000+0000

Description

*Problem* On iOS 7, when adding sections with headerTitles the first header is the wrong height. The next header is the right height. See test case. *Actual Result* The first header is to high. *Expected Result* The first header should be the same hight as the no. 2 3 4… *Test case*

<Alloy>
	<TabGroup>
		<Tab title="one" id="tabone">
			<Window backgroundColor="red" tabBarHidden="true">
				<TableView  style="Titanium.UI.iPhone.TableViewStyle.GROUPED">
					<TableViewSection  headerTitle="Header">
						<TableViewRow title="Row title" ></TableViewRow>
						<TableViewRow title="Row title"></TableViewRow>
					</TableViewSection>
					<TableViewSection headerTitle="Header">
						<TableViewRow title="Row title"></TableViewRow>
						<TableViewRow title="Row title"></TableViewRow>
					</TableViewSection>
					<TableViewSection>
						<TableViewRow title="Row title"></TableViewRow>
						<TableViewRow title="Row title"></TableViewRow>
					</TableViewSection>
				</TableView>
				<Toolbar platform="ios" bottom="0" borderTop="true" borderBottom="false">
					<Items>
						<Button id="send" title="Send" style="Ti.UI.iPhone.SystemButtonStyle.DONE" />
						<FlexSpace/>
						<Button id="camera" systemButton="Ti.UI.iPhone.SystemButton.CAMERA" />
						<FlexSpace/>
						<Button id="cancel" systemButton="Ti.UI.iPhone.SystemButton.CANCEL" />
					</Items>
				</Toolbar>
			</Window>
		</Tab>
	</TabGroup>
</Alloy>

Attachments

File	Date	Size
index.xml	2013-08-26T07:51:01.000+0000	1144
Screen Shot 2013-08-26 at 09.44.43.png	2013-08-26T07:49:11.000+0000	45409

Comments

Vishal Duggal 2013-09-03

This is not our issue but an Apple bug. On IOS7 Apple is completely ignoring the values returned from the delegates. No way to fix this for us.
Matej 2013-11-26

Hi Vishal, if this is Apple's bug why is does work in some apps? For example if you go into Settings in iPhone a then to the Wallpapers & Brightness there is normal header. I am not an Objective C developer ,but I think that problem is somewhere else... Please fix that issue. Thanks
Ingo Muschenetz 2013-11-26

Based on http://stackoverflow.com/questions/18880341/why-is-there-extra-padding-at-the-top-of-my-uitableview-with-style-uitableviewst/18935526#18935526, it seems that there is definitely a bug, but perhaps something we should provide at least a workaround to our users, as people can do so natively. Opening for re-investigation.
Vishal Duggal 2013-11-27

This is still an apple bug. Apple is not respecting values returned from delegate. Anyways for this use case try setting a dummy headerView of height 15 if(ios7 && grouped){ var dummyView = Ti.UI.createView({height:15}) tableView.headerView=dummyView; }
Justin Toth 2014-01-15

Apple bug or not, this shouldn't have been resolved, the issue still exists and the work-around doesn't work. One of the many solutions in the SO thread should be exposed to us, otherwise each of us has to create a custom iOS module to resolve this, which isn't good for something as basic as standard tableview usage.

Sabil Rahim 2014-01-21

The suggested solution by Vishal works. Please try the code posted below. This in fact is a Apple bug if try returning a value zero as the headerView height apple seems to not like it and opts to set a larger height.

   
   function isiOS7Plus()
   {
   	// iOS-specific test
   	if (Titanium.Platform.name == 'iPhone OS')
   	{
   		var version = Titanium.Platform.version.split(".");
   		var major = parseInt(version[0],10);
   
   		// Can only test this support on a 3.2+ device
   		if (major >= 7)
   		{
   			return true;
   		}
   	}
   	return false;
   }
   
   var win = Titanium.UI.createWindow({
   	title : "_args.title"
   });
   
   
   var inputData = [{
   	title : 'row 1',
   	header : 'Header 1'
   }, {
   	title : 'row 2'
   }, {
   	title : 'row 3'
   }, {
   	title : 'row 4',
   	header : 'Header 2'
   }, {
   	title : 'row 5'
   }]; 
   
   var tableView = Titanium.UI.createTableView();
   
   tableView.style = Titanium.UI.iPhone.TableViewStyle.GROUPED;
   
   
   var iOS7 = isiOS7Plus();
   
   if (iOS7 ) {
   	var dummyView = Ti.UI.createView({
   		height : 15
   	});
   	tableView.headerView = dummyView;
   }
   tableView.data = inputData;
   win.add(tableView);
   win.open();

Justin Toth 2014-01-21

Most real-world apps will be using the navigation window, so if you use the headerView height of 15 trick than it'll have 15 pixels of space between the top header and the first row of the table view. The best you can do is change the headerView height to 1, which will create 1 pixel of space between the header and the first row, which isn't perfect but doesn't look that bad. Also, even with this fix there is still a lot of padding at the bottom of the table view. I haven't tried adding a footerView with a height of 1 to see if that fixes it or not. It begs the question though of whether you want everyone building a Titanium app with a grouped table view to have to write the code above, modified to either set the headerView height to 15 or 1 (depending on if they're using a navigation window or not), and to handle the footer padding issue. It's not that intuitive to think if you have all of this tableview padding at the top and bottom that you need to set custom headerViews and footerViews, so you'll then be relying on people finding this ticket with the work-around. It seems like something that would be better resolved at the platform level to save developers from having to find this ticket and implement the code above. Just my two cents...
Matej 2014-02-18

For even smaller - no gap use height: 0.1
Unknown 2014-04-21

This issue was previously scheduled to be worked on in more than one sprint: * 'Release 3.1.2' (on board '3.1.X Triage') * 'Release 3.0.1/TS 3.0.2' (on board '3.1.0 Triage') * 'Investigate' (on board '3.2.X Triage') Starting from JIRA Agile 6.3, an issue can only belong to a single future sprint. Read more about this change: http://docs.atlassian.com/agile/docs-0630/Sprint+Marker+Migration This issue is now scheduled for future sprint 'Release 3.1.2' (on board '3.1.X Triage'). If this is incorrect, please update the issue accordingly. This comment was automatically generated by JIRA. If it is no longer relevant, please feel free to delete it.
Hans Knöchel 2018-02-18

Not an issue anymore these days, resolving ticket.
Eric Merriman 2018-08-06

Closed as completed. If this is in error, please reopen.

JSON Source