Xamarin.Forms Feature Roadmap

1246712

Posts

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @JamesHancock.1360 I didnt mean to insinuate you were complaining. I think people have a right to be a bit upset with how long the issues have gone on(not saying you just in general). As for us, we have one code base in C# without a lick of objective C, HTML, Java, or Javascript and we hit all platforms except Mac(forms shortly right?). I cant complain about that! Yes there were alot of hickups to get there, yes iOS runs the second fastest now to UWP, and Android is way in the back(to be fixed soon). But we made Android work faster by the way we built our controls and then iOS and UWP both got those improvements without us having to write an extra line of code. Thats pretty damn neat. BTW with your idea its funny a little known Microsoft employee built something called ScriptSharp (C# to Javascript), his name is Nikhil Kothari (amazing guy btw). BUT it seemed under the magical Balmer reign that they just didnt care about it. So he works at Google now.

  • @NMackay .NET Standard is part of .NET Core 1.0. I'm using it right now. VS.NET 2017 has it built in and it's working just fine. What's delayed is .NET NEXT that is .NET Standard 2.0 which is additions to .NET 4.6.2.

    Look at what you're actually using there. Meanwhile you could use NativeScript and replace all of your Mobile, Web and UWP work in one shot with one language. This is the microsoft problem.

    The first step is to merge Xamarin Forms into UWP and get rid of the custom dialect of XAML that should never have been created and then backport a ton of features of UWP XAML to Xamarin Forms.

    While that's happening the rest of the Xamarin team not working on maintenance mode and everyone else MS can spare should be working on porting .NET Native, .NET Core and UWP rendering to Android.

    Bridge.net already exists. MS should evaluate and buy it and integrate it in for web deploy while the Xamarin crew are integrating everything.

    I agree iOS is a problem. MS has a wonderful thing called Azure though. Put a f-ton of Mac minis in a closet somewhere and then provide compile and emulator services from that cluster for free to any MSDN subscriber. Boom! No Mac required.

    @BradChase.2654 The problem is that you've still got custom dialects running around all with their own gotchas. It's a complete mess when you actually look at it. Then go and use NativeScript or React. None of that AND you get to use the same language you're writing your web stuff in. That's what MS is ultimately fighting and this Xamarin over in it's own corner doing it's own thing isn't going to cut it. One plan, one vision just like the Windows 10 kernel everywhere is what it's going to take to get this back on track, because that's what the competition did with nodejs and that's why MS is behind.

  • And I might add: If MS did this, everyone with a brain would run to this stack. Why? C# is a real language. Javascript is not.

    And that's why it will work. Increasingly people are starting to realize why Javascript sucks. But until MS gives them an alternative they're making it work.

  • NMackayNMackay GBInsider, University mod
    edited February 2017

    @JamesHancock.1360

    NativeScript? No thanks. Lots of devs hate Javascript.

    What would you use instead of WPF for an app that huge? this app has been dev for 18 months.

  • On windows desktop you're still screwed if you need Windows 7. You still have to use WPF. If you could target only Windows 10 UWP has very few downsides, especially with .NET native compile possible often.

    But that's also why so many companies are ditching desktop. Pain to deploy and specialized language instead of a single language for development. (For the record I just used Desktop Bridge to bring our WPF app to the Windows store because Xamarin Forms SUCKS with a mouse so it wasn't viable yet whereas Desktop Bridge just worked for the most part.)

    Why build a desktop app when you can do 90% of that in a browser without all of those deploy issues? UWP solves that, and by porting it everywhere it also solves the developer issue having to have specialists when you could have people that can work on anything because it's all in the same language.

    NativeScript is NativeScript, but there is also React, Ionic and many others. You get the point. It's a hell of a lot cheaper to hire 2 good javascript devs than 2 javascript devs and a .NET guy or 2. (i.e. about $120k+ / year cheaper all in)

    When you do that simple math you understand what the nature of MS's problem is and why this half-assed approach isn't going to work.

  • NMackayNMackay GBInsider, University mod

    @JamesHancock.1360

    They wanted to support update XP and Windows 2000 machines until I put my foot down and insisted they use .NET 4.5.1 so the devs had Task/async :s So yeah, they needed Win7 support.

    I'm slightly skeptical about delivering a modular App that big in UWP (views are massive) but maybe it's okay, it can always be ported over later.

    I totally get your point though.

  • @NMackay Imagine if MS created a shim plugin for IE 11 that would allow UWP to run in IE 11 so it would work on Windows 7? Basically create a stripped down RDP that allowed the app itself to run in Azure or a local server and the UI went to the browser window. (or skip IE and just create a player that did the same)

    Then there would be no choice like you had. You could write with the full .NET Core/Native/UWP and still get older systems while it mattered. A variant of Desktop bridge could be used. Obviously the experience wouldn't be as good as native UWP on Windows 10, but you'd get backward compatible while it mattered and could dump old legacy support issues and the deploy issues all at the same time.

    This is what I'm talking about. Yes MS would fear bringing UWP back to Windows 7 because they wouldn't get the upgrades, but guess what? UWP isn't a reason why businesses are upgrading anyhow. And by getting devs up to the latest and greatest (which is why all of the iterations between WPF and UWP didn't work either) without the downsides is FAR more important to Microsoft in the long run than trying to force Windows upgrades through developers complaining about legacy coding when they want to do new stuff.

    The key is that yes, old stuff, web, iOS and Android will have a less good experience. But if it's good enough and the UWP stuff is even better, you'll once again own the developer space, which is all that matters. Everything else is a side effect of that group of people making choices. Right now they're making choices that hurt MS. This is how MS turns that around.

  • Oh, and let us write XAML in JSON (JAML anyone). Lots of devs have never had to write xml at all and JSON is way easier to read even though the result is the same and parsing it is as fast or faster than xml so shouldn't be a big deal to add.

  • TonyDTonyD USMember ✭✭✭

    @DavidOrtinau @JLews

    We are seeing the same thing and we are also using as many custom renderers as possible. I am actually attaching our prod results for this week.

    Page # times rendered iOS UI rendering(ms) Android UI time (ms) Android UI time (no CR)ms
    Discussions Rendering Time 8335 173 382 521
    Matches List Render Time 39157 50 261 344
    Matches Stack Render Time 43303 327 836 1309
    Messages Rendering Time 143164 26 365 588
    Visitors List Render Time 41096 13 74 133

    Right most is no custom renderers (no CR). Middle one is current (partial custom renderers for low-cost effort items). However, we can't move everything as that means completing dropping xamarin forms and we have thousands of LOCs in it already. Our app is tinder-like so users swipe through pictures with text underneath. Imagine how frustrated you'd be if you the UI froze for 836ms on average between every pic.

    Our team opened bugs 41863 and 42235 back in June 2016 and nobody's touched them.

    I'd be happy if you even took it in smaller steps but we really need to see some progress now otherwise we are also very disappointed with how XF has handled perf. Maybe deliver fast renderers for just a couple of views in week 1, then more in week 2 etc. But really show progress or deliver something. Please discuss this with your team again and come up with a more aggressive plan - also, our team is mostly based in Redmond so if you need us to persuade someone in MSFT to give you more resources, or re-prioritize this we might be able to reach out to some of our contacts there and explain this whole situation.

    Judging by how many "likes" JLews' post got I think most the community agrees that if you are going to fix only one thing in XF, Android perf should be it.

  • Abhijeet_SuryaAbhijeet_Surya USMember ✭✭✭

    @DavidOrtinau said:
    @DH80 note that Fast Renderers, Startup Improvements, and Compiled Native Views are Performance items and part of the February target. We'll be getting a boost well before May!

    Very excited to get performance upgrades. Hoping to get it soon.

  • BrightLeeBrightLee KRMember ✭✭✭
    edited February 2017

    @MichaelRumpler

    I agree with that.

    It is a big task.
    The most important one when they release new update is stability.
    Stability and advance the date can not be together.

    And I understand why Xamarin can't move all the member to performance.
    I think, Xamarin also would want if it was possible. But every member has a different ability and expertise.
    Moving more people does not always guarantee a better result.

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

    @TonyD @Abhijeet_Surya performance, yes! One of the main benefits I like about our nightly builds being public is we can see that work (however small and incremental) happening over time and get feedback as early as possible.

    re: bugs that haven't seen ANY updates -- to say we have room for improvement here is an understatement. Expect to see increased communication and velocity here in the coming weeks.

  • alextrepalextrep USMember ✭✭
    edited February 2017
    1. revert to wpf naming and redo everything one on one that this framework do like important datatype on datatemplate that you are missing etc..
    2. make it work perfectly over wpf on windows 7
    3. stability
    4. performance

    do this in your next 6 months to 1 year and xamarin might actually work. Most wpf coders are currently re-orienting themselves at the moment but i'm really not sure they will go into another messy MS bandwagon.

    at moment, you look like a team of javascript coders to me. did you ever code in wpf or what? i'm starting to really wonder if i should switch to swift, ios and give up multiplatform coding...

    so many years lost on MS never ending beta crap & always buggy UI frameworks, so many f. years and now you come along and change the naming and how everything work just to spit in our face hahahahaha wtf..

    after so many failed versions of wpf and silverlight etc..

    you decided that you prefer your own useless naming and weird layout system because you clearly never coded in WPF, lived what we have live & now you're thinking about CSS because of "selectors" hahahahaha .. another proof you have no ideas what you are doing.

    only reason i'm using XAML is because it's not CSS and HTML. You understand that more UI options will just bring a codebase mess!! right? some will prefer css, other styles, other in code etc.. of course you are not the one who have to work on those crazy messy codebase

    xaml language should be in a better clearer DSL language than XML but that's about it.. functionally it should be mostly more of the same.

    i've been coding all my life and truly, the worst part of coding is that you're always stuck in a world of idiots and juniors in high positions who take stupid decisions who affect everything of your work..


    you understand that your xamarin forms render differently on each platforms.. WHY? Can you explain us why this is the standart? no perfectly supported and exactly the same common light and dark theming?

    Most of us want exact 1on1 on all platform.. You understand that yes? that we will have to do a lot just to fix what you didnt want to put the work into doing.?

    we need a 1on1 multiplatform matching theming system and access to ALL the xaml, styling and templates, custom controls etc.. so we can modify,extend it ourselves if and where needed. YOU UNDERSTAND RIGHT? because this is all basic junior stuff.. if you don't you dont know basic stuff like this, you should be fired and they should replace you with a true wpf senior who knows what other wpf seniors working in companies need ..

  • TonekodaTonekoda USMember
    edited February 2017

    By how much do you estimate you will be able to improve startup and overall performance of Xamarin.Forms apps?

    I suggest you create a benchmark page where you compare performance of Xamarin and Xamarin.Forms with native and other cross platform solutions. If performance is good you will definitely convince me and many others to use Xamarin, otherwise not.

    In fact I have already decided that writing native apps is the way to go. Simply because end user experience is the number 1 priority. So if you could convince me with some benchmarks I would be glad, cos I like C# and don't like to learn new languages and maintain code synchronization.
    Cross platform is the future, but not yet, because of performance problems!

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    @JamesHancock.1360

    It's a requirement by Apple that iOS development must be done on a Mac. iOS code must be compiled by Xcode and it can only be deployed to an iOS device which is physically connected to the Mac build host. So even if you put the build host in the Cloud (which you can), you cannot deploy to an iOS device connected to your local Windows machine.

    I'm sure somebody at Xamarin (could have) compiled iOS apps on Windows long ago, but they are simply not allowed to.

    I'd love to install Windows on my Hackintosh, but it's Apples fault that I can't and not Xamarins.

  • @MichaelRumpler Hence why I said that MS should put a ton of Mac Minis in Azure cloud and do the compiles automatically for us so we never have to use a Mac if we don't want to.

  • DavidDancyDavidDancy AUMember ✭✭✭✭
  • PhilippSumiPhilippSumi USMember ✭✭✭

    @DavidOrtinau said:

    @ThomasBurkhart said:
    When will we have Forms decoupled from a certain Android library version?
    The inability to upgrade to the latest Android library makes it impossible to use the latest Version of the Firebase Messaging Libraries which may solve my problems.
    Currently I'm excatly in the same position as @Firefly and my client gets nervous

    It's coming. See: https://github.com/xamarin/Xamarin.Forms/commit/fb024a6e62363af2b14e704c0559eb7a2f08c082

    David, what are we looking at here? I'm sort of seeing an added dependency on 29.0.0.1 and nothing removed that would indicate that the dependency was gone elsewhere. I'm probably misinterpreting this (I hope ;)

    More importantly: Given that's such an easy fix, can this just be applied to a custom build of 2.3.4 and we would be able to use more recent Google APIs? Not being able to use Google's Place Picker on Android is a serious show stopper for us :/

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

    @PhilippSumi C9 just went stable today. https://releases.xamarin.com/stable-release-cycle-9/

    To coincide with this release we've updated our NuGet package to 2.3.3.193. This has the nuspec change to support 23+ for Android support libraries. 29+ for Maps.

    So you can use newer. Those are the minimums. Given you are targeting framework 7.0+ on your Android project.

    https://www.nuget.org/packages/Xamarin.Forms/

  • PhilippSumiPhilippSumi USMember ✭✭✭

    Wohooo, this is awesome! Can we expect an updated 2.3.4.* preview soon that also drops the fixed version dependency?

  • NMackayNMackay GBInsider, University mod

    Oh cool, a stable XAML preview in VS2015 and a UWP masterdetail that works...no, probably not.

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited February 2017
    @NMackay I agree with the master details. Really needs fixed for UWP. Insane it's taken this long for such a large up front problem and release breaker.

    That said has anyone used the nightlies and see weird dots on all the input controls for Android? What are those and is it a bug or some strange new UI thing? More importantly how do we get rid of them. It's not in 2.3.4 backwards.
  • NMackayNMackay GBInsider, University mod
    edited February 2017

    @BradChase.2654 said:
    @NMackay I agree with the master details. Really needs fixed for UWP. Insane it's taken this long for such a large up front problem and release breaker.

    That said has anyone used the nightlies and see weird dots on all the input controls for Android? What are those and is it a bug or some strange new UI thing? More importantly how do we get rid of them. It's not in 2.3.4 backwards.

    MasterDetail isn't much better in iOS, if you have a contentpage with 2 grid columns, some text in column 0 and a map in column one (each column has 50% available space), swipe right across the map and out pops the master detail. Issue going back to 2014....sigh.

    https://forums.xamarin.com/discussion/19364/map-in-master-detail-stops-swipe-to-open

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    NM I figured out the problem in the nightlies on android with the dots. It was the new accessibility stuff. Ill just start making pulls at this point because some issues are getting closed out without being fixed but if anyone needs a quick fix its in ViewRenderer.cs under SetHint().

    Change the line to set elemValue to:

    var elemValue = string.Join( (String.IsNullOrWhiteSpace((string)(Element.GetValue(Accessibility.NameProperty))) || String.IsNullOrWhiteSpace((string)(Element.GetValue(Accessibility.HintProperty)))) ? "" : ". ", (string)Element.GetValue(Accessibility.NameProperty), (string)Element.GetValue(Accessibility.HintProperty));

  • NMackayNMackay GBInsider, University mod

    @BjornB said:
    Before you update to C9!!
    Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    Thanks for the heads up, that would affect me. Could you post the bugzilla link so I can track it's progress?

    I'm waiting for the 1st or 2nd service pack before updating, same story in Cycle8.

  • BjornBBjornB USMember ✭✭✭

    @NMackay said:

    @BjornB said:
    Before you update to C9!!
    Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    Thanks for the heads up, that would affect me. Could you post the bugzilla link so I can track it's progress?

    I'm waiting for the 1st or 2nd service pack before updating, same story in Cycle8.

    I somehow made it private.. maybe i can add you to cc list, pm me email if youd like me to try

  • BjornBBjornB USMember ✭✭✭
    edited February 2017

    @PhilippSumi
    pre 2 has no dependencies

    EDIT: well it has.. but you are free to upgrade android libs to latest

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

    @BjornB said:
    Before you update to C9!!
    Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    This is Visual Studio on Windows, correct? I'm able to debug on Mac, VS for Mac and Xamarin Studio.

  • BjornBBjornB USMember ✭✭✭

    @DavidOrtinau said:

    @BjornB said:
    Before you update to C9!!
    Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    This is Visual Studio on Windows, correct? I'm able to debug on Mac, VS for Mac and Xamarin Studio.

    True! Only affects VS on windows

  • NMackayNMackay GBInsider, University mod

    @BjornB said:

    @DavidOrtinau said:

    @BjornB said:
    Before you update to C9!!
    Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    This is Visual Studio on Windows, correct? I'm able to debug on Mac, VS for Mac and Xamarin Studio.

    True! Only affects VS on windows

    This has been a legitimate gripe of mine for a while, too much focus on the iOS version of Studio clearly, Visual Studio for Windows always lags behind for features and stability, it's a fact.

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @NMackay I am surprised VS went to 32 bit to be honest. I dont know why they just didnt optimize for 16 bit.

  • BjornBBjornB USMember ✭✭✭
    edited March 2017

    @DavidOrtinau
    I have tried to find somewhere to download alpha/beta releases so that i can downgrade from stable cycle 9. I cant find any :neutral: Can someone provide a link?

  • LGMaestrelliLGMaestrelli BRMember ✭✭✭

    @DavidOrtinau

    Any news?
    We will need a link to downgrade or an Alfa/Beta release with the fix...

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

    @BjornB @LGMaestrelli there are downgrade instructions on the release notes. Let me know if you are unable to get this working.

    https://releases.xamarin.com/stable-release-cycle-9/

    Upgrading and Downgrading

    You can install this new version by checking for updates on the Stable updater channel.

    You can downgrade back to the previous Cycle 8 Stable versions (from before February 22, 2017) by manually reinstalling each old package. See the “Get the latest stable version of Cycle 8” section on your account page: https://store.xamarin.com/account/my/subscription/downloads#cycle8. (If you do not yet have a Xamarin login, you can create one.) If you have any trouble downloading the previous versions from that link, would like to install an even earlier set of versions, or simply would prefer an email with all the installer links you need, feel free to email [email protected]

  • BjornBBjornB USMember ✭✭✭
    edited March 2017

    @DavidOrtinau said:
    @BjornB @LGMaestrelli there are downgrade instructions on the release notes. Let me know if you are unable to get this working.

    https://releases.xamarin.com/stable-release-cycle-9/

    Upgrading and Downgrading

    You can install this new version by checking for updates on the Stable updater channel.

    You can downgrade back to the previous Cycle 8 Stable versions (from before February 22, 2017) by manually reinstalling each old package. See the “Get the latest stable version of Cycle 8” section on your account page: https://store.xamarin.com/account/my/subscription/downloads#cycle8. (If you do not yet have a Xamarin login, you can create one.) If you have any trouble downloading the previous versions from that link, would like to install an even earlier set of versions, or simply would prefer an email with all the installer links you need, feel free to email [email protected]

    I cant downgrade to C8 (that is all the instruction says) it will break the android project. I want release 6 of the beta for cycle 9 (stuff worked in this one :P )

    in C9 stable i cant debug. im in a shitty situatuon to say the least

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

    @BjornB ah, I understand. Let me see what I get.

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

    @BjornB @LGMaestrelli we're pulling this together. I'll message you directly on the forum.

  • LGMaestrelliLGMaestrelli BRMember ✭✭✭

    @DavidOrtinau

    Another issue that we found in the Cycle9 is in the XAML editor.
    In some files it look like the image
    And when this happens the indentation is broken

  • NMackayNMackay GBInsider, University mod

    @LGMaestrelli said:
    @DavidOrtinau

    Another issue that we found in the Cycle9 is in the XAML editor.
    In some files it look like the image
    And when this happens the indentation is broken

    Cycle9 breaks PCL debugging (which happened back in 2015), No support anymore (even for enterprise), good luck.

Sign In or Register to comment.