Xamarin.Forms Feature Roadmap

145791012

Posts

  • ChrisBoydChrisBoyd USMember ✭✭
    edited May 2017

    @DirkWilhelm said:

    How will updates to the assamblies be handled? Wait till the next android version is released? And then again wait till the other brands update their versions?

    As examples: Google Play Services and OpenCV Manager

    In related news from Google I/O: Support Library v26 adds Font Provider support, which utilizes Google Play Services to cache fonts across apps. (EmojiCompat also requires Play services, since they're fonts as well.)

    As a note: Google Play Services typically just tells the user to update to the latest version, if an update is required.
    I don't know how it handles compatibility with older apps.

    OpenCV Manager makes it clear to the user which versions of OpenCV are loaded, and apps implementing OpenCV requests a specific version from the Manager.

    As a result, I don't think it'd be completely unheard of for a common "Xamarin services" APK that handles management of Xamarin assembly versions required by apps that you use.

  • CharlesRoddieCharlesRoddie USMember ✭✭

    @DavidOrtinau said:
    This roadmap outlines our anticipated feature releases.

    Great selection of upgrades. Thank you!

    Xamarin.Forms for macOS
    Xamarin.Forms for GTK#
    Xamarin.Forms for WPF

    Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.

    Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.

  • ChrisBoydChrisBoyd USMember ✭✭
    edited May 2017

    @CharlesRoddie said:

    @DavidOrtinau said:
    Xamarin.Forms for macOS
    Xamarin.Forms for GTK#
    Xamarin.Forms for WPF

    Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.

    Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.

    I agree that there needs to be a better way to find 3rd party components.
    Preferably with a way to specify open-source (with links to Github) or license type.

    Whenever I've gone to the Xamarin Components site, I've always left dissatisfied and ended up Googling what I wanted.

    As a developer, I can certainly understand why Microsoft might want to promote (or allow developers to pay them to promote) paid components... But it often seems that this leads to a bunch of components unrelated to what I'm looking for being suggested instead.

    As an example of a components discovery site done well, there's Google's https://www.webcomponents.org/

    Granted, Google benefits from having great search algorithms...
    Maybe the Xamarin team could get some help from the Bing team here?

  • ChrisBoydChrisBoyd USMember ✭✭
    edited May 2017

    In addition to improved discovery of 3rd party Xamarin.Forms components, I think it might be nice for the Forms team to re-evaluate how certain cross-platform components work.

    e.g. The TabbedPage: Google's Material Design spec (which has been promoted by @JamesMontemagno himself) now specifies Bottom Navigation which is analogous to Apple's UITabBarController.

    Perhaps add a TabPosition property that allows the user to specify Bottom or Top with the default behavior being the current.

    The Top tabs could be like the existing Android and WP implementation, with iOS possibly using a UISegmentedControl added to the Navigation Bar.

    I certainly respect that the original goal was to prefer a platform's behavior, in order to make the user of that platform feel more comfortable... But I'll note that the MasterDetailPage is kind of foreign to native iOS.

    In native iOS, this would be a UISplitViewController with a UITableViewController as the Master, rather than a slide-out drawer. To this day, Apple hasn't added a Navigation Drawer (and to the best of my knowledge as an avid iOS user, they haven't utilized any such control in their standard apps.)

    The Navigation Drawer only really rose to use in iOS as a result of people wanting cross-platform apps to behave more similarly.

    For that matter, I actually think something more like a UISplitViewController has value as a Page component.

    Let's take a "file manager" or email setup as an example: You click on the file or email that you want to view and (on small phones) transition to the detail view. Having a "slide-out" Navigation Drawer doesn't make much sense in that use case.

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

    @Qwin said:
    I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc).
    Example :

    • I have a xamarin forms page with Button X
    • I convert the page to xamarin native iOS and Android
    • Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc
    • With the new implementation I would be able to have a way to grab the Button based on an simple method
    • UIButton buttonX = GetXamarinFormsNativeControl(ViewControllerConvertedFromXamarinFormsPage, "someTagSetInXaml")
    • now I can adjust the buttonX control natively to my likings.

    I believe you can just use Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add a GetMyButton() method and use the x:Name.

  • QwinQwin USUniversity ✭✭

    @DavidOrtinau said:

    @Qwin said:
    I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc).
    Example :

    • I have a xamarin forms page with Button X
    • I convert the page to xamarin native iOS and Android
    • Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc
    • With the new implementation I would be able to have a way to grab the Button based on an simple method
    • UIButton buttonX = GetXamarinFormsNativeControl(ViewControllerConvertedFromXamarinFormsPage, "someTagSetInXaml")
    • now I can adjust the buttonX control natively to my likings.

    I believe you can just use Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add a GetMyButton() method and use the x:Name.

    That is true that we could use Platform.GetRenderer, however I noticed a lot of problems when using it, these might be just bugs hopefully fixed in the future. (problems like rendering the native control, some things go missing or not converted correctly)

    Also I wanted to mention another problem I always get with Renderers is their extensibility. Let's say I wanted to add different libraries to the Listview (ListviewRenderer). I would need to change immense a lot of code to support for instance swiping features which are available by third party libraries. (I tried it, and got even into issues of memory management, caching and other stuff which made it a separate project by itself. Definitely the handling of recycling without causing memory leaks was almost impossible). So I hope renderers get simplified and easier to manage in the future of Xamarin Forms 3.0.

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

    @ChrisBoyd @CharlesRoddie great feedback, thank you. Discoverability between NuGet and the Component Store, and the overlap is something the component team has discussed needing and deserving improvement. I'll make sure to pass this along.

    We are evaluating changing platform design, Bottom Navigation being a great example. And we'll be improving that. That's great feedback, thanks!

  • DH_HA1DH_HA1 USMember ✭✭✭

    @DavidOrtinau I proposed Bottom Nav for android in the Evolution a while back. I would love to see this added as this is now the defacto material design for tabbed navigation

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

    @Qwin please file some reports on specific renderers that have issue with Platform.GetRenderer. I'm not aware of any, so that would be very helpful.

    Agreed, renderer extensibility is indeed an improvement we are making in 3.0, and ListView and cells is a big one.

    Re: swipe cells, I just saw some work from @MatthewRobbins that did this and looked great.

  • lyticolytico ATMember

    Xamarin.Forms for GTK#

    thats great!

    would be nice to have a link to the dev-sources, maybe to contribute some stuff!

  • Matthew-RobbinsMatthew-Robbins AUInsider ✭✭

    @DavidOrtinau, @Qwin Regarding swipeable cells; I'm planning on doing a blog post and open sourced repo to show how we did it when I get the time.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭
    edited May 2017

    @DavidOrtinau

    When should we expect PR 853 to be merged into master? I need to start developing a new app that relies on this control. Instead of waiting till Q3, I'd like to work off of nightly builds or XF fork till Q3, but it'd be nice to see this in master soon.

    Alternatively, I might grab the Nuget / plugin, so I'm debating if it's worth the wait. Please advise. :)

  • RobertDurfeeRobertDurfee USMember ✭✭

    I'm seeing the iOS breakpoint issue when debugging on device. Simulator seems to work OK though. But the dll in use issue is getting really annoying.

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited May 2017

    Android is broken as well fyi. I think two things need to change. One, there really doesnt seem to be much internal testing what so ever when it comes to releases(alpha or otherwise). It appears the greatest testing asset they have currently is us. The second part is, because of the current issues with releases and cycles, it might be a good idea on the newly released channel selector for VS2017 to update the extension and allow us to pick a version to use instead of only 3 channels.

    And dont stop there. Allow us to select which version we want with which OS. Currently there are issues with Droid that are find on iOS but then another version has one where something is fine on iOS but broken on Droid. It would be nice to just pick which version we can use best with each OS.

    EDIT: To add, I hope I am not being too harsh. I know these quick non tested releases tend to happen more often than not during conference time unfortunately :(. It isnt always this bad guys...

  • MuhammadYaseen.2706MuhammadYaseen.2706 USMember ✭✭

    I am very excited about the g18n and RTL support, as it's the only thing holding me off from using XF right now. Well done guys!

  • userexperienceuserexperience SGMember ✭✭

    I'm well aware of this issue, hence why we're stuck on cycle8 but at least we can debug.

  • ShimmyWeitzhandlerShimmyWeitzhandler USMember ✭✭✭
    edited May 2017

    WOW that's indeed a great list.
    I'm especially turned on by XAML Standard.

    Besides, I'm waiting for Xamarin to start supplying more controls, even non-native, maybe in a different namespace. ItemsControl, RadioButton, CheckBox, DateTimePicker etc. With the lack of ItemsControl counterpart, you feel like crippled.
    As a mainly WPF and former Silverlight dev concentrating in LoB apps, these controls are very demanding and are total deal-changers.

    Anyway thanks for all your efforts guys, since MS acquired Xamarin it's definitely on the right path again!

  • VelocityVelocity NZMember ✭✭✭

    @DavidOrtinau Thanks for the updates. Would it be possible to start a thread to discuss the new VisualStateManager on the roadmap? Keen to understand how this will work and what it will do, as we have built our own and interested to see what the migration path will be.

    Thanks!

  • DavidAllenDavidAllen USDeveloper Group Leader ✭✭

    When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions

  • seanydaseanyda GBMember ✭✭✭✭✭

    @DavidAllen said:
    When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions

    There are updates on the CarouselView if you follow the GitHub...
    https://github.com/xamarin/Xamarin.Forms/pull/853

  • MaharshiChoudhuryMaharshiChoudhury INMember ✭✭✭

    Xaamrin.Forms is still buggy

  • wend0rlinwend0rlin DEMember ✭✭

    @DavidAllen, as Sean mentioned it its already decided what's gonna happen.

    https://github.com/alexrainman/CarouselView
    That's the controll which will be merged into XF and its recommended to use it until its part of XF...hopefully in Q3.
    It works pretty well, especially compared to XF Carousel View.

  • NamyslawSzymaniukNamyslawSzymaniuk USMember ✭✭✭

    I've just came after a few months to Xamarin Forms, and I though, that it would be more mature, then before... but it isn't.

    God f.. damn it.
    Everything is broken - building app requires some stupid workarounds - https://acaliaro.wordpress.com/2017/05/29/the-xamlctask-task-failed-unexpectedly/

    Newest XF nugets has broken DataTriggers - https://bugzilla.xamarin.com/show_bug.cgi?id=56515
    Everything is messy, building and signing apps required stupid workaround!

    And if your project has multiple 3rd party components - like Telerik, or any other plugins, you are more and more in black hole of "it's not compiling at all, even your *.CS code is fine".

  • DavidAllenDavidAllen USDeveloper Group Leader ✭✭

    @seanyda & @wend0rlin, thanks for the information. I had assumed that the Xamarin Carousel control was the one they would be supporting. WIll migrate over

  • DavidCarawayDavidCaraway USBeta ✭✭
    edited June 2017

    It's a shame that Forms is giving Xamarin a bloody nose. I've been using Xamarin.iOS and Xamarin.Android for years and they have benefitted me tremendously. They are both rock solid technologies. With good design you can achieve high code reuse between platforms. That said, I will give XF Embedded a spin. That's a feature I will welcome. I suspect a lot of developers who have not been brave enough to fully adopt Forms are looking forward to the ability to integrate Forms in such a manner. That particular part of XF 3.0 is going to be well received. Not by those who jumped fully into Forms but by those who didn't but would like to leverage just parts of XF. If it turns out that even that is too buggy I'll just go back to doing what I've been doing....which works perfectly. Being able to use the same UI code will be nice but I have to keep things in perspective. A recent project had me adding several non-trivial dialogs to one of my enterprise apps. It only took me 2 days to fully duplicate the dialogs in iOS on Android. Granted, I don't have a desktop version of the app too.

  • fabiorfabior USMember ✭✭
    edited June 2017

    Make no mistakes, Xamarin Forms is a great technology!
    However, I think due to poor management, because team remained too small, it's been progressing slow, too slow.

    It's a bit irresponsible from Xamarin to engage and promise to developers so many Xamarin Forms features at once, not being able to make at least iOS and Android(which is what mobile is today) run as good and as fast as possible.

    Xamarin should stop everything and have a simple roadmap for 2017:

    1. Refactor \ rewrite Xamarin Forms with an architecture which delivers as much performance as possible. Since Xamarin is part of Microsoft, I was expecting Microsoft's XAML platform (especially Windows Phone since it runs on mobile) architects to help with this.

    2. Stabilize as much as possible the implementation for iOS and Android.

    3. Add as many features related to controls and XAML as possible. For this, listen to developers. Don't promise features like "CSS-Like Styling" which honestly do not make much sense. How did that go into the roadmap?

    4. In parallel, at least make Xamarin Forms XAML Preview work as good as possible.

    I've seen tweets from Miguel this week about hiring new people to join Xamarin Forms team. Which is good news.
    I hope at least 5-7 positions are available.
    But this is unrelated to starting and promising too many features at once, instead of focusing on iOS and Android.

  • voidvoid DKBeta ✭✭✭
    edited June 2017

    I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.

    The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.

    My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.

  • fabiorfabior USMember ✭✭
    edited June 2017

    @void said:

    but I think that there will always be a certain amount of pain that you as a developer will need to live with.

    Yeah, that's part of the developer's job. But please let's not mix up the usual challenges with Xamarin Forms still not being to draw the borders of a Button correctly in all versions of Android. There's a very recent fix, like a week ago, for that, which hopefully will go soon into the released package. And this is only an example, there are several others referring to bug in controls or incomplete basic features. And of course, again there's the performance issues(converting all renderers to the new "fast" renderers should be a priority).

    Again: I am NOT pointing any fingers at the Xamarin Forms team members. The team is too small, very small, I wish the team got bigger soon after Xamarin joined Microsoft. More than 1.3 years passed and that didn't happen.
    Meanwhile, Xamarin has been promising A LOT of crazy new stuff while implementation for Android and iOS still has issues.

    @void said:
    My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls.

    You mean Silverlight-like where buttons for example are not native but drawn by painting brushes? Oh please for God's sake, no!

  • fabiorfabior USMember ✭✭

    @DavidOrtinau said:
    The reason you're not seeing movement on feature PRs is our core team is only working on fixing bugs and improving quality. This extends beyond commits to Support and CI and QA and Testing processes as well. Issue reports incoming have been steady or dropping, and we are making great progress on the overall backlog of issues. Numbers aren't everything, but it's one metric I'm reporting on. Priority and severe issues (performance, crashes, leaks, volume of users impacted) is another and the team is clearing tons of those.

    I just hope the practice of marking a bug as FIXED or COMPLETED on Bugzilla when the issue it's actually not fixed nor complete, goes away.

    If you want to have Bugzilla as purely feedback forum, like the "user voice" site, then fine, but state that clear. Otherwise it's not OK to mark bugs as FIXED or COMPLETED with a message like "we're already working it". If you're working on it, it's not complete.
    While an open issue might not look OK on the statistics, by closing an issue like that you're showing the middle finger to the developer who spent time reporting.

    The blog is a marketing and education channel. It is not an indicator of what the core engineering team is doing on a daily basis.

    I am not sure what you mean by that. I should not take the blog seriously?
    Also, marketing? What are you guys selling?

    Tizen is a contribution by Samsung. WPF and GTK# are contributions by contractor teams. Our core engineering team is not actively coding on those.

    I was aware of that.
    But given the fact that you don't have time to evaluate PRs for features much more important than WPF support, it would make sense to honestly communicate that while you're announcing WPF support, that's just a contributor PR, something you might even have time to take a look at. Although, it was funny to see how easily the WPF PR was accepted. But If I were to start using it to tomorrow, I have no idea though what's supposed to work or not....

    We are hiring.

    Yep, like I already mentioned, thumbs up for that. And again, I hope the # of positions is at least 5 or 7.
    The most important aspect however remains the architecture and performance. Hiring more people won't fix the issues if things continue to be in 20 different directions, Xamarin Forms will continue to be Jack of all trades, master of none.

    I hope this small update helps balance the perspective on what is currently happening on the platform.

    Honestly? It doesn't help.

    If or when any of those features need to slip to a future target, or we juggle the priority of anything else, I'll update the roadmap.

    OK, I hope the ball called "CSS-Like Styling" is dropped in the juggling process and gets broken into pieces.

    What the roadmap doesn't indicate is anything beyond features, and I need to improve how I communicate the non-feature work. Please know that the desire for improved quality, stability, and performance is very much shared and driving our day to day efforts.

    I am positive Xamarin can pull it off. Even though Xamarin Forms was a framework nobody believed in and took Xamarin by surprise :)

  • DavidCarawayDavidCaraway USBeta ✭✭
    edited June 2017

    @void said:
    I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.

    The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.

    My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.

    Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing. However, I generally agree with you. The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term. I'd wager my house that will prove to be the case. They will either have to use an approach like you recommend or go with a lightweight implementation that isn't so ambitious. There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.

  • fabiorfabior USMember ✭✭
    edited June 2017

    @DavidCaraway said:
    Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing.

    Swing!? Yes, "plague" is the appropriate word.

    The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term.

    No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though.
    Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.

    Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework
    It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.

    I'd wager my house that will prove to be the case.

    Don't. You will lose your house.

    There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.

    Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method.
    Let's keep Silverlight dead for good. Please.
    With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.

  • DavidCarawayDavidCaraway USBeta ✭✭

    @fabior said:

    @DavidCaraway said:
    Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing.

    Swing!? Yes, "plague" is the appropriate word.

    The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term.

    No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though.

    Might be a case of both

    Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.

    Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework
    It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.

    I'd wager my house that will prove to be the case.

    Don't. You will lose your house. No I won't

    Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method.
    Let's keep Silverlight dead for good. Please.
    With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.

    Drawing controls was hardly my idea of a lightweight approach. I've been using homemade "lightweight" approaches since the time I first started using Xamarin. They are admittedly laughable though. I don't care. I work on my own dime. I go with what works. It's been a very long time since I've ever banged my head against the wall for days trying to find a workaround.

    So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.

  • fabiorfabior USMember ✭✭

    @DavidCaraway said:
    So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.

    I was going to argue that the right question is "when", not "if". But I think you're right. Anything in regards with technology has a deadline. Even if you do it, it might be too late, so yeah maybe "if" is correct.

145791012
Sign In or Register to comment.