Xamarin.Forms Feature Roadmap

189101113

Posts

  • HopinHopin Member ✭✭

    The Device.StartTimer seems to be missing features and in need of improvement, so I am using some AdvancedTimer for now but it's an old 2015 assembly. Perhaps we just need some additional abstractions put around the Device.StartTimer so it's easier to use.

  • batmacibatmaci DEMember ✭✭✭✭✭

    @Hopin said:
    The Device.StartTimer seems to be missing features and in need of improvement, so I am using some AdvancedTimer for now but it's an old 2015 assembly. Perhaps we just need some additional abstractions put around the Device.StartTimer so it's easier to use.

    Device.StartTimer is there. i am using it currently and works perfectly fine

  • IrongutIrongut Member ✭✭✭
    Are there rough expected release dates for XF 3.5 and 4.0? (I understand they may slip)

    The next feature update to one of my apps uses Bindeable Layouts from 3.5 and I have plans for a major rewrite once 4.0 is released. I have been using the prereleases for development but regressions in 3.5pre3 mean I can't release anything until it is stable.
  • IrongutIrongut Member ✭✭✭

    @Irongut said:
    Are there rough expected release dates for XF 3.5 and 4.0? (I understand they may slip)

    v3.5 was released a few hours after I posted that question. Now that's what I call service! :D

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    Bentornato Alessandro!

  • Poz1Poz1 ITUniversity ✭✭

    @AlessandroCaliaro said:
    Bentornato Alessandro!

    Grazie :)

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    @Poz1 Agreed. Unfortunately, the team is making a lot of short-sighted decisions with respect to which direction to head. Issues on Github seem to be piling up at a higher rate than they are fixed. My biggest complaints right now are ListView and lack of 3rd-party tooling. Like you mentioned, XF cannot handle images properly, and I run into critical problems with FFImageLoading. Animations aren't as smooth as I'd like. The current implementation of Span is buggy and has performance problems. Even the good, old Grid has calculation problems with Auto heights. While I can find workarounds for small issues, I can't easily circumvent these without completely changing the UI.

  • Poz1Poz1 ITUniversity ✭✭

    @AdrianKnight The saddest part is that in almost a month no one even bothered to show that we may be seeing it wrong :|

    Seems like just no one cares.

    In these few days I was also able to appreciate that the Entry Control still does not uses TextInputLayout (Android), that we still have no CheckBox, that the Grid calculation are a total mess (as you said), that we have tons of properties that are apparently ignored or simply meaningless (!) and that most of the things that one were provided by external libraries are now old, and likely to be broken (as they should be).

    When it all started for me, and we are talking of when we had padding only and no margin ( :s ) in Forms components, Xamarin was the new solution to all problems, that was still a lot incomplete and buggy because it was new.

    The community started providing the missing functionality, I did NFCForms to allow devices to use NFC directly from Forms, but it was obvious that these basic feature had to be in the XamarinCore!

    How can you believe to build a framework on libraries provided by people that share a piece of code that will probably not be ever maintained or updated?

    Basically right now Xamarin (at least Forms) is almost the same of 2 years ago, maybe more.

    So the question is, do you really want to waste your time building your future apps with it?
    As I am now creating the nth "customrenderer" say: If I had done it full native I would probably written the same code, wasted much less time against Forms bugs and got a much more speedy app.

    I am afraid this may be my last project written in Xamarin. I cannot stand it anymore.

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    @Poz1 said:
    @AdrianKnight The saddest part is that in almost a month no one even bothered to show that we may be seeing it wrong :|

    Seems like just no one cares.

    In these few days I was also able to appreciate that the Entry Control still does not uses TextInputLayout (Android), that we still have no CheckBox, that the Grid calculation are a total mess (as you said), that we have tons of properties that are apparently ignored or simply meaningless (!) and that most of the things that one were provided by external libraries are now old, and likely to be broken (as they should be).

    When it all started for me, and we are talking of when we had padding only and no margin ( :s ) in Forms components, Xamarin was the new solution to all problems, that was still a lot incomplete and buggy because it was new.

    The community started providing the missing functionality, I did NFCForms to allow devices to use NFC directly from Forms, but it was obvious that these basic feature had to be in the XamarinCore!

    How can you believe to build a framework on libraries provided by people that share a piece of code that will probably not be ever maintained or updated?

    Basically right now Xamarin (at least Forms) is almost the same of 2 years ago, maybe more.

    So the question is, do you really want to waste your time building your future apps with it?
    As I am now creating the nth "customrenderer" say: If I had done it full native I would probably written the same code, wasted much less time against Forms bugs and got a much more speedy app.

    I am afraid this may be my last project written in Xamarin. I cannot stand it anymore.

    Which is the second choice?

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @Poz1:
    I agree with you...
    As you wrote, I also have invested a lot of time in Xamarin over the last few years and see no (or only a litte bit) progress (.forms is far away to be a complete framework right now)
    I would check out flutter, if I would find the time...

  • JamesLaveryJamesLavery GBBeta, University ✭✭✭✭✭

    The paradox here is that we (in general) are able to produce good quality apps with Xamarin.Forms - some of us seem to find endless workarounds are needed, while others don't. Is it that the former are implementing more complete solutions while the latter are not going deep enough?

    I've found Forms to be very productive, and haven't found show-stopping bugs.

    This isn't a criticism of those who are frustrated and considering dropping Xamarin, just an observation. I agree that it's frustrating that bugs just don't seem to get fixed!

  • CharlesRoddieCharlesRoddie USMember ✭✭

    @AdrianKnight they have spread themselves out too thin

    Agreed. Too much feature-creep in Xamarin.Forms. And they have a bad philosophy of not making breaking changes so technical debt just accumulates, and they keep adding things without getting existing features to a good level of quality. Too much of the mono philosophy. Bindings, css, shell, navigation... none of these are needed IMO.

    That said most of the specific controls mentioned have actually been improved or work is well underway to improve them.

    ListView: being replaced with CollectionView.
    Checkbox: in progress https://github.com/xamarin/Xamarin.Forms/pull/4369
    Switch color: this can be changed since 3.1 apparently

  • Sumit_SharmaSumit_Sharma USMember ✭✭✭

    @CharlesRoddie said

    Bindings, css, shell, navigation... none of these are needed IMO.

    Totally agreed on above.

    I believe I should have posted this here as no one from Xamarin Team has replied or It might have been missed by Xamarin Team...

    https://forums.xamarin.com/discussion/156412/xamarin-forms-support-general-discussion

  • deczalothdeczaloth DEMember ✭✭✭

    I really enjoy making apps using Xamarin.Forms and C#, and had no reason to look for other alternatives, but since the Xamarin Team is too quiet to basic questions as "the on-going support for UWP", to name just one, i am really considering to choose another cross-platform framework for my next App... Too much secrecy is not doing any good to the old good Xamarin...

  • batmacibatmaci DEMember ✭✭✭✭✭

    I would like to see android app bundles in xamarins roadmap. This will be game changer for us. Currently if you need good performance and startup time, you must use aot and llvm but these increase you app size and we need to cut this down. App bundles seems to be only way to achieve it for xamarin. But I dont hear any interest on this theme.

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @batmaci
    There was/is a big interest here (performance ans startup) from the customer side and Xamarin has pinned this goal as major target for new releases of .forms. But - as mostly - not reached and now... silence (similar - e.g. - to the for years missing simple popup control).
    It seems as all not trivial stuff find the way to the trashcan, but therefore it's worked on "rounded corners" and similar things...
    It's a real shame... :'(

  • GiampaoloGabbaGiampaoloGabba USMember ✭✭✭
    edited May 24

    I remember one or two year ago when they posted great plans to improve android performance a lot but then, things have changed. A lot of effort was put on things like css, shell, visual, previewer ecc...
    It's great to have new, shiny, things but i think that stuff like Android performance and app size, hot reload, a full featured CollectionView, more control on gestures/transitions/scrolling effects are all basic things that should have been worked out before :)

    Take the CollectionView for example: it's a really great control! But they sipped it without scrolling events, refreshview, swipe context commands... Wouldn't be better to just ship a finished, polished control and then move to another feature?

  • JoeMankeJoeManke USMember ✭✭✭✭✭

    @GiampaoloGabba At least they're not calling the CollectionView stable yet.

  • GiampaoloGabbaGiampaoloGabba USMember ✭✭✭

    @JoeManke said:
    @GiampaoloGabba At least they're not calling the CollectionView stable yet.

    uooops, you are right! i was sure that CollectionView was part of the first 4.0 stable but is still in preview :)

  • DavidGerding.4136DavidGerding.4136 USMember ✭✭

    I'm going to throw in two cents here... First, add UWP (or whatever Microsoft is going to support for UX moving ahead) to the new shell thing or drop the shell thing. The 2019 roadmap seems so... timid? Especially in the context of all the pain points that keep surfacing over and over.

    I don't understand why MS is alienating all these long-time MS-friendly developers. I know they want to sell Azure... but UX is the gateway to services, no?

  • JKayJKay USMember ✭✭✭
    edited June 19

    Been working with Xamarin.Forms for 5 years

    Some real fundamental things missing from Xamarin Forms, which seem really simple but would make a huge difference to general app development:

    1. Absolute layout with Landscape and Portrait bounds - Out of the box Xamarin Forms provides a horendous experience in designing applications to work in both landscape and portrait. Most sample apps are designed on phones where this isn't a problem, as soon as you put it on a tablet and display it landscape your application looks stupid. An easy and optimised way to provide different layouts in different orientations

    2. Delayed Views - Initial feedback to our application was "responsiveness is slow" this was because on pushing a button we pushed a page which would call InitializeComponent and would take 0.5-1 seconds to render complicated views. To work around this we created a view that would be completely empty and hold a datatemplate that would start initialising as soon as the page was displayed - Yes this is probably slower overall but that initial feedback to show its doing something is far more important.

    3. Page Animations - We actually ended up ditching Xamarin Forms page navigation all together, having a page snap in from nowhere gives a horrendous UX. We instead replaced it with RG Popup page simply for animations

    4. Invisible views still layout - One thing we noticed was that eventhough a view was invisible (i.e. IsVibisle = false) the measure and draw was still happening (on android at least) commenting a complex view out (that was set to invisible) had a huge performance boost. We, therefore invented another delayed view to show the screens quicker and take the drawing hit at time when visibility changes on the view

    All the points above are fundamental to xamarin forms but instead we are getting Shell and collectionviews - which are completely unimplemented on UWP making it useless for anyone looking to develop for all 3 platforms.

    I guess the bottom line is this Xamarin.Forms needs more resources, which in turn means more money/investment

  • BrainfuryBrainfury Member ✭✭

    thanks for sharing

  • JohnHJohnH GBMember ✭✭✭✭✭

    @JKay said:

    My understanding is that views with IsVisible false are not rendered.

    Based on that I presume you are using XAML for your complicated views, but are you compiling them? If not, there is an initial inflation cost that must be paid regardless of whether a view is visible or not. Commenting out large sections will improve the inflation time, but isn't a true reflection on the cause of your issue.

    We build our views in code, and they are instant. If we used XAML for our views and compiled them, performance would be the same.

  • JKayJKay USMember ✭✭✭
    edited June 21

    @JohnH said:
    My understanding is that views with IsVisible false are not rendered.

    This would seem logical but my tests don't prove this at all.

    I'm using XAML to construct my views, I've got compiled XAML turned on.

    I've attached a view to prove my point which contains hundreds of labels. Construct this view and push it to the stack using:

            var view = new VisibilityTest();
            this.Navigation.PushAsync(view);
    

    The above line of code took 5 and a half seconds on my device, regardless of whether you set IsVisible = True or false on the root layout.

    This view also proves another point I mentioned

    Delayed Views: pushing this view takes 5 seconds to initialise... 5 seconds for the user to wait for a page to appear!! obviously this is an extreme example but anything greater than half a second is bad UX, hence why we've used DelayedViews and datatemplates

    Test out the View and let me know if you get the same 5 second delay to push this view even with isvisible = false

  • JohnHJohnH GBMember ✭✭✭✭✭
    edited June 21

    @JKay
    I cant test that right now, but could you try disabling the XAML compiler for that view and see how much slower it is?

  • GiampaoloGabbaGiampaoloGabba USMember ✭✭✭
    edited June 21

    @JKay i think you should open an issue on Github for this, attaching your test project, a view with IsVisible=False should not trigger a layout.

    However we can already manage Delayed views with a little effort. This awesome blog post explain how, i have already tried it and is working very well: https://www.sharpnado.com/xamarin-forms-lazyview-boost-your-app-reactivity-and-startup-time/

    Sure, it would be better to have such a function inside the core, instead of questionable things like css, shell, ecc...

  • JKayJKay USMember ✭✭✭

    @JohnH With XAMLC turned off it takes 9.5 seconds so XAML C is definitely doing something

    @GiampaoloGabba I currently dont have time to file a github issue. The most annoying thing is that this is really simple.

    My view is:

     <StackLayout IsVisible="False">
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
                <Label Text="Welcome to Xamarin.Forms!" VerticalOptions="CenterAndExpand" HorizontalOptions="CenterAndExpand" />
    .
    .
    . x400
    </StackLayout>
    

    And it takes about 5 seconds to push that page.

    As this is IsVisible=False I would expect it to be instant.

    However we can already manage Delayed views with a little effort. This awesome blog post explain how, i have already tried it and is working very well: https://www.sharpnado.com/xamarin-forms-lazyview-boost-your-app-reactivity-and-startup-time/

    We have invented a control similar to this, the annoying this is that we've had to do our own research and invent this control. It should be out of the box and in all the samples as a design pattern

  • batmacibatmaci DEMember ✭✭✭✭✭

    IsVisible=false views are rendered on android and uwp. I havent tested on ios but most probably also Somebody claimed that it is only working on UWP https://github.com/xamarin/Xamarin.Forms/issues/6536
    But till 3.6 version It is not working. I have tested myself and it is there. You can simply check using bannerads, you will see that it will be refreshed frequently even it is isvisble false

  • JohnHJohnH GBMember ✭✭✭✭✭

    @batmaci said:
    IsVisible=false views are rendered on android and uwp. I havent tested on ios but most probably also Somebody claimed that it is only working on UWP https://github.com/xamarin/Xamarin.Forms/issues/6536
    But till 3.6 version It is not working. I have tested myself and it is there. You can simply check using bannerads, you will see that it will be refreshed frequently even it is isvisble false

    Hmm, maybe that is something resolved with the Android fast renderers which are now default in XF 4?

  • JKayJKay USMember ✭✭✭

    Some extra feedback on the subject of performance...

    Label padding: https://github.com/xamarin/Xamarin.Forms/pull/6299 would be a great feature to merge. The work has already been done.

    The number of times I have

    <ContentView BackgroundColor="Blue">
          <Label Margin="5" Text="I wish I could have a background colour and 5 pixel padding"/>
    </ContentView>
    

    Every view added is a performance slowdown

  • AnthonyRamirezAnthonyRamirez USUniversity ✭✭✭
    edited June 30

    I've been meaning to post this...

    I've also found that an ImageView on Android with IsVisible = false (Legacy Renderers...not sure about Fast Renderers) will cause the Android Bitmap to be inflated using the full device's full screen size (even if the image was set to a smaller size) causing a large amount of memory to be consumed. This was found while profiling.

    As a workaround, I implemented a ImageView custom renderer which will not set the ImageSource unless Visibility is true. This saves tons of memory and stopped OutOfMemoryErrors from being generated.

  • JKayJKay USMember ✭✭✭

    On the topic of orientation aware mobile apps one of the most useful ways to do this is AbsoluteLayout coupled with Visual State manager.

    The one problem is that AbsoluteLayout logic is so complicated with its moving anchor point.

    Can anyone decrypt this documentation: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/absolute-layout#proportional-layouts

    AbsoluteLayout has a unique anchor model whereby the anchor of the element is positioned relative to its element as the element is positioned relative to the layout when proportional positioning is used.

    Unique is definitely the right word here, although I can think of a few others

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    I know that several people are concerned about UWP support. My suggestion would be delegating this responsibility to another team at Microsoft (if at all possible) so the Forms team can focus on iOS and Android first and foremost. This would be similar to how Tizen support is being handled today. While I understand the attractiveness of the idea of being able to develop for many platforms, most people who use Forms develop for iOS and Android, in my opinion, and these require a lot of work to do already.

  • batmacibatmaci DEMember ✭✭✭✭✭

    @AdrianKnight do they have separate team for Tizen support?

Sign In or Register to comment.