Is someone else seeing this as well and are there any workarounds? The app works on UWP ... couldn't test iOS yet.

I had the same problem with XF 2.3.3 using carousel. Downgrading solved it.

Thanks, i tested that as well but that is not what i had in mind i was hoping that i could use the latest pre AND the carousel view ... especially because there should have been bugfixes for the carousel view in the latest version.

error FS0443: This type implements or inherits the same interface at different generic instantiations 'IElementConfiguration' and 'IElementConfiguration'. This is not permitted in this version of F#. [C:\Sandbox\XXX\XXX.Mobile.Core\XXX.Mobile.Core.fsproj]

Why does it take months to develop a flippin' carousel view? You're not inventing a spaceship. We expected Microsoft to fix things - not be the same crap Xamarin was. Sometimes my breakpoints don't get hit in VisualStudio when I'm debugging iOS. Rebuilding iOS is extremely slow compared to Android, and debugging is often not a good experience because the error messages are cryptic.

Tip for all those developers getting p1ssed off by the hard work the Forms team are doing not satisfying your exact requirements - head over to https://github.com/xamarin/Xamarin.Forms, make the fix and raise a pull request. That's the beauty of open source.

@JimBennett said:
Tip for all those developers getting p1ssed off by the hard work the Forms team are doing not satisfying your exact requirements - head over to https://github.com/xamarin/Xamarin.Forms, make the fix and raise a pull request. That's the beauty of open source.

Performance is not "your exact requirements". It's everyone basic requirement. Xamarin applications get trashed in android store reviews. That's a deal breaker for any developer. You also forgot that Xamarin transitioned not so long ago and those forums are still filled with people who paid quite a bunch of $$$ for using it.

@WiktorKoncki - not true - plenty of Xamarin applications get fantastic reviews in the Google Play store. If your app is too slow then maybe you should have evaluated Forms for your requirements before using it. I also used to pay a lot for Xamarin so did not forget this point, but I made sure the tools fit my purpose. Xamarin Forms has in the past been pitched at scenarios where flashy UI is not needed, and for those tasks it works very well. If you want more control then don't use forms.

As for 'performance being everyones basic requirement' - Forms gives you a certain level of performance. Native Android can give you better performance but you can still write really slow apps. These are tools, they have their upsides and their downsides, you can write fast Xamarin Forms apps and slow native apps.

If you've written your app well and you are getting bad reviews due to performance then it should be simple to replace your UI layer with native for your Android app.

@JimBennettWe don't want to develop Xamarin.Forms, we want to develop WITH Xamarin.Forms.
It's not a playground for us (it seems as it is just this for some users), it should be a stable platform for stable app's (what is not true SINCE YEARS now)!

@JimBennett said:
Tip for all those developers getting p1ssed off by the hard work the Forms team are doing not satisfying your exact requirements - head over to https://github.com/xamarin/Xamarin.Forms, make the fix and raise a pull request. That's the beauty of open source.

That's a bit harsh Jim, we pay for multiple MLS licences and are an enterprise customer so expect a certain level of stability from the platform. As far as I'm aware, they are working on trying to improve Android performance and I'm well aware of how hard the team works (they deserve more resource allocated IMO), I think a lot of this frustration is down to a lack of communication.

@BryanHunterXam@StephaneDelcroix - I have a pile of outstanding bugs in bugzilla. I've listed just 7 below. For those 7, is there any chance of getting the two CONF ones fixed, the one with a PR fixed, and the other four at least triaged please.

Of the ones needing triage, 44773 is the most important. There are various issues around ListViewCachingStrategy, so at least having RetainElement work as expected across the platforms would provide a base from which to start then investigating bugs relating to RecycleElement.

44773 - ListViewCachingStrategy.RetainElement on UWP is constructing multiple instances of cells as the user scrolls up and down (NEW - repro code provided)
44738 - MinimumHeightRequest ignored in ListView Header and Footer templates (NEW - repro code provided + Adrian Knight has done a PR at https://github.com/xamarin/Xamarin.Forms/pull/386)
36670 - ScrollView on WinPhone 8.1 RT calculates height incorrectly if word wrap used in nested views (CONF)
40817 - AutomationId may only be set one time exception (CONF)
43716 - Height = GridLength.Auto in RowDefinition does not handle content of word-wrapped Label on UWP and WinRT (NEW - repro code provided)
44680 - On UWP and WinRT 8.1, Image with IsVisible=false obscures what is beneath it (NEW - repro code provided)
43832 - Using a ListView with a DataTemplateSelector and RecycleElement results in wrong behavior on cells (NEW)

As you can see, my PR was rejected. If fixing a bug creates a breaking change for apps that worked around a bug, then what we are saying is it is OK to not fix bugs even though you know you can. I'm more curious now to see how XF team will release a functioning MinimumWidth/HeightRequest.

Maybe, I'm not thinking this straight, but I see several ways to address this issue:

Don't worry about breaking changes (Developers will need to fix their code if they update to a new version of XF. Not fun for developers)

Use conditionals in XF source code based on assembly versioning (Increases clutter, potentially maintenance hell. Not fun for XF team)

Release two versions of XF each release cycle so that one includes breaking changes (Gives enough time to devs while they pull in non-breaking changes.)

As frustrating as it sounds, I'd be comfortable with the first option.

@AdrianKnight I completely agree, breaking changes are fine as long as it improves the code, fixes bugs etc. They must be well documented, so I wouldn't add the PR in a point release but in this case in a 2.4 branch, that could be pre-released so users can check their app.

Have you emailed Jason Smith, or maybe start a discussion on the Forms dev list about breaking changes? Might be a bit better suited than the forum.

@rogihee No, never got involved in a discussion about breaking changes. The only communication I had was in that PR. I'm hoping we can see a discussion there for the time being. I think it needs to be re-opened and sit in the queue until perhaps 2.4-pre1.

@AdrianKnight
One solution would be also to follow sane versioning model where minor releases are not introducing breaking changes. It should be safe to upgrade from 2.2.1 to 2.2.2 without worrying about breaking changes. We can then introduce breaking changes in 2.3.0. That would make it much safer and cleaner for everybody involved.

@AdrianKnight - if it's a breaking change then maybe it'll have to wait for 3.x? I assume they're using SemVer so breaking changes need a major release bump, so maybe they'd prefer to batch up a few breaking changes into one big release.

@NMackay, @FredyWenger - I know where you are coming from, just trying to offer a counter to the negativity as that seems to be predominately what is appearing on this thread. As I've already said elsewhere I have a hell of a lot of respect for your views on this @FredyWenger as you've dealt with a lot of issues and been very candid with talking about what has caused your problems, I just wanted to pop my head up and offer some positivity.

Forms is awesome - it allows you to write one app and create native apps on multiple platforms, you can avoid the complexities of the iOS autolayout, have a consistently laid out UI on multiple platforms and can easily drop into native where required. It's not perfect, and every time a new OS is released in iOS and Android they have a lot of work to do to ensure it still works and supports any changes, but what it does it does pretty well, and I know a fair few people who are happy with it in production apps. It has it's limitations and Xamarin have never been shy about mentioning them - it was pushed for prototypes and LOB at the start, now its anything without a flashy UI. The team has done a superb job getting where they have, and it's certainly getting better and better all the time. The teams communication could be better, but sometimes it is hard in a commercial environment as they don't want to give away confidential plans.

Microsoft needs to hire more people for fixing bugs in Xamarin.Forms.
Bug fixing is not like developing new features, where the man-month idea is just a myth. Bug fixing is scalable because each bug has a very defined area of intervention, and usually require one programmer assigned to fix each bug. The resource/speed ratio for bug fixing is linear: if you increase the staff by n times, the bug fixing speed is also increased by n.

@WiktorKoncki@JimBennett I'm okay with breaking changes waiting till a bigger release. I just don't understand why they would reject a PR because it's breaking. It should stay in the PR queue and NOT be rejected. Maybe @JohnHardman needs to push back on 386.

@JohnHardman At the time I submitted the PR, all unit tests passed. I'm having difficulty running UI Tests due to environment setup issues. Surely, it will break existing functionality when minimum values start working, but it's up to devs to fix their own code. For example, if you were doing calculations based off of Width/HeightRequest of one element to position another element, then these calculations will be incorrect when minimum values come into play because Width/HeightRequest doesn't represent the actual size anymore.

Another scenario (I'll confirm this):

You had a button with 30 units of width. Platform renderer returned 33 as default minimum width. XF originally overwrote default values with yours (you wrote UI/Unit tests expecting 30). If you hadn't indicated a width, then you'd get 33 (this is fine).

Now you should get the maximum of the two (breaking change). If you typed MinimumWidthRequest=44, then you should get 44 (this is fine).

Again, I'll confirm the above scenario and update this post. In all seriousness, I'd have expected a review of the changes instead of a simple close of the PR.

@AdrianKnight - Not one of my classier repro samples, but it does the job ;-)

Many thanks for your help on this. As you say, it would be good to have useful feedback where a PR is rejected.

With my old SET/SDT/SDET hat on (which abbreviation to use depends on where you've worked :-) ) ...

With a default of 33, and neither WidthRequest nor MinimumWidthRequest, I would expect Width to be 33.

With a default of 33, and a MinimumWidthRequest of 44, I would expect Width to be 44.

Whilst I was reporting issues around Minimum values, rather than WidthRequest and HeightRequest, with a default of 33 and a WidthRequest of 30, I would expect Width to be 30.

With a default of 33, a WidthRequest of 44 and a MinimumWidthRequest of 30, I'd expect Width to be 44.

With a default of 33, a WidthRequest of 30 and a MinimumWidthRequest of 44, I'd hope the renderer wouldn't throw an exception (because renderer exceptions can be a nightmare to investigate) and would hope the property setters wouldn't throw an exception (because Slider used to do so on WinPhone and/or Windows, and it was also a nightmare), but I don't know what I would expect the result to be - perhaps 33 as what the caller specified did not make sense.

@BryanHunterXam@StephaneDelcroix - It turns out that 44773 is apparently intentional behavior - it's just NOT what the documentation explicitly says it will do. Can somebody confirm please on UWP, when using ListView with RetainElement, whether it's necessary to implement OnBindingContextChanged.

If not explicitly using RecycleElement, I wouldn't expect to need to implement OnBindingContextChanged, but if UWP is doing virtualisation even when not explicitly using RecycleElement, does it magically handle changes of BindingContext, or does the user have to implement it even when not using RecycleElement?

If the user has to implement it, and if I understand OnBindingContextChanged correctly (the documentation is woefully lacking), the idea of having one set of code to work cross-platform for ListView is rather dubious - RetainElement doesn't actually retain an element on UWP, and RecycleElement behaves so differently between platforms (watching the pattern of ViewCell construction on different platforms is somewhat surprising) that it's no wonder there are different issues on different platforms.

In my case, Android button renders 88x48 units by default. If you explicitly give it 60 width and 120 minimum width, then GetSizeRequest will create a size request object with 60x55.5 (measures button on 60 width hence the wrapping of the text and increased height) and update minimum to 120 but it does not know what height to give so it gives minimum 55.5 (should be 48). Even if this is fixed, Layout needs to be intelligent and assign the correct size.

I rewrote GetSizeRequest so that we measure once for request and once for minimum and return the correct SizeRequest object, but this breaks a lot of unit tests. I also worked on Layout and ended up with a lot of if-else conditionals. By default, WidthRequestHeightRequestMinimumWidthRequest and MinimumHeightRequest are set to -1. If the user explicitly sets any to a value, then we are looking at 2^4=16 predicates to understand what the user intends. Maybe there is a better way and I just don't know it.

That said, you will still get the right width but incorrect height. I don't think most people would run into this issue and even then it's fixable. What's the point of doing 60 width and 120 minimum width? Just remove the first one.

Still, the changes are an improvement over the current state. All unit tests pass, so I'm not sure what Jason was getting at when he said it would break functionality.

With a default of 33, a WidthRequest of 30 and a MinimumWidthRequest of 44, I'd hope the renderer wouldn't throw an exception

Breaking changes is something take serious, we have a lots of enterprise customers and 3rd party libraries that depend on Forms and ABI compatibility, and we don't want to brake everyone. That said we are looking at ways that we can move forward and still don't break people. At the time we are looking at maybe a extra package with the legacy stuff, so one could always opt in.

We are working on Android performance, we are trying to see where we can shave time on layout , binding system etc.. Take note this is a very complex problem and special making sure we still keep all functionality. We can't give ETA when will it be fixed since this takes a lot of analys and benchmark.... a never ending job of improvement Xamarin Forms performance. But rest assure the team is trying to address this. If you check master you will see a couple of small things getting in.

It's great to see more involvement of the community, more pr's , bug fixes etc.. Keep it going.

We are working on Android performance, we are trying to see where we can shave time on layout , binding system etc..

Rui, I don't think the performance issue can be addressed just shaving some time here and there. The problem is architectural. The code doesn't scale, period. Once you reach a certain number of images or elements on screen, the system becomes unusable. GC explicit sweeps become so frequent that you can hardly interact without making everything unresponsive. Even the most basic function of mobile devices, the scrolling of a list, something that the user is used to see always perfectly smooth on browsers, has continuous hiccups. I don't think the issue is XAML, because XAML is conceptually not very different from HTML+CSS. But then why scrolling long web pages with tons of images and elements is always smooth on the browser on the same device, while in Xamarin.Forms (even when compiled) you have continuous hiccups with just a few custom cells with few small images?
Something is deeply flawed in the basic architecture of XAML that makes the performances going down quickly as the number of elements on the page increase. Shaving some time here and there will not solve the problem, because the cpu usage grows in a non linear way. The only thing that can solve the problem is changing the current code with something that scales, something that doesn't waste cpu time in doing again and again the same thing for each element. Things like precalculating layouts, pre-rendering, caching, buffering, recycling, singletons and factories, constants and shared elements to avoid allocating, etc. need to be used. If a browser can get 60 fps with HTML, you can do the same with XAML. There are no excuses.

It's good to see that you take those serious, but fixing a feature which did not work is something different IMHO.

Yes, the layouts would look different with the fix, but only if users tried (and failed) to use MinimumWidth before and they left it in and worked around it. Making Forms do what it should justifies such a change.

What's even more important: @AdrianKnight invested a lot of work to write all those PRs - not only this one. His name pops up more often in the list of PRs than any Xamarin employee. If you reject a fix for a bug, then people will be less motivated to do PRs. You'd have to do everything yourself like it was before you open sourced it. And we all know that you lack the time and people to make the great product XF should be.

The first and last lines are from my code. Between those I just return from a method and set a bool flag. The rest of those 1.042 seconds between those lines the GC blocked the app.

As you can see it mentioned GC_OLD_BRIDGE. It was using the old GC although the GC documentation states that Tarjan should be the default. I didn't know about that before and I didn't choose a different GC on purpose.

However, now my Android app does use the Tarjan GC and it seems to be better than before. I don't know if it was Cycle 8 or a new XF version which changed it. I did not.

@MichaelRumpler we sure appreciate all the hard work of the community , but i personally don't agree that just because you open a a lot of PR's it would be a indication they have to be merged.
There's a process of review, testing, ui test and manual review. For example sometimes we have asked to add a couple of UITests, because if we are fixing a bug we want to make sure it doesn't regress in the future. Others we review changes made to existing code without a proper explanation, we can't just add something because it fixes only 1 case and might brake another.
And it's true some issues do make that Forms doesn't behave exactly how it's supposed, but there's lot's of apps and 3rd party libraries already relying on some of those behaviours so we need to be smart and don't brake everyone when we change something. This is just hard and we are figuring the best way to do it more globally and not just for particular issues.

@JohnHardman i don't se why you have to implement OnBindingContextChanged, we actually say to people don't use that.. lot's of people use it as a "hack" to get to the VM and to get notified when changes.

@JohnHardman It should not be necessary to implement OnBindingContextChanged on your Cells. As you scroll through the List, UWP will automatically replace the contents of the ItemContainers for you, regardless of the CachingStrategy you have selected.

@SamanthaHouts - Great to know that OnBindingContextChanged isn't expected to be required on UWP.

@rmarinho - That's interesting. I actually went through my code a while back and removed all of the OnBindingContextChanged stuff, other than to leave some diagnostics there to see what is going on. However, the documentation of OnBindingContextChanged is sadly lacking, and I have whilst searching everywhere for more info about its use found snippets from Xamarin folk showing it being used. Some clear documentation and guidance is definitely required. I did notice it on one of the slides from a Xamarin University deck last night as well, although there was nothing useful on the slide to say why it was there.

I also suspect that using OnBindingContextChanged will be required in the short term to workaround some of the ListView bugs, particularly relating to RecycleElement. I have one logged where ViewCells are disabled, which I suspect I will need to use OnBindingContextChanged to workaround (still to investigate).

@rmarinho I agree with you that PR's should be good enough before merging but I think you are missing @MichaelRumpler 's point: Forms is still in it's infancy open-source wise and then also the way you accept or close a PR, which somebody did in their spare time, matters also as most as the PR or scope of it itself.

I think it is good to engage more and discuss more and explain, rather than "just" closing the issue, boom like Jason did in this case.

@rmarinho@SamanthaHouts - Here's one piece of Xamarin documentation saying to use OnBindingContextChanged. Can you confirm whether or not this guidance is still correct based on your comments above please?

Xamarin Forms is a UI framework, something which is not part of Xamarin core business. But Xamarin promoted Xamarin Forms at Evolve 2014, Evolve 2016, on their blog, and now Xamarin University includes it.
It's like Xamarin Forms is really mainstream. But surprisingly, the Xamarin Forms team continues to be very small and progress on performance is still slow.
Progress was made on new features though (control templates, native views, etc.) which is great, but again, it's confusing to me the direction and future of Xamarin Forms.
And now Xamarin part of Microsoft complicates it, I'm not sure. Why would Microsoft want to pay employees to work on Xamarin Forms, a cross platform UI framework? It's even more strange than before.

Personally I always wanted for Xamarin Forms to become the framework which it should be. Unfortunately, I've seen so little communication from Xamarin and support on their own forum, I have no idea what's going on. Regarding Xamarin Forms, Xamarin decided to look like Microsoft, and it's not in the good ways.

@BryanHunterXam@StephaneDelcroix - I can see that people have been through some of the bugs I listed above. It seems that 43716 has been missed - could you have somebody take an initial look please? Many thanks.