Is this bug happening only to me?
When I use listview's contextAction, Viewcell's height is ruined.
(ONLY iPhone 5)

before 2.3.3 - not happen
until 2.3.3-pre4 - not happen
2.3.3 stable and 2.3.4-pre1 as well - happen firsttime
And Xamarin.forms team said there is a issus at 2.3.3 stable and will release again.
(at the same time, I tried 2.3.4-pre1, same result)
2.3.3-SR1 - problem was gone.
2.3.4.184-pre1(new release) - problem again here.

@BBright said:
Is this bug happening only to me?
When I use listview's contextAction, Viewcell's height is ruined.
(ONLY iPhone 5)

before 2.3.3 - not happen
until 2.3.3-pre4 - not happen
2.3.3 stable and 2.3.4-pre1 as well - happen firsttime
And Xamarin.forms team said there is a issus at 2.3.3 stable and will release again.
(at the same time, I tried 2.3.4-pre1, same result)
2.3.3-SR1 - problem was gone.
2.3.4.184-pre1(new release) - problem again here.

@michaelwalmsley said:
What i was looking for was a version of forms that was compatible with netstandard. The oage i was referring to was about netstandard so surely its the forms package that i need.

Im trying to use forms and netstandard together. However i cant get it to compile using vs2017 and the new csproj structure.

Ah, I understand. We don't yet publish a version of Forms compatible with netstandard and it's not currently on the roadmap.

But...Xamarin.Forms community to the rescue! Check out @OrenNovotny's blog post on that topic.

https://bugzilla.xamarin.com/show_bug.cgi?id=52318
New bug, This is nothing that came in this release, I Think its a bug that was introduced all the way from XF 2.1.0.6529.
I here by summon @AdrianKnight since your PR solved the parent to this bug (Many thanks!) , can you please take a look at it. Since it has to do with appearing/dissapearing events in my mind its pretty important even though i can be worked around now that we have platformspecific options for android. Thank you!

The bindable Picker does not appear to update when OnPropertyChanged is fired from a bound ObservableCollection on UWP. My binding is correct because it works with a listview, but not with a picker. I'm using 192. I see that there a bug has been filed and a pull request created but failed. Is this going to be fixed, or a work around provided, or do I need to plan on using a static list for the foreseeable future?

@MarkGarcia said:
The bindable Picker does not appear to update when OnPropertyChanged is fired from a bound ObservableCollection on UWP. My binding is correct because it works with a listview, but not with a picker. I'm using 192. I see that there a bug has been filed and a pull request created but failed. Is this going to be fixed, or a work around provided, or do I need to plan on using a static list for the foreseeable future?

@BjornB said:https://bugzilla.xamarin.com/show_bug.cgi?id=52318
New bug, This is nothing that came in this release, I Think its a bug that was introduced all the way from XF 2.1.0.6529.
I here by summon @AdrianKnight since your PR solved the parent to this bug (Many thanks!) , can you please take a look at it. Since it has to do with appearing/dissapearing events in my mind its pretty important even though i can be worked around now that we have platformspecific options for android. Thank you!

So I updated to the nightly to see if some drawing issues were fixed when leaving the app and coming back which breaks a bunch of our views. I cannot compile now because any style that uses a Setter.Value is broken. Is anyone else seeing this?

@PaulDiPietro I will as soon as I test some other stuff out on it. I want to see if its isolated to certain properties. I wanted to check if anyone else was getting it because I havent heard anything on it so far.

EDIT: Well as usual I created an example app and added the offending code in and it still compiled. So ya got me. I noticed that the Setter.Value was the content property so I just removed the .Value lines and it worked.

Sad part the latest Forms still didnt fix my redraw issues which I cant replicate in a small sample app either. If I force every control in the tree to redraw then the app looks perfect again on resume(takes about 5 minutes to do). Only happens when I minimize the app by taking a photo or loading a pdf, something like that.

@DavidOrtinau David, I went ahead and got some time today to try and test out the last defect https://bugzilla.xamarin.com/show_bug.cgi?id=45179 that was going to be fixed where the DataTemplates were being created before they needed to, leading to being created to the Nth degree down in the tree. I went ahead and merged that checkin with this release and they are still being created. Is there some reason why it might be able to merge over or is there a specific way that is recommended? I would like to start testing UWP but we are in a predicament where we cant upgrade Forms until that bug is fixed and we cant run UWP until we upgrade...

Any ideas on what we should do at this point? Or what might help us merge those two in a working fasion and maybe a small writeup on which dlls go where(unless they changed with the stubs I am doing as my custom version before) Or maybe some nightly release of master?

@BradChase.2654 said:@DavidOrtinau David, I went ahead and got some time today to try and test out the last defect https://bugzilla.xamarin.com/show_bug.cgi?id=45179 that was going to be fixed where the DataTemplates were being created before they needed to, leading to being created to the Nth degree down in the tree. I went ahead and merged that checkin with this release and they are still being created. Is there some reason why it might be able to merge over or is there a specific way that is recommended? I would like to start testing UWP but we are in a predicament where we cant upgrade Forms until that bug is fixed and we cant run UWP until we upgrade...

Any ideas on what we should do at this point? Or what might help us merge those two in a working fasion and maybe a small writeup on which dlls go where(unless they changed with the stubs I am doing as my custom version before) Or maybe some nightly release of master?

Can you try a nightly build instead of cherry picking the fix? If you still encounter the issue, post a repro sample project for us to that ticket and reopen it.

@DavidOrtinau Disregard the cherry pick comment. I went ahead and finally got everything running under nightly and sure enough it works perfectly, templates are now loading only once! Thanks a ton to you, stephane, and the dev team!

EDIT: Hmm now on UWP it bombs out wherever I change Picker.SelectedIndex with a value out of range exception.

@PaulDiPietro Ack lost my last comment. I am not going to bother with putting up another bug because I believe the problems are already filed after I re-read the other posts here by @MarkFredrickson and @David.Rettenbacher.

@MarkFredrickson Have you tried turning off XAMLC? I get different issues both ways, one with the exception being thrown over and over, the other doesnt yet its still slow amongst other issues one of which I had to add <Namespace Name="Windows.UI.Xaml" MarshalObject="Required All"/>
to my rd.xml.

@MarkFredrickson well I dove into it a little more because something that takes android or ios literally a quarter of a second in UWP now takes 7 seconds. I decided to put the performance profiler on it and it appears to come down to one function "IsInNativeLayout". Ive attached the chart to it. I havent had time to pour over it but I wonder if that is what is throwing the exceptions.

Edit:. With this function is it possible to split it out for different calls or can we aleast only check its current parent rather than the whole tree? Because every single call to it, it checks every parent it has in the entire tree from what it appears at first glance.

Good news?!? My entire rending time is SPLIT SECOND! I mean instant rendering!!! I went ahead and said screw it lets not even call the IsInLayout and lets just force a layout everytime. HOLY CRAP! Everything I am rendering is there by the time I click on it, every screen, every depth, every control! And its perfect.

EDIT1: We are talking screens that took 7 seconds and some into the minutes are now down to instant.. I mean instant.

EDIT2: If you want to replicate an example of how to get the speeds, go into VisualElementTracker and comment out IsInNativeLayout like so:

Then copy over the DLLs for testing. I believe this is the only function that calls it. Amazing.

EDIT3: I tried to test android to check speeds but I have majorly fubared my libraries at this point just to test UWP. So I will test it tomorrow morning as I am pooped right now and way past my bed time. If someone wants to check the speeds I would love to wake up to that good news .