Forum› Xamarin.Forms
Xamarin.Forms 2.3.4.221-pre6
DavidOrtinau
USForum Administrator, Xamarin Team, Insider, University Xamurai
USForum Administrator, Xamarin Team, Insider, University Xamurai
We've pushed Xamarin.Forms 2.3.4.221-pre6 to nuget. To install the pre-release, check the pre-release option in your nuget manager and install this version.
If you’ve got a bug to report, drop us a quick report here so we can troubleshoot in detail.
2.3.4.221-pre6
- [iOS] Prevent NRE when page is switched on Appearing (PR)
- [A]Fix potential crash when calling ClearFocus in SearchBarRenderer (PR)
- [Android] Convert Android maps to GetMapAsync call (PR)
- 38723 - "Update Content in Picker's SelectedIndexChanged event causes NullReferenceException" (PR)
- 42559 - "LineBreakMode does not work on UWP" (PR)
- 45330 - "System.ObjectDisposedException: Cannot access a disposed object. Object name: 'Android.Views.GestureDetector'." (PR)
- 52620 - "[iOS] Header in MasterDetailPage overwrites status bar" (PR)
- 53203 - "XAMLC: AttachedProperty not found" (PR)
- 53362 - "Layout regression in Grid on iOS: HorizontalOption = Center does not center" (PR)
- 53381 - "Templated views no longer rendering (as of pre3)" (PR)
- 53834 - "incorrect row heights on ios when using groupheadertemplate in Xamarin.Forms 2.3.4.214-pre5" (PR)
- 53909 - "XML drawables cannot be used as ToolbarItem.Icon" (PR)
2.3.4.212-pre5
51536 - "[iOS] Height of ViewCell and Height of ContextAction incorrectly measured" (PR)
2.3.4.212-pre4
For all the details, please read the release post here. (same release notes)
2.3.4.211-pre3
For all the details, please read the release post here.
2.3.4.192-pre2
For all the details, please read the release post here.
2.3.4.184-pre1
This release builds upon 2.3.4.184-pre1. Revisit that thread discussion here.
1
Posts
The detail link is broken
I was hitting save on that fix just as I got your notification.
Thanks for watching out!
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.
Not fixed at 2.3.4-pre2.
I already sent my whole project to @DavidOrtinau .
(ONLY iPhone 5)
Please provide a link on your release pages to the appropriate nugget package
Eg, on https://releases.xamarin.com/beta-release-cycle-7-service-release-1-updated/ how does one work out what nugget package version this applies to.
I believe that release page is for Xamarin itself, not Xamarin Forms. Xamarin itself is updated through Visual Studio, not Nuget.
Yeh, as @NickCZA mentioned, that URL is not the Forms release we're talking about on this thread.
The NuGet link you're looking for and the Release notes for this version are linked in the original post of this thread. I made sure we also linked from the release notes to NuGet for you.
From your package manager, choose the pre-release option to see the latest version available. Also, from the NuGet web page, the versions are all listed at the bottom. Should be easy to find.
I got it running this morning on device! It crashed in the simulator, so I wasn't able to see it. I do see the same problem. I'll get you an update on the ticket asap. https://bugzilla.xamarin.com/show_bug.cgi?id=51536
@DavidOrtinau
Thanks for your update David.
I faced this problem only on iPhone 5(iOS 10.2)
I have a question.
What is the purpose of sample code in bugzilla?
It's not a workaround, isn't it?
@BBright no, the sample isn't a workout. It's code that can be quickly run to demonstrate the problem, rather than having to setup a new project or dig through a larger existing project.
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://oren.codes/2016/07/09/using-xamarin-forms-with-net-standard/
If you have an feedback about the 2.3.4.192-pre2, please let us know on this thread. For further discussion of the netstandard topic, you'll likely get more engagement starting a new thread.
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?
https://bugzilla.xamarin.com/show_bug.cgi?id=51642
https://github.com/xamarin/Xamarin.Forms/pull/725
I'll follow up on that PR. It'll be fixed.
Does that work?! I don't think I've achieved the power to summon.
I'll follow up on that bug report, thx.
It worked @DavidOrtinau https://github.com/xamarin/Xamarin.Forms/pull/754, Thank you @AdrianKnight !
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?
<Style TargetType="Grid"> <Setter Property="Padding"> <Setter.Value> <OnPlatform x:TypeArguments="Thickness" iOS="0" Android="0"/> </Setter.Value> </Setter> </Style>The error comes back as "Position 32:16. Missing Value for Setter".
EDIT: To add I know this uses OnPlatform but this also happens if I set a standard thickness.
EDIT2: This also happens on 2.3.4.192-pre2
@BradChase.2654 Are you able to reliably reproduce it in a new project and wouldn't mind possibly filing a bug if there's a clear regression?
@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.
@BradChase.2654 My team has run into that
Setter.Valuebug as well, it's part of why we aren't using 2.3.4 pre-releases yet.@BjornB I don't have any free time left to contribute to the project, but I couldn't say no to your bug.
@DavidOrtinau Just saw your email. Please see my response.
Thanks!
@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?
I recently realized I can change HttpClient implementation to AndroidClientHandler which is better.
But since I changed it, the exception "NetworkOnMainThreadException" is thrown because HttpClient's async method needs to be called from backgroundThread. (as I know, it's fine on iOS)
I changed some code where the exception has been thrown with using Task.run(async ...) to make it be invoked on the Background thread.
But it's just for a workaround.
and I found weird one.
https://bugzilla.xamarin.com/show_bug.cgi?id=44961
This says it's been fixed.
and Even in https://github.com/xamarin/xamarin-android/blob/master/src/Mono.Android/Xamarin.Android.Net/AndroidClientHandler.cs
It's wrapped with Task.run.
Why I face this problem?
It's same here. https://github.com/luberda-molinet/FFImageLoading/issues/416
tested on XF 2.3.3.180. Android SDK api23.
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.
https://github.com/xamarin/Xamarin.Forms/wiki/Nightly-Builds
Same issue on 2.3.4.192-pre2? If so, let's reopen that ticket and let me know so I can make sure we prioritize to fix the regression.
Hi, @DavidOrtinau
https://github.com/xamarin/xamarin-android/pull/247
According to this, It turns out that this is fixed on Xamarin.android 7.1.
Is this right?
Then it wouldn't be included in stable release since Xamarin.Android version is 7.0.2.42 now.
Am I correct?
So I better wait, then fine?
XF nightly build is newest, isn't it?
I have a question.
Which branch is the branch of nightly build on the github?
If anyone knows that, please let me know.
By the way, It's newer than 2.3.4-pre2, right?
@DavidOrtinau I was under the assumption that the nightlies were based off of 2.3.4 and the bug fix was in 2.3.5. I will definitely check it out when I am back in the office on monday and report back.
> XF nightly build is newest, isn't it?
>
> I have a question.
> Which branch is the branch of nightly build on the github?
> If anyone knows that, please let me know.
>
> By the way, It's newer than 2.3.4-pre2, right?
Master branch, so newer.
@DavidOrtinau did you already look into the "Unable to create layer for Platform_DefaultRenderer" bug? We still can't update past XForms 2.3.2 because of this.
https://bugzilla.xamarin.com/show_bug.cgi?id=51238
@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.
@BradChase.2654 If you find any sort of regression, please file it with a reproduction.
@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.
They were:
https://bugzilla.xamarin.com/show_bug.cgi?id=51796
https://bugzilla.xamarin.com/show_bug.cgi?id=51642
https://bugzilla.xamarin.com/show_bug.cgi?id=51646
The one with the EEMessageException at memory location is our biggest problem because it literally takes 10 mins to load a view now.
@BradChase.2654, @DavidOrtinau, @PaulDiPietro Yes, same behavior as Brad with the UWP EEMessagException bug 51796 . The form works ok, just takes forever to load because of the exceptions.
@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.
@MarkFredrickson Good news and bad news.
Bad news, it wasnt the exceptions causing the slow down.
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:
void MaybeInvalidate() { //if (Model.IsInNativeLayout) // return; var parent = (FrameworkElement)Element.Parent; parent?.InvalidateMeasure(); Element.InvalidateMeasure(); }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
.
im grabbing my popcorn awaiting the android result
Nice finding there @BradChase.2654
Ahh shoot well after checking, it appears that the MaybeInvalidate was only being called on the windows side
. Well atleast we get one faster system.
Ive filed a bug to fix the speed:
https://bugzilla.xamarin.com/show_bug.cgi?id=52507