Xamarin.Forms 2.3.3.193

245678

Posts

  • BelljuBellju RUMember ✭✭

    @Thomas.Goerlich said:
    I get the following error with the latest Xamarin.Forms and CarouselView pre packages:

    System.TypeLoadException: Could not load type 'Xamarin.Forms.Platform.CarouselViewRenderer' from assembly 'Xamarin.Forms.CarouselView, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

    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.

  • tgodltgodl DEMember ✭✭

    @Bellju said:

    @Thomas.Goerlich said:
    I get the following error with the latest Xamarin.Forms and CarouselView pre packages:

    System.TypeLoadException: Could not load type 'Xamarin.Forms.Platform.CarouselViewRenderer' from assembly 'Xamarin.Forms.CarouselView, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

    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 :wink: 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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @BryanHunterXam @StephaneDelcroix - Are there any plans to add support for IsPullToRefreshEnabled on UWP? If so, is there any indication of when this might happen?

  • nbevansnbevans USMember ✭✭✭

    This pre2 release breaks F# compatibility in a severe way:

    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]

  • WiktorKonckiWiktorKoncki USMember ✭✭

    @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.

  • JimBennettJimBennett GBInsider, University, Developer Group Leader ✭✭✭✭

    @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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭
    edited September 2016

    @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)

  • AdrianKnightAdrianKnight USMember ✭✭✭✭
    edited September 2016

    @JohnHardman

    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.

  • rogiheerogihee NLMember ✭✭✭

    @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.

    Thanks for all your PR's BTW!

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    @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.

    Welcome.

  • WiktorKonckiWiktorKoncki USMember ✭✭

    @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.

  • JimBennettJimBennett GBInsider, University, Developer Group Leader ✭✭✭✭

    @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.

    Forms team - keep up the good work!

  • EmanueleSabettaEmanueleSabetta ITBeta ✭✭✭

    @TonyD said:
    @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    +1

  • EmanueleSabettaEmanueleSabetta ITBeta ✭✭✭
    edited September 2016

    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.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭
    edited September 2016

    @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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @AdrianKnight - does it somehow break functionality, or does it make unit tests fail that should fail (and hence be re-written)?

  • AdrianKnightAdrianKnight USMember ✭✭✭✭
    edited September 2016

    @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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭
    edited September 2016

    @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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @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.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭
    edited September 2016

    @JohnHardman I tested all your scenarios. I even found an edge case. See my latest comment here: https://github.com/xamarin/Xamarin.Forms/pull/386

    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, WidthRequest HeightRequest MinimumWidthRequest 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

    In this case, it should render 44 units.

    Feel free to continue the discussion on the GitHub thread. :)

  • WiktorKonckiWiktorKoncki USMember ✭✭

    @AdrianKnight said:
    I just don't understand why they would reject a PR because it's breaking.

    I actually seen this before in other projects, even big ones like mysql. Unfortunately if you keep bugs for long enough, they become features.

  • rmarinhormarinho PTMember, Insider, Beta Xamurai

    Hey everyone, just a little feedback.

    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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @rmarinho - Hi Rui. As it relates to virtualisation of ListView, which is a performance matter, I wonder if you could answer the OnBindingContextChanged question I raised above on UWP please?

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    I posted this about a month ago:

    Here is a sample from my output window:

    [0:] 11:14:50.770: DocNavigationViewModel.NavigateProperties[197]: Navigated
    08-18 11:14:51.702 I/art ( 4427): Explicit concurrent mark sweep GC freed 5041(231KB) AllocSpace objects, 2(348KB) LOS objects, 40% free, 10MB/17MB, paused 448us total 18.938ms
    08-18 11:14:51.706 D/Mono ( 4427): GC_OLD_BRIDGE num-objects 295 num_hash_entries 47142 sccs size 25747 init 0.00ms df1 148.88ms sort 30.32ms dfs2 396.90ms setup-cb 3.47ms free-data 175.82ms links 181377/181377/2912009/115 dfs passes 228814/207124
    08-18 11:14:51.706 D/Mono ( 4427): GC_MINOR: (Nursery full) pause 155.65ms, total 155.80ms, bridge 0.00ms promoted 224K major 4816K los 783K
    [0:] 11:14:51.812: DocNavigationViewModel.OnItemTapped[188]: End of OnItemTapped. IsNavigating set to False

    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.

  • rmarinhormarinho PTMember, Insider, Beta Xamurai

    @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.

  • Shane000Shane000 USMember ✭✭✭

    @MichaelRumpler Where did you find it set to Old? I read Tarjan was default but want to make sure mine isn't set to Old somewhere.

  • SamanthaHoutsSamanthaHouts USXamarin Team Xamurai

    @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.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @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).

  • rogiheerogihee NLMember ✭✭✭

    @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.

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    @ShanePope
    There are GC messages in the Output window.

    Old:

    08-18 11:14:51.706 D/Mono ( 4427): GC_OLD_BRIDGE num-objects 295 num_hash_entries 47142 sccs size 25747 init 0.00ms df1 148.88ms sort 30.32ms dfs2 396.90ms setup-cb 3.47ms free-data 175.82ms links 181377/181377/2912009/115 dfs passes 228814/207124

    Tarjan:

    09-29 18:18:31.419 D/Mono (14366): GC_TAR_BRIDGE bridges 1918 objects 75550 colors 1945 ignored 148728 sccs 1918 xref 1090 cache 0/26 setup 0.59ms tarjan 62.34ms scc-setup 1.31ms gather-xref 0.17ms xref-setup 0.06ms cleanup 5.35ms

    If you see GC_OLD_BRIDGE or GC_NEW_BRIDGE (that would be the obvious name), then you should override it like it is described in https://developer.xamarin.com/guides/android/advanced_topics/garbage_collection/#GC_Bridge_Options.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @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?

    https://developer.xamarin.com/guides/xamarin-forms/user-interface/listview/customizing-cell-appearance/#Custom_Cells

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @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.

Sign In or Register to comment.