Xamarin.Forms Feature Roadmap

16791112

Posts

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Good conversation, and I appreciate all the comments about the future of our platform and how the competitive landscape is shaping up. I'm soaking it all up.

    This thread exists to not only share what we are planning and working on, but to hear your frustrations and thoughts. I suppose that sometimes means drama, and that's ok.

  • NMackayNMackay GBInsider, University mod
    edited July 2017

    @DavidOrtinau said:
    Good conversation, and I appreciate all the comments about the future of our platform and how the competitive landscape is shaping up. I'm soaking it all up.

    This thread exists to not only share what we are planning and working on, but to hear your frustrations and thoughts. I suppose that sometimes means drama, and that's ok.

    @DavidOrtinau Maybe it's the summer but the engagement from the team to the community has dropped of a little publicly in the last few months, it's been really good since you took over and community engagement has never been higher, as we have little support (sorry to say but MS support is poor...as an enterprise customer), we rely on this place to hear our voice.

    An updated roadmap (it has slipped), some focus on optimising apps to benefit from new features 2.35.x performance optimisations, Forms still is treated a little like a beta project but it's now very much used for production use.

    Also, features like native embedding have been blogged about but XamlC support has been missed (it was promised), will it happen and if not then make us aware so we can invest time or not in this feature, as it stands it's not fit for production usage.

    Lastly, the samples (renderer samples are out of date) and documentation desperately need some attention.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Hi @NMackay,

    I expect to be able to update the roadmap in the first week of August. At that time I can answer more specifically where we stand on XAMLC support for native embedded views.

    As I noted previously, our work since Build has been on bug fixes, bug fix PRs, and QA processes. Yes, it's summer and that means holidays and vacations, etc. I hope that although there may have been a reduction in communication here, there has been an increase in communication on Bugzilla issues.

    If there are specific docs and samples that you see are out-of-date, send me links and either I can update them or put in a request with the docs team. I just updated a couple yesterday.

  • NwikNwik PTMember ✭✭

    Hi @DavidOrtinau, can you tell us anything about NetStandard 2.0 support?
    In your original post says that this is estimated for Q3, is this still valid?

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    @DavidOrtinau said:

    @MichaelRumpler said:
    This is probably not the correct place, but I couldn't find any other info about the MenuPage in the evolution forum or the github pull requests.

    The MasterDetailPage can use the Master as a flyout so that it overlaps the Detail or they can be shown side by side when you use MasterBehavior=Split. Then the Detail width is not the full page width.
    What I am missing is that the user can swipe in/out the Master and the Details width is adjusted to be the rest of the page. The two pages should not overlap, but the user can still decide whether he wants to show the Master (Detail has less space) or not (Detail has full width).
    Maybe you can design the MenuPage so that it supports this (or enhance the MasterDetailPage).

    Where would be the proper place for this? In the evolution forum? In UserVoice? In the forms-devel mailing list? In Bugzilla? I still don't get the difference. You have too many tools!

    Yes, we want to have those kinds of conversations in the Evolution forum. We need to get our thoughts out there as we did yesterday with Accessibility so it's not just a mention on the Roadmap. And we didn't want to further delay the Roadmap. So, give me a bit to make that happen.

    Half a year later I still can't find a post in the Evolution forum about the MenuPage. I'd really like to add some ideas of mine and see if they can be implemented.

  • fabiorfabior USMember ✭✭
    edited July 2017

    I must admit, I'm not happy at all to say the least.

    I thought seeing the XF team carelessly close bugs on Bugzilla or PRs is history now. I thought it won't happen again.
    But here's just one example of closing a PR which happened very recently:

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

    If you have enough experience writing real apps, you know how important and useful are TargetNullValue and FallbackValue.

    Someone spent their time on that PR. Why was that PR closed so easily?

    We definitely consider adding this to the binding system, but not right now.

    Seriously? Consider it to add it when? Hello!? Xamarin Forms is over 3 years old. How much time do you need to add such basic features to the framework?

    Seeing the Xamarin Forms roadmap with "CSS-like" and other crazy features while very basic but useful features like TargetNullValue and FallbackValue still do not exist, frankly, this shows how disconnected the people leading the Xamarin Forms team are from what developers really need in day to day work.

    And this is just one small example. Want another example? Here's this one: https://github.com/xamarin/Xamarin.Forms/pull/869

    And there are more...

    Frankly, by now it's clear to me that Xamarin created a XAML framework but has no idea what they are doing...

  • PhilipGruebelePhilipGruebele USMember ✭✭

    @fabior To be fair looks like the second example you mention https://github.com/xamarin/Xamarin.Forms/pull/869 is waiting on the requester to undo formatting changes, so the delay is currently not Xamarin's doing.

  • fabiorfabior USMember ✭✭
  • JohannesWlflJohannesWlfl DEMember ✭✭

    Hi all.

    @DavidOrtinau : in your blog post "5 Ways to Boost xamarin forms startup time" you mentioned:

    _Reduce Number of Assemblies _ ... Xamarin.Forms for example inspects all assemblies for [ExportRenderer] attributes and currently has no method to opt-in or opt-out. This is something we’re working to improve.

    Is this something you're actively looking into?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @JohannesWlfl we have discussed [ExportRenderer] and it's in our 3.0 backlog to address.

  • fabiorfabior USMember ✭✭

    @DavidOrtinau I hoped you won't ignore my comment. That's a real issue, something tangible.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @fabior not sure which comment. You'll get better engagement if you would please refrain from inflammatory statements like has no idea what they are doing. It's difficult to determine what is you blowing off steam (we all get frustrated, that's fine) and what is something to be actually discussed and that will be well received.

    re: PR 664 being closed swiftly, it was also reopened swiftly and kept open with little movement. It's been closed because it's breaking and as such isn't in a condition to be considered further.

    If you'd like to contribute to making this PR acceptable, we can see about moving it forward.

    Someone did spend time on the PR, and we definitely don't want anyone to feel their time was wasted. This is one reason we have the Evolution forum to make proposals before a bunch of effort goes into a PR that we cannot or will not take. I don't see any Evolution post related to this PR. Unfortunately, effort spent doesn't mean any PR should be accepted except on the merits of the PR.

    As the PR indicates, this can be done in other ways, so while Xamarin.Forms doesn't implement it, it's still doable by you.

    CSS as crazy. It's not something you consider useful or basic, that's fine. Other devs have expressed it will be extremely useful and productive to them.

    Re: being disconnected from what developers really need, I talk to 2-3 customers a week about how they do their work with Xamarin and Xamarin.Forms and other products. I myself have been a freelancer, consultant for 20 years working with a wide variety of dev shops, creative agencies, startups, enterprises, etc.; as is the same with many on our engineering team. I'd love to hear about your workflow and experience and how we can better support you, so perhaps we can set up a call. If you're interested, email me.

    re: 869, I posted this elsewhere, but we have been in an API change, feature freeze as we focus specifically on bug fixes. I know multiple merged dictionaries is something that many people want, and I'll see what I can do to move it forward.

  • fabiorfabior USMember ✭✭
    edited August 2017

    @DavidOrtinau

    I don't have by any means the purpose to write "inflammatory" comments. Yes, I'm frustrated because I wish Xamarin Forms was better.

    I get it, the PR 664 for the TargetNullValue and FallbackValue it's breaking. OK. But my point really is, why isn't the team considering adding this kind of basic binding features?

    And about PR 869 (Merged dictionaries), you're saying, I quote
    "I know multiple merged dictionaries is something that many people want, and I'll see what I can do to move it forward"

    I think this is a problem. You have to see what you can do to push another basic features to get implemented. Shouldn't be obvious it's much useful? Merged dictionaries allows you to write bigger apps and enable reusability.

    Also, you say how much you'd like to hear about my workflow. Well, my workflow is to be able to use the same basic framework features I've been using in the XAML ecosystem (WPF, Silverlight, WinPhone, WinRT, etc.).

    Another thing: when are "fast renderers" going to be fixed and implemented to cover all controls? It's yet another thing which it's half baked.

    You think my comments are just inflammatory and have no real substance. I am sorry you think that.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Hi All,

    I have an updated draft for the roadmap. Once I get a review and sign off, I'll share it. Look for that next week.

    Re: our next stable release, I understandably get a lot of questions about it. Here's the current status:

    We have identified a handful of regressions and changes we need to introduce before 2.3.5 can be stable. In the course of evaluating the changes we determined this is more substantial than the 2.3.5 versioning indicates and we need to renamed this as 2.4.

    We have a handful (4 at present and 1 coming) of pull requests that need to be reviewed and merged before we can publish. Once those are ready we will submit to QA and then publish a new pre-release. Ideally that will happen next week, not additional regressions will be identified, and we can promote that build to stable within another 2 weeks.

    In 2.4, Fast Renderers will be disabled by default and made internal because they are going to be changing as we refactor our renderer architecture. Once we are done with the refactoring and implementation, we'll expose them. Because the feedback has been excellent in terms of performance benefit, you can still enable them in your application via a new Flags API. More details to come.

    Ok, I think that's it for now. I know many of you are eager for an update here, and I'm eager to share.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    You think my comments are just inflammatory and have no real substance. I am sorry you think that.

    @fabior not "just". I'm trying to be helpful and understand your position. I hope you can hear that in my tone.

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @DavidOrtinau

    "Because the feedback has been excellent in terms of performance benefit, you can still enable them in your application via a new Flags API"

    Where can we see the "excellent feedback" to the "Fast Renderers"?
    And a really useful feedback would be nice (e.g. page with n'nnn texboxes takes without "Fast Renderers" nn seconds but with "Fast Renderers" n seconds, and the same for other examples like show a Listview with nnn entry's).
    I think, that would be interesting for every developer (and what I would expect from the thread "let's talk about performance" instead of the actually posted information's).
    Thanks

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai
    edited August 2017
    Hi @FredyWenger,

    Twitter, forums are public. As I mentioned I'm talking to customers every week, and this is in large part what I'm hearing. Those are private conversations so unless they publicly share their findings I'm going to respect that privacy.

    The performance thread is to foster open conversation about all things performance. I've found the conversation quite useful and hope it continues. Perhaps you could contribute a report like you suggest.
  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @DavidOrtinau

    Your posting from April 13:

    “One of the initiatives I'm spearheading is to populate a solution with UIs that are representative of your applications.”

    To have useful information’s a reference app should be created by Xamarin
    The app should contain buttons to do “representative” tests like:

    • Label test (e.g. add 2’000 labels on a StackLayout in an ScrollView and set some text on it)
    • ListView test 1 (e.g. show a ListView with 2’000 text entries)
    • ListView test 2 (e.g. show a ListView with 2’000 text entries and images)
    • Button test (e.g. show StackLayout in a ScrollView with 1’000 Buttons)
    • StackLayout test (e.g. create a very complex nested StackLayout)
    • and so on..

    This app should be frozen (once finished) and tested with new .forms versions, the results should be published with new versions.
    That would be useful information’s.

    The performance thread should document the performance progress of .forms in a comprehensible manner...
    AOT (that blast the apk) is no solution (and not what I expect in the performance thread)

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai
    @FredyWenger I appreciate your advice and welcome your contribution.
  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @DavidOrtinau
    ... so follow your words and let the Xamarin engineers create such an app :sunglasses:

  • DnielBugaDnielBuga USMember ✭✭
    edited August 2017

    @DavidOrtinau said:

    We have identified a handful of regressions and changes we need to introduce before 2.3.5 can be stable. In the course of evaluating the changes we determined this is more substantial than the 2.3.5 versioning indicates and we need to renamed this as 2.4.

    We have a handful (4 at present and 1 coming) of pull requests that need to be reviewed and merged before we can publish. Once those are ready we will submit to QA and then publish a new pre-release. Ideally that will happen next week, not additional regressions will be identified, and we can promote that build to stable within another 2 weeks.

    Hey,

    this is cool, but does this mean that bugs already fixed but not pulled to the current 2.3.5 branch will be included as well? Specifically: pr 891 I reported it more than 3 months ago, it was a simple, almost one-liner fix and it got merged into master, but did not make into any of the 2.3.5 previews. I find this really annoying. I also have 2 issues currently open and confirmed (almost 4 months old issues) in bugzilla, with seemingly nothing being done about. Yes, one of those is a minor inconveniance, a visual glitch (bz 55135), but the other one (bz 56274) is a reliable crash caused by a usage pattern that would require me to rewrite a lot of code to work around.
    I don't know why these things are basically left to rot, maybe they are just so far buried below other tasks, and I understand that. But I really hope you guys don't plan to release XF while you have "CONFIRMED - critical" issues open in BZ.

    To quote from the opening post: "Improving quality by addressing bugs is huge priority and ongoing focus for the team". I really hope this is the case and not just words. XF is a really fun, extremely powerful framework but the number of issues and the reaction time to reported issues is what makes it frustrating (for me at least) to use.

  • fabiorfabior USMember ✭✭
    edited August 2017

    @DavidOrtinau Why did you mark this as RESOLVED ?
    https://bugzilla.xamarin.com/show_bug.cgi?id=41404

    Seriously, why are you guys marking issues which are actually BUGs with RESOLVED status, when in reality, that's still an issue?

    What is your ACTUAL\TODO bug list? It's not public assume?

    You commented with "This is working as designed". You mean a design which lets the master go over the status bar? How come that is "the design".

    You google for a minute, you'll see a lot of any people have been asking about this.
    To fix it, I assume almost everybody just chose the quick and dirty solution to put some padding at the top so that the menu doesn't seem it's hovering the status bar (or on Android used the translucent style).... But this is NOT the correct solution....

  • fabiorfabior USMember ✭✭
    edited August 2017

    @FredyWenger said:
    Your posting from April 13:

    “One of the initiatives I'm spearheading is to populate a solution with UIs that are representative of your applications.”

    To have useful information’s a reference app should be created by Xamarin
    The app should contain buttons to do “representative” tests like:

    • Label test (e.g. add 2’000 labels on a StackLayout in an ScrollView and set some text on it)
    • ListView test 1 (e.g. show a ListView with 2’000 text entries)
    • ListView test 2 (e.g. show a ListView with 2’000 text entries and images)
    • Button test (e.g. show StackLayout in a ScrollView with 1’000 Buttons)
    • StackLayout test (e.g. create a very complex nested StackLayout)
    • and so on..

    This app should be frozen (once finished) and tested with new .forms versions, the results should be published with new versions.
    That would be useful information’s.

    The performance thread should document the performance progress of .forms in a comprehensible manner...
    AOT (that blast the apk) is no solution (and not what I expect in the performance thread)

    I was also asking for the same kind of info. Any serious product has this kind of tests.
    Xamarin is talking about things like "FAST" renderers when in fact they either incomplete or broken.

    I seriously don't understand what's wrong with Xamarin and Xamarin Forms. Why doesn't Xamarin want to put some serious effort into Xamarin Forms?
    What is Jason and other people doing during the day? Jason is not working on Xamarin Forms anymore for years I think.

  • sirmaksirmak TRBeta ✭✭

    Calm down guys, wouldn't it be better if we were constructive a bit ? Yes, there're lots of problems (and I hate xaml) but there isn't any other tool on earth like xamarin forms.

    Other alternative is in a worse situation: https://github.com/facebook/react/issues/10191

  • fabiorfabior USMember ✭✭

    @sirmak said:
    Calm down guys, wouldn't it be better if we were constructive a bit

    Why do you think this isn't constructive?
    I pointed out tangible problems, even links to PRs. What is wrong with that?

    @sirmak said:
    Yes, there're lots of problems (and I hate xaml)

    Errr, you hate XAML? That explains everything :)

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @DnielBuga that fix PR891 is in 2.4. There were about 50 fixes tagged for a 2.3.6 release and we merged those to make this 2.4.

  • DnielBugaDnielBuga USMember ✭✭

    @DavidOrtinau said:
    @DnielBuga that fix PR891 is in 2.4. There were about 50 fixes tagged for a 2.3.6 release and we merged those to make this 2.4.

    Thank you. I was certain it would arrive but it was weird to see that a bug reported for 2.3.5 was not merged for the later previews for 2.3.5. Anyhow, hope to see 2.4 come soon.

  • PaulBrennerPaulBrenner USUniversity ✭✭

    @DavidOrtinau, do you have an ETA on when the team is going to look at this almost 2 year old bug? Also, the code change in this PR is pretty small, any chance it could get merged soon? Thanks

  • LGMaestrelliLGMaestrelli BRMember ✭✭✭
    edited August 2017

    I agree with @FredyWenger
    How fast XF has become with the new fast renderes and other improvements?
    If the old version took 14 seconds to open the app and now takes 13 seconds, it is faster, but not fast enough.
    And I also agree that enabling the AOT is not the cure, it is just a band-aid that will inflate the apk size (and it is already big).

    It is possible to test the new performance on some XF apps made by Xamarin?
    So we can have a base line with out wondering with it is our code and libs that slow down the app.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @PaulBrenner said:
    @DavidOrtinau, do you have an ETA on when the team is going to look at this almost 2 year old bug? Also, the code change in this PR is pretty small, any chance it could get merged soon? Thanks

    Paul, I'll look into those and have the ticket updated.

  • VelocityVelocity NZMember ✭✭✭

    @DavidOrtinau Thanks for the update. We appreciate the focus on maintaining stability.
    We have found XF 2.3.5 still a little flakey with the new fast renderers, so are happy these will be disabled by default until the remaining issues can be ironed out.

    XF 2.3.4 is currently the most rock-solid foundation we have built on yet, so we were hesitant to see any step backwards.
    Thanks for the hard work. Look forward to testing the initial XF 2.4 pre-release.

  • JKayJKay USMember ✭✭✭

    @ClayZuvich +1

    This is Microsofts best shot at Cross-platform no doubt and in my eyes Microsofts best shot at keeping their "store" alive. Without Xamarin.Forms I doubt alot of developers would even look twice at UWP, it would just be Android and iOS

  • VincentwxVincentwx CAMember ✭✭
    edited August 2017

    @DavidOrtinau Can you share any process on WPF and GTK backend support? I saw them on this road map due in Q3. We are planning a Point of Sale system on all devices, the WPF support is particular import to cover windows 7. If those two are coming, plus the current iOS, Android, UWP and MacOS, Xamarin.Forms will be a very good fit for our project.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @Vincentwx GTK is looking really strong. @jsuarezruiz has been crushing it!

    https://github.com/jsuarezruiz/forms-gtk-progress/blob/master/Gallery.md

    WPF I need to get an update on.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @ClayZuvich appreciate that.

    By most all indications I see things are going strong! In the forums here we are more focused on the things that need improvement, and thus the conversation tends to be more cynical. It's good to be reminded of the positive, productive, useful things we are enabled to do with this tech!

    https://m.signalvnoise.com/highrise-3-0-for-ios-c0fe0a29d469

  • sirmaksirmak TRBeta ✭✭

    @fabior I should sent my last message from a fake account :smiley:

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    @DavidOrtinau

    Your posting from July 12:

    I expect to be able to update the roadmap in the first week of August.

    When can we expect an update?

  • piecypiecy MYMember ✭✭

    release date of xamarin.form 3.0?

Sign In or Register to comment.