Bug 25887 - [iOS] Height of Relative Layout/Listview wrong when ListView resides within a Relative Layout
Summary: [iOS] Height of Relative Layout/Listview wrong when ListView resides within a...
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.3.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2015-01-09 13:41 UTC by Dominic N [MSFT]
Modified: 2015-01-19 08:18 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Sample project from customer (146.75 KB, application/zip)
2015-01-09 13:41 UTC, Dominic N [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Dominic N [MSFT] 2015-01-09 13:41:24 UTC
Created attachment 9304 [details]
Sample project from customer

## Overview:

I have a report from a priority customer that recently upgraded their project from Xamarin.Forms 1.2 to Xamarin.Forms 1.3 and faced one issue.

When a ListView resides inside a Relative Layout, the height of this Relative Layout/Listview is not as expected. The customer indicates that this problem shows in iOS and WP8. I have verified the discrepancy between Android and iOS and can confirm that this difference exists in Xamarin.Forms 1.3.

The customer also indicated that in Forms 1.2 there was a workaround to the issue: adding padding to the bottom of the parent StackLayout allowed the view to be fixed. However, this does not work in Xamarin.Forms 1.3.

## Steps to reproduce:

1. Download sample app
2. Run both iOS and Android versions using Forms 1.3
3. Note differences

## Expected results:

Both iOS and Android behave in the same manner, sizing as indicated.

## Actual results:

iOS ListView takes up entire page.
Comment 2 Jason Smith [MSFT] 2015-01-12 14:20:18 UTC
This issue wont be fixed, the way ListView/TableView measure is dependent on the platform implementation. To get a reliable layout in a RelativeLayout either constrain the height or give it a HeightRequest.
Comment 3 Dominic N [MSFT] 2015-01-12 14:58:41 UTC

My apologies on this one. I'm reopening this as it looks like I missed the actual issue the customer was inquiring about (though the information above is quite helpful, thanks!). He contacted me recently to inform me of this.

According to the customer, the actual result is:

## Actual result:

The ListView drops of the page. The last items in the list are not visible on the screen. I've rerun the sample and can confirm this.

The expected result, of course, should be that the last item on the list does not drop off the visible page.

Comment 4 Jason Smith [MSFT] 2015-01-18 04:06:56 UTC
Dont use a relativeLayout like this. They provided no constraints so it simply gave the ListView a layout which was its desired size regardless of the parent size. Thats what a relative layout will do without any constraints applied.

Instead of a relative layout here you probably just want to pack the ListView into a ContentView or directly as the Content of the page.
Comment 5 Nicolas Hotterbeekx 2015-01-19 08:18:37 UTC

Thanks for the feedback, but then again, how do you overlay the listview with a message that extra items are loading?
The only way I know this is done, is by using a relative-layout.
It is a real bummer that XF1.3 is not backward compatible with XF1.2.