Whiplash

EricGroverEricGrover USMember ✭✭

So I just discovered from Xamarin that the way that Grid layouts work changed in XForms 1.2.x. Previously, if you did not specify a column definition for a single column grid, it would behave like MSFT SL/WPF/WinStore apps and it would take up the width of it's parent container. Now, it will default to "Auto", and will only take up the width of it's content. This makes the "Star" width in a child grid useless in that case.

This new "feature" apparently is not a bug, but is here to stay.

It would have been nice at the very least for Xamarin to have announced this decision, rather than just dumping it out there for people to find.

Posts

  • adamkempadamkemp USInsider, Developer Group Leader mod

    Do you have a link to Xamarin making that statement?

    It seems like a really bad idea for something as basic as Grid to not work like it does on other XAML platforms. That will make both porting and learning the platform significantly harder than it should be.

  • TMainTMain USMember ✭✭

    Yeah, I discovered this too with 1.2.1. It really screws up my layout and setting a single column width to Star does nothing to change it to expected behavior.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    That's even more disturbing because it conflicts with the resolution of this bug that I reported: https://bugzilla.xamarin.com/show_bug.cgi?id=21268

    In that bug I noted that a Grid with a single column didn't fill properly, and you had to fix it by adding a second column with 0 width. That bug was reported as fixed. I also noted that I expected the same behavior even without adding a column explicitly, but it wasn't clear whether they changed that behavior at the time.

    Now it sounds like possibly the entire behavior has regressed?

  • rmarinhormarinho PTMember, Insider, Beta Xamurai

    yap Grid isn't a easy one, but im seeing some progress, i also faced some grid issues, by trial and error, i found out that the default is width is auto, so no stretch.. but it works as expected if u specify one column with star for width.
    Before it didn't work as expected on MS , most of the times the items weren't expanding even with one row.. in this last version seems to work.

  • EricGroverEricGrover USMember ✭✭

    @TMain‌ Setting a column definition with a width of "Star" on my parent grids actually did fix my issues. I don't want to beat up on the Xamarin guys too much, after all, this tech really is pretty amazing. I just wish they would stop making breaking changes that require me to go back and recode pages that I thought were "done". :-)

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    @EricGrover: as said in the discussion on bugzilla, the default mode for columns/rows hasn't changed, and it's still "Auto". What changed is the way the grid does it's size request when it contains '*' elements. the previous behavior was a bug, and the requested size was bigger than expected. This was causing real layout bugs at other places. With the change, the grid now requests the size it actually needs, but will expand to the size it's been given by the parent during the layout phase.

    I understand the frustration of having to change your pages, it's unfortunate that you were relying of this as a feature, when it was in fact a bug.

  • EricGroverEricGrover USMember ✭✭
    edited July 2014

    @StephaneDelcroix‌ I guess I really don't understand the nature of the "bug", but what I know is that the way I had built my grids previously would have worked correctly in Silverlight/WPF/WinStore XAML. It also used to work correctly in XForms XAML. The fact that the fix to whatever bug existed now causes XForms grids to work differently than Grids in other kinds of XAML is unfortunate.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    @EricGrover‌ and @StephaneDelcroix‌, I'm getting confused now. I want to make sure that we are expecting the same behavior. How would you expect this to render?

    <Grid BackgroundColor="Blue">
        <Grid BackgroundColor="Red" />
    </Grid>
    

    Do you see blue or red or neither? On WPF you see red. It acts the same as this:

    <Grid BackgroundColor="Blue">
        <Grid.RowDefinitions>
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Grid BackgroundColor="Red" />
    </Grid>
    

    In the stable release of Xamarin.Forms (1.2.1.6229) as well as the current pre-release (1.2.2.6240-pre2) the grid doesn't make its children fill unless you explicitly tell them to (by writing the second version). You see a screen of blue instead of a screen of red. That's incorrect behavior if you consider the WPF behavior to be correct (which I do).

    It looks like they fixed the bug I reported earlier (that you have to add a second column to make it fill), but it still isn't behaving correctly when you leave out the row and column definitions entirely.

  • EricMaupinEricMaupin USXamarin Team Xamurai
    edited July 2014

    I guess I really don't understand the nature of the "bug", but what I know is that the way I had built my grids previously would have worked correctly in Silverlight/WPF/WinStore XAML

    Do you see blue or red or neither? On WPF you see red. It acts the same as this:

    That's incorrect behavior if you consider the WPF behavior to be correct (which I do).

    We are not a WPF clone and we have not stated any expectation of compatibility with WPF. Our grid's default row and column default to Auto, rather than *. Whether or not you agree with the decision, it's what we have, and changing it now would break anyone depending on what XF has defined as the correct behavior. I realize this might seem hypocritical (given the bug fix that changed it for you), but understand that 'Auto' has always been the default, this did not change with 1.2. The bug that gave you the *-like behavior prevented Grid from working in some scenarios regardless of how you used it. It's unfortunate that it broke some users, but it had to be fixed.

    We don't make breaking changes lightly and we'll strive to be clearer when we do.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    We are not a WPF clone and we have not stated any expectation of compatibility with WPF.

    I don't expect a total clone of WPF, but I do expect very similar elements to behave very similarly. In XAML it is extremely common to wrap things in a Grid to make them fill when they normally wouldn't, and this behavior defies that expectation. It is an impediment to adoption and it makes the tool harder to use.

    I don't like breaking things either, but this product is still young, and things break all the time anyway (you know it's true!). Now is the time to fix this mistake. A one-time pain point to fix the problem is better than a bad decision that will haunt the product forever. Making the default Auto instead of * was and is a bad decision.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    So I don't want to get stuck in a protracted conversation about this, but i do want to give you some clarity on our process on how we handle these issues.

    How we look through bugs

    First when we get a bug report we try to determine if it actually is a bug at all. This is not as easy as you might expect. Often time bug reports are about cases that are not strictly bugs but rather users not understanding the way the api is meant to work. Worse still the understanding of how the API should work is usually heavily shaded by if the developer is more experienced in Android or iOS or WPF. So in the context of the original issue, we are seeing an expansion measure behavior in grid, when it wasn't intended or specified in the API. This resulted in Auto looking like * in some cases (which is why @EricGrover thought it was *).

    Regardless of whether or not you agree with the default, we can at least agree that this was a layout bug as the layout was specified. So we fixed the bug.

    Sure but is it a behavioral change?

    Well yes it is in a sense. But its a change from unintended behavior to intended behavior. In the same way fixing the bug on android (coming in 1.2.2-pre3) that causes ToolbarItems applied to a navigationPage directly not to show up is also a behavioral change. If someone was intentionally doing that to hide toolbar items, we would break them.

    So when fixing bugs, we try not to make behavioral changes unless the behavior we are changing was never intended by us.

    Switching from Auto to *

    We have already admitted that internally this was a mistake. However we intended the Auto when we released it, so changing the default would not be an acceptable change as its not strictly speaking a bug. Does it suck? Yes a bit. Is it a bug? No.

    So what can we do?

    Well there are a couple options we can do.

    1) Obsolete Grid and make a new layout named similarly to Grid which has this behavior change.
    2) Change grid and ship a breaking change. This will probably generate a fair amount of backlash. (look at the backlash we get for fixing what is clearly a bug)
    3) Add some kind of API to change the global default.

    We're not sure what to do at this time. #2 could happen for a 2.0 release, but obviously we are nowhere near that. The others feel like shitty things to do.

    Anyhow I hope this helps you understand the process we are going through.

    Jason

  • EricGroverEricGrover USMember ✭✭

    @JasonASmith‌ Thanks for the clarification. I personally don't care which direction you go. I know from now on to just be explicit about all of my row and column definitions for every grid, then I don't have to worry about it.

Sign In or Register to comment.