Forum Xamarin.Forms

Xamarin.Forms 1.2.3 Prerelease 3 out

TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai
edited September 2014 in Xamarin.Forms

Get it on Nuget!

Important Note

Xamarin.Forms 1.3 will be changing the default behavior for a Grid. The default Column/RowDefinitions will be changed from Auto to Star. This is in line with about a million bug reports requesting this, user voice, and should better meet your expectations. If you are depending on the current behavior please add code to your project now to set the Row/Column definitions to Auto.

We will be putting out several pre-releases with this change so you have time to adapt.

Bug Fixes

  • [iOS] Editor.Focus now works correctly
  • [iOS] Editor.UnFocus now works correctly
  • [iOS] Editor.IsEnabled now properly disables editing
  • [iOS] Fix crash introduced in 1.2.3-pre2 when navigating using MasterDetailPage
  • [iOS] Fix memory leak when changing pages using Master pane in MasterDetailPage
  • [iOS] Secondary toolbar items will now clear properly and are sorted correctly
  • [Android] SwitchRenderer no longer causes crashing with Navigation
  • [Android] ListView selected background color now properly cleared
  • [Android] Image loading reset on ImageCell
  • [Android] Fix edge case where images were not loaded asynchronously in ListView
  • [Android] Images no longer trigger useless layout cycle when re-used in ListView
  • [Android] Minor ListView performance improvements
  • [WinPhone] Switch.IsEnabled property now works correctly
  • [WinPhone] Secondary toolbar items no longer occasionally duplicate themselves

Prerelease 2 Notes

Important Notes

In this release we have changed the base class of EntryRenderer from a ViewRenderer<Entry, Canvas> to a ViewRenderer<Entry, Grid> on Windows Phone. While it is unlikely anyone depends on this behavior, if you do you will need to update your code.

Bug Fixes

  • [Android] ListView background color will no longer throw a NotFoundException in some cases
  • [Android] Fix a GREF leak when dismissing keyboard (performance and memory leak)
  • [Android] Keyboard now properly hides when calling Entry.Unfocus
  • [WinPhone] MapRenderer is now public
  • [WinPhone] Calling Picker.Items.Clear no longer crashes
  • [WinPhone] Entry's inside of a ViewCell will no longer incorrectly horizontally minimize
  • [WinPhone] Add support for ApplicationId and AuthToken to FormsMaps.Init (string, string), old overload remains for testing
  • [iOS] MapRenderer is now public
  • [iOS] ScrollView will no longer exceed its bounds (extension of previous fix to include more cases)
  • [iOS] Resolve a major memory leak when popping pages from Navigation stack
  • [Xaml] Fix error when saving xaml file in Xamarin Studio on Windows where the file is locked by another process

Prerelease 1 Notes


This release contains a new dll used to speed up JNI bridge invocation for Android. This is the first public release with this faster bridge.


  • [Android] ListView performance increase. Especially when dealing with lots of labels or nested layouts.

Bug Fixes

  • [All] Entry no longer clears one way bindings when the user enters text
  • [Core] BindableObject.ClearValue now properly triggers INPC
  • [Android] ScrollView will no longer crash when inside of a ViewCell
  • [Android] ListView background and divider color is now based on the theme color
  • [Android] ScrollView children will no longer flow outside of ScrollView bounds
  • [Android] Setting MasterDetailPage.Detail should now dispose old Detail properly
  • [Android] Reshowing an existing ListView will no longer crash on selection
  • [Android] Fix crash in ImageRenderer during dispose cycle
  • [XAML] BindableObject can now be used as a root element in XAML, not just VisualElements. Allows creating ViewCells as root objects.
  • [iOS] ContentPage inside of a NavigationPage inside of TabbedPage will no longer incorrectly set the tab title from the ContentPage
  • [WinPhone] EntryCell now properly supports IsEnabled


  • adamkempadamkemp USInsider, Developer Group Leader mod

    The default Column/RowDefinitions will be changed from Auto to Star.


  • @JasonASmith - Great news on the •[WinPhone] Secondary toolbar items no longer occasionally duplicate themselves .. been waiting months for this as major part of my (and no doubt others) apps is having secondary items in the toolbar and with it not working on WP I haven't been able to go further so well done for getting this fixed! :)

    However .. sorry but appears it's introduced a new bug in that you can't now add more than 2 primary items as if you do you get an exception halt with "too many items in list" occurring and the app stops :( .. I know there's an imposed limit of 4 primary items which is workable but only 2 is not .. hope this is a quick fix as really want to use .Forms again and got excited with the secondary fix :) so hopefully prerelease 4 will be ok? :)


  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai
    edited September 2014

    @DerekPapworth‌ uhhh thats odd... Looking into it now.

    @DerekPapworth‌ with 1.2.3-pre3 I am able to successfully load up 3 different primary items without any issue on Windows Phone. Can you provide a repro of some sort.

  • ddotmunchddotmunch DEMember ✭✭

    Running into a problem when setting Detail page of MasterDetail which contains Editor - Controls:

    Sep 22 11:36:09 jacks-mac-mini.luax.lan SwaviAppiOS[77897] <Warning>: Unhandled managed exception: Object reference not set to an instance of an object (System.NullReferenceException)
          at Xamarin.Forms.Platform.iOS.EditorRenderer.UpdateEditable () [0x00000] in <filename unknown>:0 
          at Xamarin.Forms.Platform.iOS.EditorRenderer.OnElementChanged (Xamarin.Forms.Platform.iOS.ElementChangedEventArgs`1 e) [0x00000] in <filename unknown>:0 
          at Xamarin.Forms.Platform.iOS.VisualElementRenderer`1[Xamarin.Forms.Editor].SetElement (Xamarin.Forms.Editor element) [0x00000] in <filename unknown>:0 
          at Xamarin.Forms.Platform.iOS.VisualElementRenderer`1[Xamarin.Forms.Editor].Xamarin.Forms.Platform.iOS.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x00000] in <filename unknown>:0 
          at Xamarin.Forms.Platform.iOS.RendererFactory.GetRenderer (Xamarin.Forms.VisualElement view) [0x00000] in <filename unknown>:0 


    we are having an issue with Xamarin.Forms not displaying on IOS only as soon as there is a scrollview in the form.
    Is that an known issue? is there a workaround?


  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @DanielMnch is this happening on an iPad by chance? Can you check if it happens on phone too?

  • ddotmunchddotmunch DEMember ✭✭

    @jsonasmith it's indeed on an iPad, currently checking on phone

  • ddotmunchddotmunch DEMember ✭✭

    @jsonasmith good guess, it's working alright on phone

  • DH_HA1DH_HA1 USMember ✭✭✭


    PopToRootAsync NullReference error

    I am getting a Null Ref error at

    at Xamarin.Forms.Platform.iOS.NavigationRenderer+ParentingViewController.ViewDidLayoutSubviews () [0x00000] in :0 at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr) at MonoTouch.UIKit.UIApplication.Main (System.String[] args, IntPtr principal, IntPtr delegate) [0x00005] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:62 at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00038] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:46

  • @JasonASmith

    I'm experiencing the same issue @DH_HA is, except instead of PopToRootAsync, mine is on PopModalAsync:

    Xamarin.Forms.Platform.iOS.NavigationRenderer.ParentingViewController.ViewDidLayoutSubviews () in
    MonoTouch.UIKit.UIApplication.UIApplicationMain () in
    MonoTouch.UIKit.UIApplication.Main (args=Value not available, principal=Value not available, delegate=Value not available) in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:62
    MonoTouch.UIKit.UIApplication.Main (args=Value not available, principalClassName=Value not available, delegateClassName=Value not available) in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:45

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @jguibault‌ @DH_HA‌ that crash has been tracked and fixed thank you. Seems when we found the memory leak some of the objects being forcibly kept alive were preventing this crash. With the leak fix an NRE became possible.

  • ddotmunchddotmunch DEMember ✭✭

    So is there any chance we're getting an update for this before the usual pre-release in two weeks? I couldn't install the last one due to its bug in MasterDetail page in the last pre-release, and I'm waiting for updates for over 4 weeks already since my app is suffering a lot from memory leaks in NavigationPage and possible others.

  • @JasonASmith‌ - After some more debugging this morning I've discovered why you're not getting the exception whereas I am .. it's because the error only occurs when opening/pushing a subsequent page onto a another page and the combined number of primary toolbaritems exceeds 4 which is the limit for WP.

    Using the example code below, on page 1 you can uncomment 1 to 4 of the items and all is fine but then on page 2 you can only have as many so that total on page 1 plus total on page 2 is <= 4 i.e. you can have 1 (page1) and 3 (page2) or 2 (page1) and 2 (page2) but as soon as you do say 2 (page1) and 3 (page 2) you get the exception.

    My guess is that there's some of cache/save buffer used between page switches that saves page1 before switching page2 which has the 4 limit but this isn't cleared before loading page 2's? Or something along those lines?

    Note: This isn't cumulative, merely between one page and then next as if you add a page 3 say the exception only occurs if sum of page 2 and page 3 exceeds 4 not if sum of page 1, page 2 and page 3 exceed 4

        public ui_Page1() : base()
            Content = new Label { Text = "This is page 1" };
            ToolbarItems.Add(new ToolbarItem("One", "icons\\grid.png", doAction, ToolbarItemOrder.Primary, 0));
            //ToolbarItems.Add(new ToolbarItem("Two", "icons\\upload.png", doAction, ToolbarItemOrder.Primary, 0));
            //ToolbarItems.Add(new ToolbarItem("Three", "icons\\search.png", doAction, ToolbarItemOrder.Primary, 0));
            ToolbarItems.Add(new ToolbarItem("Four", "icons\\neww.png", doAction, ToolbarItemOrder.Primary, 0));
        private async void doAction()
            await Navigation.PushAsync(new ui_Page2());
    public class ui_Page2 : ContentPage
        public ui_Page2() : base()
            Content = new Label {Text = "This is page 2"};
            ToolbarItems.Add(new ToolbarItem("One", "icons\\grid.png", doAction, ToolbarItemOrder.Primary, 0));
            //ToolbarItems.Add(new ToolbarItem("Two", "icons\\upload.png", doAction, ToolbarItemOrder.Primary, 0));
            ToolbarItems.Add(new ToolbarItem("Three", "icons\\search.png", doAction, ToolbarItemOrder.Primary, 0));
            //ToolbarItems.Add(new ToolbarItem("Four", "icons\\neww.png", doAction, ToolbarItemOrder.Primary, 0));
        private async void doAction()
            await Navigation.PushAsync(new ui_Page3());
  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @DanielMnch‌ yes we are pushing out a pre-release 4 thursday if all goes well. I am happy to give you a debug build if you want to test.

    @DerekPapworth‌ looking into it, thank you.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai
    edited September 2014

    @DerekPapworth‌ that was the clue I needed. We are adding the new ones before removing the old ones. Doh.

    Edit - Fixed in a PR, should be in the next release.

  • @JasonASmith‌ glad to provide clue :) thought it must be something like that .. do you think fix can make it into pre-release 4 on Thursday? If not, any chance of debug build with fix in?

    On related subject .. in my original post about secondary toolbar items I also mentioned the difference with iOS implementation vs Android/WP in that in the latter secondary items are hidden as expected and appear in a popup menu when the "hamburger"/more icon is clicked, whereas in iOS they're always visible as second line of "tabs" below the toolbar and if there's a few looks really squashed etc.

    I've customised my implementation so that if compiling for iOS and there are secondary toolbar items rather than adding them to the toolbar I create secondary ActionSheet with secondary item details and add a "hamburger"/more icon as primary to toolbar with it's action being to show secondary ActionSheet. This makes it functionally similar to Android/WP and also similar display wise .. might be worth making that the native (.Forms'wise) way toolbar works?

  • EricGroverEricGrover USMember ✭✭

    The default Column/RowDefinitions will be changed from Auto to Star.

    I had gotten used to the other way! :-)

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    I'd expect Auto as well. Just saying. Will make it explicit from now on, just in case :)

  • HugoLogmans_HugoLogmans_ NLMember ✭✭✭

    Never trust default settings :)

    layout.RowDefinitions.QuickRows (new []{GridUnitType.Auto, GridUnitType.Star});

        public static RowDefinitionCollection QuickRows(this RowDefinitionCollection collection, GridUnitType[] units)
            foreach (var item in units)
                var newrow = new RowDefinition() {Height = new GridLength(1, item)};
            return collection;
  • chris_riesgochris_riesgo USUniversity ✭✭✭

    @JasonASmith‌ - I just logged an Android-specific Forms bug that we noticed after upgrading to You might have some ideas.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    I'd expect Auto as well. Just saying.

    All of the other XAML implementations (Silverlight, Windows Phone, WPF, and Windows 8) use star as the default. That's why it was so commonly reported as a bug.

  • DavidCarawayDavidCaraway USBeta ✭✭
    edited September 2014

    I'd expect Auto as well. Just saying. Will make it explicit from now on, just in case :)

    Basically someone at MS decided upon a completely unintuitive * instead of Auto. His mentor was the guy who came up with Ctrl+Alt+Del. Xamarin, having employed engineers with horse sense, said "why the heck don't we just call it what is is...Auto"? And so they did. The developers would have nothing of this. :^)

  • adamkempadamkemp USInsider, Developer Group Leader mod

    Well that's the cynical view. The more likely reason is that Grid is actually really useful as a primitive using the star row/column size. For instance, if you want to overlay some views and have them centered then it's really easy to just wrap them in a grid (without any row or column definitions). The default star behavior will cause that grid to fill its container, and then the items within it will just overlay on top of each other (using whatever layout settings they have for placement within the grid). That's a common pattern in XAML, but if you change the default then it becomes much more verbose.

    On the other hand, I can't think of a reason to have a single-element (1x1) Grid that uses auto by default. That would have no effect at all. It seems like a useless default to me.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @chris_riesgo‌ thank you for the report, investigating now

  • nbevansnbevans USMember ✭✭✭

    I never understood what Star meant. I thought it was some esoteric width algorithm. But no, it turned out it was exactly what 99% of use cases for Grid would want to use. I realise it's too late now, but why wasn't it just called Percent and Absolute? No silly "Auto" case at all. I am guessing some other framework's silly convention was copied without really thinking?

  • EricMaupinEricMaupin USXamarin Team Xamurai
    edited September 2014

    But no, it turned out it was exactly what 99% of use cases for Grid would want to use. I realise it's too late now, but why wasn't it just called Percent and Absolute?

    The problem is it's not exactly a percentage. It's easiest to think of it that way, but consider the case of having two rows or columns with 25* they still take up 50% of the Grid. If it was "25%" or new RowDefinition (Percent, 25), you wouldn't get the result you expect at all. "Proportional" is probably more representative, but what symbol do you use to represent that?

    No silly "Auto" case at all.

    Auto is useful when that's what you want, just not as the default. The main reason we're changing it is that Grid defaults to fill, so you get an expanding container with only-big-as-needed content as the default behavior, which is fairly odd. So, to get the default to somewhere that makes more sense we either change the default Grid sizing or the default Column/Row sizing, the choice there seems

  • nbevansnbevans USMember ✭✭✭

    I don't use Xaml (and don't really understand why so many here use it especially considering there isn't even a designer for it yet!) so I never considered why a symbol would be important. Why does it have to be a symbol anyway? But why not just use "P" for proportional? ;)

  • TMainTMain USMember ✭✭

    Not sure what the big deal here is, * just means "all available space" in Xaml. Auto means "size me to my largest child". } means "stop processing here" in C#. Symbols just mean things. That is all.

  • ddotmunchddotmunch DEMember ✭✭

    Guess it's not the symbol which is confusing, but the change in who's in control: Like @TMain sais: * mean "all available space", in which case the Grid estimates the remaining space after lay-outing everything else and says to it's child: You can take this size. Auto is the opposite: Grid first ask his child "how many space do you need?" and then layouts everything else depending on the child's requested size.


    • *: Grid is in control of the size
    • Auto: Child of Grid is in control of the size
  • MihaMarkicMihaMarkic SI ✭✭✭✭

    I don't use Xaml (and don't really understand why so many here use it especially considering there isn't even a designer for it yet!)

    Well, the (page) definition looks much more terse and readable, that's why. Plus, you get a separation of code and UI. Which also means that somebody else can play with XAML (think advanced designer) without having clue of programming language.
    Missing designer is not a huge problem for me, more problematic is missing intellisense in Visual Studio (I usually switch to Xamarin IDE when typing XAML) and then go back to VS for coding.

  • ChaseFlorellChaseFlorell CAInsider, University mod

    I'm also having an issue whereby if I've got a Page pushed on top of the base 'Detail' page, and then try switching out the Detail page, it'll crash with the same issue as the noted PopToRootAsync issue. This is only happening on iOS.

    Do I need to create a repro or is this already known?

  • @JasonASmith‌ - you mentioned you were hoping to get pre-release 4 out on Thu but Fri here in UK and don't see it as yet .. do you think it might be today/tonight? Was hoping to do some more work over the weekend but kinda need that fix on primary toolbaritems (already covered/fixed) so any chance of a debug/pre-pre-release :) which includes that?

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @DerekPapworth Im getting the final merges in right now

  • @JasonASmith‌ - That's great! You must be working real late over there .. early hours of the morning? Much appreciate the effort you guys put in by the way .. won't be able to make it to Evolve unfortunately, one man band so can't afford it the expense at the moment :(, but was hoping to meet you and others not only to have some good tech discussions on things but also to say thanks so .. thanks! :)

  • The Android issue in ScrollView children flowing outside of ScrollView bounds has returned in 3!!

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @PeterGoddard‌ I am frankly kinda surprised... do you have a repro?

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @PeterGoddard‌ I just re-verified our test cases that we are not seeing the overflow. If you have a reproduction I will add it and make sure it verifies.

  • @JasonASmith‌ The issues I've experienced were when dynamically adding grid structures to a stacklayout where the content is derived dynamically from definitionsstored in out database. I tried to replicate the problem in a small stand alone project for you to see see but in doing so discovered that by not using grids but stacklayouts instead, it no only speeds up the rendering but also restored the earlier scrolling behaviour that I needed.

    The example I was building which demonstrated the overflow was generating a content structure as follows

                '<StackLayout (Root)>
                    <Picker />
                        <Grid />
                        <Grid />
                        <Grid />
                        <Grid />
                   (.......... repeater code each grid can be different)
                        <Grid />
                        <Grid />
                        <Grid />
                        <Grid />
                        <Grid />

    The content of the ScrollView would overflow the (Root First Child) Picker, and Underflow the LastChild Button.

    I hope this clarifies the scenario.

    I appreciate the prompt responses!!

    Many thanks


  • JacoboJacobo USMember

    Element is already the child of another element. Master Detail page Multi click

Sign In or Register to comment.