Xamarin.Forms 2.3.2-stable

2

Posts

  • jonojono USMember ✭✭

    On closer inspection i do get the GC pauses in (navigating mostly) without the debugger is attached too. But ive nothing to compare this too as i never used 1.5. The iOS experience with/out debugger is fast and smooth.

    Excessive GC sounds like an allocation issue. MS recommends going to pooled memory in such situations, or re use of objects. Sounds like Xam may need to go down this route?

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @BryanHunterXam - Is there any chance of getting bug 43716 addressed (word wrapping of Label in a Grid in a ViewCell, on UWP)? Or at least get it triaged so that it can go in the following update?

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    @BryanHunterXam @TheRealJasonSmith

    A bug was introduced in 2.3.2.118-pre1. I filed a bug submission here: https://bugzilla.xamarin.com/show_bug.cgi?id=43993

    If I put an Entry above a ListView or set list view header as an Entry, keyboard show->hide will mess up iOS list view scrollbar height. In my repro, I can't see anything beyond item 93 on iPhone 6.

    If you revert to 2.3.1.114, then all is fine. I need my list data to be searchable; thus, I can't update XF version at the moment.

    Can this be fixed asap?

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭

    @AdrianKnight Version 2.3.2.127 has just been released.

  • OddbjornBakkeOddbjornBakke NOMember ✭✭

    @MichaelRumpler said:
    @AdrianKnight Version 2.3.2.127 has just been released.

    Nice, waiting for release notes then :D

  • BjornBBjornB USMember ✭✭✭

    Thanks to @AdrianKnight this bug https://bugzilla.xamarin.com/show_bug.cgi?id=41322 is solved from his PR. Can you please include this PR asap Xamarin :)

  • Just installed 2.3.2 stable, but Listview Pull-to-Refresh ActivityIndicator animation stucks when listview is on the first navigation page. When i go away and then back again it is working just fine

  • Shane000Shane000 USMember ✭✭✭

    Anyone know how to hide that giant bar with xaml preview button?

  • RenaudLaloireRenaudLaloire BEUniversity ✭✭

    I am just adding myself to the long list of people who are experiencing huge difference in performance between iOS and Android ... But that's not new to this version.

  • +1 For Android Performance Issues. Pushing a page is relatively slower than iOS. I also experience a major slowdown when using a TabbedPage with 5 Content Page children, switching 2 to 3 tabs away.

    For iOS, HttpClient performance seems to be much slower than Android.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    For me, Android slowdown is particularly evident when debugging. I can't scroll a listview without a major fps drop.

  • ThibaultDThibaultD SEMember ✭✭✭
    edited September 2016

    @AdrianKnight said:
    For me, Android slowdown is particularly evident when debugging. I can't scroll a listview without a major fps drop.

    A bit off-topic
    I mostly debug using the iOS build of my app, if I'm not forced to investigate an Android-specific bug. I hear a lot the claim that building to Android is slow with Xamarin. And now that debugging is slow.
    But let's be honest, if you have developed native apps for iOS and Android you know that the iOS simulator is by orders of magnitude faster that the Android emulators, both in building, deploying and running the apps. (Even if it's much better since the x86 emulator is out, still not perfect)
    Debugging on device on Android has always been pretty slow with native apps. Somehow, it felt it was faster when I switched to Xamarin.

    So to me the current fastest way to develop Xamarin.Forms apps is to use Xamarin Studio on a mac and deploy to an iOS simulator.

    Back to topic
    I've just upgraded my app from Xamarin Forms 1.5.1 to 2.3.1 for iOS10's sake.
    Now I'm testing it on Android and that's true that there is a noticeable performance drop.
    I've tried the same build with 1.5.1 and 2.3.1 (and minor deprecation issues fixes), still with cycle 7, on a Nexus 5, and this is my feeling:
    Xamarin.Forms 1.5.1: Not 100% smooth, already one can see a few lag issues. But 90-95% acceptable I'd say, enough for my purpose.
    Xamarin.Forms 2.3.1: I'd say about 75-80% acceptable.

    My conclusion is that there is a performance drop, but if you compare Android and iOS, the iOS version of my app was already much smoother with 1.5.1 than the Android one was.

    I mostly use ListViews and StackPanels (and Labels, Buttons and Switches)

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    @ThibaultD I'm using Visual Studio, and for me it takes much longer to build and deploy to iOS than Android; however, iOS debugging performance is much better even from within VS.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    Similarly, I find building for iOS from VS2015 takes an age. It's never been fast (which I put down to the Mac Mini I use for a build server), but it got significantly slower after one XF update sometime last year I think.

    Whilst I would like iOS to be the platform I do most testing on, I actually do most testing on UWP as it is hugely faster to build/deploy/debug from VS2015 for UWP (obviously for desktop, but also for phone) than on either Android or iOS.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭
    edited September 2016

    I am currently using XF 2.3.1.114, but am hitting different ListViewCachingStrategy bugs on each platform (UWP, Android, iOS). I don't see anything to suggest XF 2.3.2 will have resolved any of them, but am contemplating moving to XF 2.3.2 in the hope that things might have improved without anything relevant appearing in the release notes. Has anybody hit anything particularly serious using 2.3.2, particularly around ListView? Feel free to message direct :-)

    If I stay on 2.3.1, I'm going to limit ListViewCachingStrategy to RetainElement on iOS and Android (despite the horrible performance), and RecycleElement on UWP (not that it does what would be expected).

  • MiguelCervantesMiguelCervantes MXMember ✭✭✭
    edited September 2016

    I'm having an issue on Android with a listview that has a viewcell and an entry , each time I defocus the entry, the entire childs on the listview fire the defocus event causing an infinit loop.

    Tell me if i'm wrong but is that normal? I knew that defocusing an entry only fires its defocus event not all.

    Any ideas?

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @MiguelCervantes - if you have a ListView in a ViewCell, I think that's not supported.

  • MiguelCervantesMiguelCervantes MXMember ✭✭✭

    @JohnHardman No dude, sorry i didin't made myself clear, I have a listview with custom viewcells, those viewcells have a label and an entry, I edited my post!

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @MiguelCervantes - No problem :-)

  • MiguelCervantesMiguelCervantes MXMember ✭✭✭

    Back in here with the demo here

    What happens is that focusing the entry then focusing another one always fires the first element entry focus/defocus, you need to focus/defocus 2 or 3 times and it began to behave strange.

    The first time you select an item (an entry) is correctly works, but just the first time.

    Any ideas?

  • sageonesageone DEMember

    UWP Navigation-Bug after updating from Xamarin.Forms 2.3.1.114 to 2.3.2.127

    I'm developing a Xamarin.Forms PCL App for Android, iOS and UWP.
    I use the normal NavigationPage to manage the navigation stack.

    In Xamarin.Forms 2.3.1.114 everything runs well: Pressing the Back Button on a child page
    will return to the previous page (on all platforms).

    After updating from Xamarin.Forms 2.3.1.114 to 2.3.2.127 there seems to be a breaking change
    for UWP Apps: Now i have to press the Back Button twice to return to the previous page.
    For Android and iOS everything runs well as in version 2.3.1.114.
    This behaviour is not acceptable.

    What changes have been made in UWP navigation ???

  • EZHartEZHart USXamarin Team Xamurai

    @sageone As far as I know there were no changes made to UWP navigation which would cause the issue you're describing. Please submit a bug report at https://bugzilla.xamarin.com/enter_bug.cgi?product=Forms and we'll take a look.

  • NMackayNMackay GBInsider, University ✭✭✭✭✭

    @sageone @EZHart

    I've seen this as well, it like the UI thread freezes when you press back and it usually eventually responds. There is no non blocking code in the page pop, in most case it just clears behaviors and unregisters the binding context etc. I did see some possible performance issues with SimpleIoC in UWP but I wanted to investigate that further before raising it by swapping the IoC container. Unfortunately it's pretty random and I can't reproduce it but I've seen it many times debugging on a Lumia 650 (1GB ram).

    The issue is you press back several times and then the phone responds and before you know it you've navigated out of the app.

    No such issue in Android and iOS so it does point the finger at UWP.

  • sageonesageone DEMember

    @EZHart @NMackay

    I have invested some time to analyse the issue. Now i'm able to reproduce the bug from scratch.
    The error occurs when navigating from a ListView-Item (via event "ItemSelected") to the next page.
    The same issue occurs after displaying an alert (via event "ItemSelected").
    At latest from the second time, you have to press the Back-/OK-button twice to return to the previous page.

    I have created a simple VS2015 solution to reproduce the issue (see attachment).
    On Android and iOS everything works as expected.

    What am I doing wrong???

  • ahmedkhanahmedkhan USUniversity ✭✭

    +1 on Android Performance Issues. My last forms app had adequate performance on android, but just barely. the latest release is performing even slower on my Samsung edge S6 which is really unacceptable. I think the development teams first priority should be to address this or risk making Forms unsuitable for cross platform development.

  • sageonesageone DEMember
    edited October 2016

    @EZHart

    I have submitted a bug report:

    https://bugzilla.xamarin.com/show_bug.cgi?id=45219

    We want to deploy the app on iOS 10 devices. But with Xamarin Forms version 2.3.1.114 the app freezes in the launch screen. An update to version 2.3.2.127 would solve this issue. But then the UWP app is unusable.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @BryanHunterXam -

    I've just upgraded from 2.3.1.114 to 2.3.2.127 . A breaking change was introduced without warning in 2.3.2.127 that broke the custom image button renderers that I use on WinRT and UWP platforms.

    https://github.com/xamarin/Xamarin.Forms/pull/260

    did what is described on the PR as:

    "More descriptive class name (ImageLoaderSourceHandler → UriImageSourceHandler)"

    My code is also now broken on StreamImagesourceHandler, which isn't mentioned on that PR, but my guess is that's also in that particular PR (if not, then there's a second PR with breaking changes in 2.3.2).

    Whilst I'm not against breaking changes, these need to be highlighted at the top of the Xamarin.Forms release notes, not just hidden away on individual PRs (and possibly not even mentioned there). And, if they're basically just renames, please batch them up for major release number changes, rather than putting them in minor release number changes.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @BryanHunterXam - Actually, thinking about it some more - if changes are introduced that change the name or signature of an existing API, can they not only be highlighted at the top of the release notes, but can the previous name/signature be maintained for a while with an Obsolete attribute. In the case I hit yesterday, that would be marking ImageLoaderSourceHandler Obsolete, but leaving it as a thin wrapper around UriImageSourceHandler, until perhaps XF 2.4 when the obsolete name could be removed.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    @JohnHardman I'm not sure if they remove Obsolete APIs at all. In my opinion, they should eventually be decommissioned (maybe a year later). I see no point in having them stick around forever. I recently worked on adding X11 colors and wanted to remove a color that was marked obsolete in 1.3 because of a typo, but I was told not to remove it. See PR 393.

  • EZHartEZHart USXamarin Team Xamurai

    @JohnHardman

    marking ImageLoaderSourceHandler Obsolete, but leaving it as a thin wrapper around UriImageSourceHandler.

    This is definitely what should have happened; we'll try to be more conscientious about this type of change in the future.

    My code is also now broken on StreamImagesourceHandler, which isn't mentioned on that PR, but my guess is that's also in that particular PR (if not, then there's a second PR with breaking changes in 2.3.2).

    Same PR; the StreamImageSourceHandler name was cased incorrectly.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    Developers are overheating for sure though. :smiley:

  • KenPespisaKenPespisa USBeta, University ✭✭

    Developers are overheating for sure though. :smiley:

    Seems like some of that is due to a lack of communication. It has been awfully quiet lately and I can't tell if that is the quiet before a storm (like a major new release) or a sign that Xamarin Forms is fading away

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    @KenPespisa I think Xamarin has had a lack of communication in general. I'm not sure if this is going to change soon. I don't even know if there is a roadmap we could look at. Being an open-source project backed by MS, I'd expect to see a clear vision as to where this project is going.

    That said, if XF is fading away, what is the alternative?

    Look at the forum posts: XF 77.4K, Android 45.3K, iOS 39.9K

    This alone shows the amount of interest in cross-platform development - not to mention that XF is relatively recent compared to the others.

    If MS comes up with another technology, it HAS to be cross-platform. Asking people to write code for individual platforms is almost like regressing. Honestly, I wouldn't be too worried about something new because the skillset would generally be translatable. I'm more worried about being left in the dark as though there is no vision or interest by MS in advancing cross-platform.

    I know other people are much more heavily invested in XF, so for them, it going away is a much bigger pill to swallow.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    The problem as I see it (and the principal reason why I'm using XF) is that if I didn't use XF I'd end up having to write it. Either that, or use MVVMCross, which I have done in the past and may be forced into again.

    The problem for Xamarin is that there are some other Open Source tools on the market that do a completely stellar job of previewing changes to screen layouts, cross-platform, live. Most of them have not bothered with Windows Phone, but because they built the screen layout preview feature first, they have been able to build on their initial foundations and still have screens updated as you type/save the design despite some extensive upgrades to their toolkit. I can tell you how much time that would save me if Xamarin had it too. Honestly, it would shave days off the time it takes to build an app.

    XF is a stunning achievement. That it works at all is a minor miracle. That it works as well as it does is a great credit to the developers. I do wish though (applying 20/20 hindsight!) that they had started with the preview feature rather than trying to bolt it on afterwards. The delay between the demo at Evolve and a working implementation is I hope a reflection of just how complex that task is at the moment rather than an unwillingness or inability to finish the work.

    Unfortunately there have been a few tools that were demo'd with much fanfare that still have yet to see the light of day. The only consolation I have is that if I were to undertake that work myself I would probably take even longer to get it done. :)

  • DavidCarawayDavidCaraway USBeta ✭✭

    My $0.02

    I've refrained from adopting Forms (for now) in production apps but I am still a huge supporter of Xamarin. There are a great many developers using plain ole Xamarin.iOS and Xamarin.Android and getting excellent code reuse. I guarantee you that I spend a fraction of the time building native UI's than most here do troubleshooting and finding workarounds for Forms issues. Building an interface in XCode or Eclipse is pretty simple. Think about it. The actual UI layout is usually easy to build. It's all of the business logic behind the UI that takes the most time and effort. In Xamarin.iOS and Xamarin.Android I'm able to share the vast majority of that business logic.

    In a nutshell, writing code for individual platforms isn't all that hard when you use Xamarin's other technologies. I see no signs that Forms will meet an early death but rest assured the future is still bright if it does. If Forms ever becomes rock solid I'll adopt it. My standards for Forms stability are very high because I'm only going to gain a small amount of extra productivity when that day arrives. I see Forms as a very ambitious project that doesn't provide much added value above and beyond that provided by plain ole Xamarin iOS and Android, both of which are rock solid. Those of you really beating your head against the wall with Forms might want to give the other technologies a spin. You might be amazed by how productive you will be.

2
Sign In or Register to comment.