Q3 2017 Xamarin.Forms for macOS Preview
Q4 2017 Xamarin.Forms for GTK# Preview
Q1 2018 Xamarin.Forms for GTK#, Xamarin.Forms for macOS
Backlog Xamarin.Forms for WPF
This timeline is still there in the first post and is still insane. This IS a decision-making problem in Xamarin. The management is clearly planning for an alternate reality in which Mac and Linux dominate the desktop. Just look at the wpf github fork to see how little attention wpf is getting.
@CharlesRoddie said:
Q3 2017 Xamarin.Forms for macOS Preview
Q4 2017 Xamarin.Forms for GTK# Preview
Q1 2018 Xamarin.Forms for GTK#, Xamarin.Forms for macOS
Backlog Xamarin.Forms for WPF
This timeline is still there in the first post and is still insane. This IS a decision-making problem in Xamarin. The management is clearly planning for an alternate reality in which Mac and Linux dominate the desktop. Just look at the wpf github fork to see how little attention wpf is getting.
This is too bad: the part of Windows in enterprises is still important, and Windows 10 is only about the half of the Windows part...
Some customers have contacted me as they were interested by a "full" cross-platform app: Windows (from 7 to 10), iOS and Android.
Bugzilla seems to be growing bigger with over 500 bugs once again. We have bugs that were reported more than 3 years ago. I know that some might be duplicates or no longer valid, but it's also true that waiting literally years for things to be resolved does not sound good on Xamarin's part. Also, we have a lot of old PRs.
Can you publish a Bug Resolution Roadmap and Timeline similar to the features one (this one) so that we know what to expect with regards to which bugs will be resolved and when? There should also be a way, in my opinion, for people to vote/discuss so we identify high/medium/low-priority items. There should be a rule, for example, that only bugs that appeared prior to any of the current (-pre) releases can be on the roadmap so the (pre-)release bugs can be discussed on their dedicated threads.
I agree, I'm watching and not loving the overall count rising. It's a casualty of pushing out more releases more frequently it would seem. I've discussed it with the engineering team and we've already started allocating more effort to bugzilla reports.
I prioritize bugs based on severity (crashes, blocking issues, workaround availability, etc.) and impact (platforms affected, number of customers affected, etc.).
Which bugs in particular would you like me to review?
The best way for people to "vote" on bugs affecting them is to follow (join the cc list) the bug reports and supply reproduction projects where they are lacking. The quality of actionable reports incoming has been poor. It vastly slows down our triage process, and hinders our ability to see and fix issues.
For me, a higher priority item would be any confirmed bug pertaining to memory leaks, Listview issues, inconsistencies in the navigation stack, font issues, and any binding problems.
Just looking at the titles on the current confirmed list (and I'm going to assume they either need fixing or to be tested on v2.5+):
Memory leaks:
31171: NavigationPage.PopAsync() cause memory leak by still holding on popped Page 43583: [Android] ListViewRenders leaking 60492: Memory Leak when using Platform.CreateRenderer() 52252: Navigationstack is not getting smaller when removing the last page (currentpage) when a modal page is in view
Listview:
29712: listview datatemplate is not correctly reusing cells, and is waisting performance/memory for nothing 37126: ListView with custom ItemTemplateSelector not updating Background binding in ViewCell 37757: iOS Listview mess with scrollposition after navigation to another page on iOS 40432: iOS ListView is scrolling to the wrong ViewCell after a call to ForceUpdateSize. 41982: ListView binding cannot work correctly in RecycleElement mode 43427: [iOS] Margins Set on ListView Header and Footer Are Rendered Incorrectly 44525: Xamarin.Forms Listview Row Height Does Not Update When Changing Content Size (such as label) 45182: IndexOutOfRangeException when attempting to update an ObservableCollection bound to a ListView within a background thread. 45206: ListView Scroll problem when add a item. 45327: ListView Header disappears when items are added on iOS 45929: ListView ItemTemplate do not change height based on content 46286: ListView incorrectly showing items IsEnabled property after ItemsSource is reset 52430: ListView with HasUnevenRows doesn't auto fit to Image created with ImageSource.FromStream 52979: [iOS] ListView with RowHeight does not fill available height when inside nested StackLayout 56298: Changing ListViews HasUnevenRows at runtime on iOS has no effect
The issues around Listview seem to be much more than these ones. Text-searching 'ListView' on the confirmed list shows 98 mentions. Considering lists are the most important UIs in virtually every modern app, I think the team should focus on creating a more stable ListView.
Also, there are some small (maybe big to some) issues like InitializeComponent(). It's been years since I saw squiggly lines under this method. It's present in VS2017 as well. Not sure if this is something the VS team needs to fix. Oftentimes, I also run into cases where custom renderers on Android create compilation issues because the compiler can't recognize the using statements.
40666: "The name 'InitializeComponent' does not exist in the current context" VS IntelliSense error due to missing .g.cs file if you manually delete the obj folder and then reload the solution
I fully agree with your last paragraph. I think this also partially has to do with the way Bugzilla functions. Maybe repros should be enforced at the time of bug submission or those who can't submit one should have to deliberately check a box? Maybe you should stop accepting bug submissions through Bugzilla and create a new UI (separate URL) with clear step-by-step instructions: add a repro, remove Nugets, minimize reproduction case, avoid XAML, etc. Make this a list of checkboxes that every dev has to check before hitting the Submit button.
Re: InitializeComponent, I'm not seeing this in VS17 (15.5 preview build) when using .NET Standard projects. Regardless, for anyone still observing this issue, please file a report against the IDE using the feedback option in VS. We'll support the build teams to address it, but it's primarily not a Forms issue.
We won't enforce reproduction projects as a rule, b/c we don't want there to be that barrier. However, we will and should consider how we can properly incentivize better reports. While it bloats our bugzilla counts and slows our time-to-resolution, it's still preferred to gather all reports.
@DavidOrtinau I second @AdrianKnight 's comments re: bugs and I know it's an incredibly tough job you guys have to keep multiple platforms abstracted successfully. In the main Xamarin Forms is amazing, but the design really gets in the way when we find internal and private still scattered everywhere in the code. A propos the ListView bugs in particular, a different design which could allow us to swap out the "stock" implementation and replace it with one of our own would enable production bug fixes for the things that actual users deem important. This is true of all XF controls, but especially annoying with the ListView because it's not possible to replace only part of it. IMO XF is currently being build like the Louvre, with all the good bits on the inside. It really needs to be like the Pompidou centre, with all the plumbing exposed to the user so we can hack it and change it to suit our own specific requirements - which the XF design team can't possibly anticipate.
@DavidDancy said: @DavidOrtinau I second @AdrianKnight 's comments re: bugs and I know it's an incredibly tough job you guys have to keep multiple platforms abstracted successfully. In the main Xamarin Forms is amazing, but the design really gets in the way when we find internal and private still scattered everywhere in the code. A propos the ListView bugs in particular, a different design which could allow us to swap out the "stock" implementation and replace it with one of our own would enable production bug fixes for the things that actual users deem important. This is true of all XF controls, but especially annoying with the ListView because it's not possible to replace only part of it. IMO XF is currently being build like the Louvre, with all the good bits on the inside. It really needs to be like the Pompidou centre, with all the plumbing exposed to the user so we can hack it and change it to suit our own specific requirements - which the XF design team can't possibly anticipate.
@DavidOrtinau if we use CompressedLayout.IsHeadless="true" and if it works for a device or android api, can we expect that it will work for all. For example, i just used for some pages of my project and I tested for api 25 and api 26, can I expect that I wont get any exception for other android apis and any device. I am asking this because this is an exception in UI and I wont be notified until i test it for all possible apis and devices
There is a issue with the new .NET Standard 2.0 templates when you add some new libraries lien IdentityModel.OidcClient or EntityFrameworkCore it fails at runtime when try to load a reference assembly, more info here: https://github.com/xamarin/AndroidSupportComponents/issues/75
@DavidOrtinau Any updates on the integration of GTK? I saw a merge on git several weeks ago.
I'm looking forward to that integration. Can't await to target Linux.
Wtf is going on
Seriously on Android for Xamarin forms your application is too laggy and slow and the newer update always making the previous controls to become fossil or crab and they will not become able to work according to it
@jahanzaibZAHID.7393 said:
Wtf is going on
Seriously on Android for Xamarin forms your application is too laggy and slow and the newer update always making the previous controls to become fossil or crab and they will not become able to work according to it
What version/release are you using? What devices and OS version?
I've been using both 2.5.0 and the nightly releases, doing some performance testing, and I'm seeing good speed on an old Pixel. With XAMLC and AOT startup was 1.6s on average cold start. App responsiveness is great.
@DavidOrtinau Can the documentation team review what's been posted so far and remove obsolete information and make sure new stuff is discussed? For example, here and here WP 8.1 talk should probably be removed, no?.
Also, thanks for updating the roadmap. I don't see any mention of CarouselView. Should we expect the current PR to sit there for another year or so? I was hoping to get my hands on it, included in XF, but I might need to use the current external package instead. Any guidance on whether to wait or not?
@steffWin I raised this point as well, currently the GTK2 cant support without massive overhaul the current Forms features as is. GTK3 of course has it all built in. We had to cancel any work on it.
@DavidOrtinau can you give us an ETA on when you guys will release a new version to nuget? Also I have the same question as @AdrianKnight, whats the status of the Carousel? And @BradChase.2654 can you expand on your answer? GTK2 is insanely old!
Could there be a Roadmap update so we have a rough idea when to expect these?
Just had a Roadmap meeting today and will be incorporating those items. Note anything in the "Ready for Implementation" bucket is up for grabs! We have dozens of community contributors working on this effort (see community-sprint and f100 labels), and Microsoft/Xamarin engineers as well.
@DavidOrtinau - Is there any documentation regarding compatibility of Xamarin.Forms versions for apps to run on Amazon Fire versions (Amazon Fire having been forked from Android)? I've just been doing some testing, and an app that worked on Amazon Fire 4.5.x until recently no longer does. Whilst it could be down to code changes, or a third party assembly, I wonder if it is simply the Xamarin.Forms version.
Posts
Take a look at the rtl branch on github: https://github.com/xamarin/Xamarin.Forms/tree/rtl
@DirkWilhelm Cool, the last time I checked there was no activity on the branch
Not sure where the responsibility lies for this one but;
The New Project templates for a Cross Platform (PCL) app are incredibly out of date.
I've recently converted all my PCLS to .Net Standard which took a large amount of time. Would be better to change the templates
i.e.
Finishing up flipping native controls and a few other odds and ends. It's very close.
https://github.com/xamarin/Xamarin.Forms/tree/rtl
Finishing up flipping native controls and a few other odds and ends. It's very close.
https://github.com/xamarin/Xamarin.Forms/tree/rtl
Q3 2017 Xamarin.Forms for macOS Preview
Q4 2017 Xamarin.Forms for GTK# Preview
Q1 2018 Xamarin.Forms for GTK#, Xamarin.Forms for macOS
Backlog Xamarin.Forms for WPF
This timeline is still there in the first post and is still insane. This IS a decision-making problem in Xamarin. The management is clearly planning for an alternate reality in which Mac and Linux dominate the desktop. Just look at the wpf github fork to see how little attention wpf is getting.
This is too bad: the part of Windows in enterprises is still important, and Windows 10 is only about the half of the Windows part...
Some customers have contacted me as they were interested by a "full" cross-platform app: Windows (from 7 to 10), iOS and Android.
@DavidOrtinau
Bugzilla seems to be growing bigger with over 500 bugs once again. We have bugs that were reported more than 3 years ago. I know that some might be duplicates or no longer valid, but it's also true that waiting literally years for things to be resolved does not sound good on Xamarin's part. Also, we have a lot of old PRs.
Can you publish a Bug Resolution Roadmap and Timeline similar to the features one (this one) so that we know what to expect with regards to which bugs will be resolved and when? There should also be a way, in my opinion, for people to vote/discuss so we identify high/medium/low-priority items. There should be a rule, for example, that only bugs that appeared prior to any of the current (-pre) releases can be on the roadmap so the (pre-)release bugs can be discussed on their dedicated threads.
Hi @AdrianKnight.
I agree, I'm watching and not loving the overall count rising. It's a casualty of pushing out more releases more frequently it would seem. I've discussed it with the engineering team and we've already started allocating more effort to bugzilla reports.
I prioritize bugs based on severity (crashes, blocking issues, workaround availability, etc.) and impact (platforms affected, number of customers affected, etc.).
Which bugs in particular would you like me to review?
The best way for people to "vote" on bugs affecting them is to follow (join the cc list) the bug reports and supply reproduction projects where they are lacking. The quality of actionable reports incoming has been poor. It vastly slows down our triage process, and hinders our ability to see and fix issues.
@DavidOrtinau
For me, a higher priority item would be any confirmed bug pertaining to memory leaks, Listview issues, inconsistencies in the navigation stack, font issues, and any binding problems.
Just looking at the titles on the current confirmed list (and I'm going to assume they either need fixing or to be tested on v2.5+):
Memory leaks:
31171: NavigationPage.PopAsync() cause memory leak by still holding on popped Page
43583: [Android] ListViewRenders leaking
60492: Memory Leak when using Platform.CreateRenderer()
52252: Navigationstack is not getting smaller when removing the last page (currentpage) when a modal page is in view
Listview:
29712: listview datatemplate is not correctly reusing cells, and is waisting performance/memory for nothing
37126: ListView with custom ItemTemplateSelector not updating Background binding in ViewCell
37757: iOS Listview mess with scrollposition after navigation to another page on iOS
40432: iOS ListView is scrolling to the wrong ViewCell after a call to ForceUpdateSize.
41982: ListView binding cannot work correctly in RecycleElement mode
43427: [iOS] Margins Set on ListView Header and Footer Are Rendered Incorrectly
44525: Xamarin.Forms Listview Row Height Does Not Update When Changing Content Size (such as label)
45182: IndexOutOfRangeException when attempting to update an ObservableCollection bound to a ListView within a background thread.
45206: ListView Scroll problem when add a item.
45327: ListView Header disappears when items are added on iOS
45929: ListView ItemTemplate do not change height based on content
46286: ListView incorrectly showing items IsEnabled property after ItemsSource is reset
52430: ListView with HasUnevenRows doesn't auto fit to Image created with ImageSource.FromStream
52979: [iOS] ListView with RowHeight does not fill available height when inside nested StackLayout
56298: Changing ListViews HasUnevenRows at runtime on iOS has no effect
The issues around Listview seem to be much more than these ones. Text-searching 'ListView' on the confirmed list shows 98 mentions. Considering lists are the most important UIs in virtually every modern app, I think the team should focus on creating a more stable
ListView.Also, there are some small (maybe big to some) issues like
InitializeComponent(). It's been years since I saw squiggly lines under this method. It's present in VS2017 as well. Not sure if this is something the VS team needs to fix. Oftentimes, I also run into cases where custom renderers on Android create compilation issues because the compiler can't recognize the using statements.40666: "The name 'InitializeComponent' does not exist in the current context" VS IntelliSense error due to missing
.g.csfile if you manually delete theobjfolder and then reload the solutionI fully agree with your last paragraph. I think this also partially has to do with the way Bugzilla functions. Maybe repros should be enforced at the time of bug submission or those who can't submit one should have to deliberately check a box? Maybe you should stop accepting bug submissions through Bugzilla and create a new UI (separate URL) with clear step-by-step instructions: add a repro, remove Nugets, minimize reproduction case, avoid XAML, etc. Make this a list of checkboxes that every dev has to check before hitting the Submit button.
Thanks @AdrianKnight, I'll review those items.
Re:
InitializeComponent, I'm not seeing this in VS17 (15.5 preview build) when using .NET Standard projects. Regardless, for anyone still observing this issue, please file a report against the IDE using the feedback option in VS. We'll support the build teams to address it, but it's primarily not a Forms issue.We won't enforce reproduction projects as a rule, b/c we don't want there to be that barrier. However, we will and should consider how we can properly incentivize better reports. While it bloats our bugzilla counts and slows our time-to-resolution, it's still preferred to gather all reports.
@DavidOrtinau I second @AdrianKnight 's comments re: bugs and I know it's an incredibly tough job you guys have to keep multiple platforms abstracted successfully. In the main Xamarin Forms is amazing, but the design really gets in the way when we find
internalandprivatestill scattered everywhere in the code. A propos theListViewbugs in particular, a different design which could allow us to swap out the "stock" implementation and replace it with one of our own would enable production bug fixes for the things that actual users deem important. This is true of all XF controls, but especially annoying with theListViewbecause it's not possible to replace only part of it. IMO XF is currently being build like the Louvre, with all the good bits on the inside. It really needs to be like the Pompidou centre, with all the plumbing exposed to the user so we can hack it and change it to suit our own specific requirements - which the XF design team can't possibly anticipate.@DavidDancy ... a poet...
@DavidOrtinau when can we expect to be able to try out the RTL functionality?
@DavidOrtinau if we use CompressedLayout.IsHeadless="true" and if it works for a device or android api, can we expect that it will work for all. For example, i just used for some pages of my project and I tested for api 25 and api 26, can I expect that I wont get any exception for other android apis and any device. I am asking this because this is an exception in UI and I wont be notified until i test it for all possible apis and devices
@DavidOrtinau When it is expected to release forms RTL support?
@DavidOrtinau Hi, we're very eager to see the RTL's support released. Is it scheduled to be released soon? when will that be?
Promising developments for WPF support!
https://github.com/xamarin/Xamarin.Forms/pull/1334
https://github.com/xamarin/Xamarin.Forms/pull/1335
https://github.com/xamarin/Xamarin.Forms/pull/1337
There is a issue with the new .NET Standard 2.0 templates when you add some new libraries lien IdentityModel.OidcClient or EntityFrameworkCore it fails at runtime when try to load a reference assembly, more info here: https://github.com/xamarin/AndroidSupportComponents/issues/75
@DavidOrtinau Can you please give us an update on the roadmap? Shouldn't Q3 and Q4 have been done by now? When do you expect to release XF 3.0?
@DavidOrtinau Any updates on the integration of GTK? I saw a merge on git several weeks ago.
I'm looking forward to that integration. Can't await to target Linux.
Wtf is going on
Seriously on Android for Xamarin forms your application is too laggy and slow and the newer update always making the previous controls to become fossil or crab and they will not become able to work according to it
i thing xamarin forms should b only for ios as developer there are not doing anything
When can we expect the release of XF 2.6.0?
@anve by 2.6.0 are you referring to the what is in the nightly feed? Is there something particular there you are interested in?
We are working on packaging and testing a pre-release now. As soon as it's ready to share, we'll do so.
In the meantime we want to continue shipping bug fixes and quality improvements on the 2.5.0 release.
What version/release are you using? What devices and OS version?
I've been using both 2.5.0 and the nightly releases, doing some performance testing, and I'm seeing good speed on an old Pixel. With XAMLC and AOT startup was 1.6s on average cold start. App responsiveness is great.
It's in the nightly feed. Have you tried it? Please share your feedback with me if you have, david.ortinau@microsoft.com.
It will be in the next pre-release and go out with that stable.
It's in the nightly feed now. If you have feedback, please shoot me an email david.ortinau@microsoft.com.
@DavidOrtinau Can the documentation team review what's been posted so far and remove obsolete information and make sure new stuff is discussed? For example, here and here WP 8.1 talk should probably be removed, no?.
Also, thanks for updating the roadmap. I don't see any mention of
CarouselView. Should we expect the current PR to sit there for another year or so? I was hoping to get my hands on it, included in XF, but I might need to use the current external package instead. Any guidance on whether to wait or not?Thanks for your response. I'm interested in this bugfix to decide if I should wait for the release or build a workaround in the meantime.
@steffWin I raised this point as well, currently the GTK2 cant support without massive overhaul the current Forms features as is. GTK3 of course has it all built in. We had to cancel any work on it.
It looks like there has been a ton of cool enhancements added to the Issues on GitHub:
https://github.com/xamarin/Xamarin.Forms/issues?q=is:open+is:issue+label:t/enhancement
Could there be a Roadmap update so we have a rough idea when to expect these?
@DavidOrtinau can you give us an ETA on when you guys will release a new version to nuget? Also I have the same question as @AdrianKnight, whats the status of the Carousel? And @BradChase.2654 can you expand on your answer? GTK2 is insanely old!
@PaulBrenner There are a bunch of issues but just for example GTK2 doesnt even support alpha channels in colors.
@DavidOrtinau I too would like to know when we'll see another release. It feels like it's been ages since 2.5.
I'm really excited to see this in the next preview. Is there any work done on this feature already?
2.5.0 Service Release 4 shipped today. It's a handful of high priority bug fixes.
We are working on a stability release for the broader range of bug fixes sitting in master. I definitely don't want to hold those up on feature work.
@MatthiasBruzek work has not started on that.
Just had a Roadmap meeting today and will be incorporating those items. Note anything in the "Ready for Implementation" bucket is up for grabs! We have dozens of community contributors working on this effort (see community-sprint and f100 labels), and Microsoft/Xamarin engineers as well.
@DavidOrtinau - Is there any documentation regarding compatibility of Xamarin.Forms versions for apps to run on Amazon Fire versions (Amazon Fire having been forked from Android)? I've just been doing some testing, and an app that worked on Amazon Fire 4.5.x until recently no longer does. Whilst it could be down to code changes, or a third party assembly, I wonder if it is simply the Xamarin.Forms version.