Xamarin.Forms Feature Roadmap

1356712

Posts

  • BjornBBjornB USMember ✭✭✭

    @PaulVipond said:
    @BjornB Interesting tip on ModernHttpClient thanks. I'm using MvvmCross and had this defined as part of my IoC setup:

            Mvx.RegisterType<HttpClient>(() =>
            {
                return new HttpClient(new NativeMessageHandler());
            });
    

    So removed new NativeMessageHandler() from the constructor and yay - it starts working in release mode. I commented it back in to check that was definitely the issue and ... you guessed it, erm, it was still working. This platform plays with your mind :-)

    Try deleting bin/obj manually between debug/reease builds, maybe somtehing caches. The framework is getting better day by day. I remember when i thought maybe the temeperature of my coffe had something to do with with my app getting build errors or not, that was 2 years ago.

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

    @DavidDunscombe said:
    Great to see the focus on performance, android especially could use some improvements. Its a shame you don't offer the easy ability to just AOT selected assemblies instead of the entire app, from my experiments hacking at the msbuild files you really only need to AOT the main app assembly and a couple of xamarin assemblies to get improved startup and performance on android. AOT adds bloat to the already large apk, so some sort of UI to select which assemblies should be AOT'd would be nice.

    The Android team has considered and continues to consider AOT for selected. We'll be glad to have all options at our disposal.

    Improvements in that area are likely to be coming, but discussing that further is both outside the scope of my present knowledge and the focus of the Xamarin.Forms Feature Roadmap.

    Talking of bloat, xamarin currently stores the assemblies uncompressed in the APK, where as with the enterprise version of xamarin you bundle them into a native lib (which gets compressed). Why not compress the assemblies in the non enterprise version - i'm not bothered about the additional 'security' of bundling, but would like the smaller APK size.

    I agree, would be nice to have compression for everyone. I really don't know the historical reasoning behind that. I'll pass that feedback along.

  • PaulVipondPaulVipond GBMember

    @DavidOrtinau WRT performance, I've been looking at the Evolve 2016 Xamarin Forms app. It takes 11 seconds to load on my Note 3 and 16 seconds on my Zen Max Pro. I know the XF performance gains aren't set to materialise until May, but do you have any indicative stats? I.e. likely to load 25%, 50% faster etc? It would be really helpful to know, as my app is fairly straightforward and to deliver android first and then iOS without much rework in XF would be fantastic.

  • ChrisDeBrodie.OAChrisDeBrodie.OA USUniversity ✭✭

    I'm so excited for may 2017 now can't wait for the Xamarin.Forms Embedding Feature that's going to amazing! Now if we can get a drag and drop xamarin forms UI designer that would be epic!

    Keep up the great work Team Xamarin!

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

    @PaulVipond said:
    @DavidOrtinau WRT performance, I've been looking at the Evolve 2016 Xamarin Forms app. It takes 11 seconds to load on my Note 3 and 16 seconds on my Zen Max Pro. I know the XF performance gains aren't set to materialise until May, but do you have any indicative stats? I.e. likely to load 25%, 50% faster etc? It would be really helpful to know, as my app is fairly straightforward and to deliver android first and then iOS without much rework in XF would be fantastic.

    I don't have that yet. When we do I'll share the results.

  • ThomasBurkhartThomasBurkhart DEMember ✭✭✭✭

    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

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

    @rogihee said:
    @DavidOrtinau People have been whining about this for years now. If this commit is what it took, well, shrugs head.

    Keep up the pace!

    That commit represents a lot of conversations, evaluating priorities, and negotiating with several moving pieces. That commit was the easy part.

    When managing something like Xamarin.Forms that's used by so many people, what were once small, simple decisions become complicated and of much greater importance. :)

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

    @DonBox said:
    I still don't see any major activity in the XF GitHub repo on the performance. There have been some small tweaks, things which could have been fixed a year ago if someone dedicated some time.

    The XF team continues to be very very small, like 6-7 people. You can see the number of commits to master for the 10 last months, since XF became open source: https://github.com/xamarin/Xamarin.Forms/graphs/contributors
    Many thanks to Adrian Knight, a free contributor, he has done a lot of fixes.
    You can figure out yourself how many commits per month each member has...

    From my point of view the roadmap should be very focused on 3 main parts:

    1. Fix ALL bugs in controls. As an example, it's not OK that ListView is still not working properly. There are still issues with computing the layout(measure and position) of controls

    2. Focus on performance: measure & tweak performance on the layout engine and the built-in renderers, data-binding performance, XAML performance.

    3. Make sure all small but basic & useful features from Windows XAML are present in XF too. As an example, there are features missing in binding, there's no FallbackValue or NullTargetValue(I saw a recent commit from a contributor but it doesn't look promising, not sure).

    Focus on Android and iOS only. Reality is Windows mobile is pretty much dead right now(even Microsoft pulled the plug for its own apps). For now, Android and iOS is what really matters. I don't think support for Mac OS is important now, when mobile is not working properly.
    Also, I left out things like XAML previewer and other stuff.

    XF still doesn't look like a good option to produce quality mobile apps. Buggy and slow.

    Hi @DonBox, thanks for the feedback! It sounds like we are on the right path then, focusing on quality (bugs) and performance.

    In terms of the Feature Roadmap items you noted:

    • XAML - we want to continue to improve features here. If you'd like to see a binding enhancement like those you mention, please add a proposal in the Evolution forum.
    • Android and iOS only - there world is a big place, and it includes not a few companies that have made significant investments in Windows Phone and increasingly in UWP. We will continue to support and improve those experiences.
    • Forms (Xaml) Previewer isn't a product of our team, it's actually the Designer Team. I've been testing the updated builds and it's improving every time. It's going to be a really useful productivity tool.
  • DonBoxDonBox USMember ✭✭

    Come on David...

  • TonyDTonyD USMember ✭✭✭

    @DavidOrtinau - It's February 1st now, any updates on the Feb perf/other release?

    The Github commits did not look very promising so I hope there's some secret branch somewhere with all the promised Feb perf fixes.

  • BrightLeeBrightLee KRMember ✭✭✭

    @TonyD

    I understand how you're waiting it, because same here.
    But as developer, due date is something that can't be stable.
    I believe you also know it already.
    I bet they are actually working really hard to archive it.

  • DirkWilhelmDirkWilhelm USMember ✭✭✭
    edited February 2017

    Looks like there is a new release 2.3.4-190-pre2 that includes the fixes for Xamarin.Support.* v25, but its not un nuget yet:

    https://github.com/xamarin/Xamarin.Forms/releases/tag/beta-2.3.4-pre2

  • PierceBogganPierceBoggan USForum Administrator, Xamarin Team, Developer Group Leader Xamurai

    @DirkWilhelm: Worth noting that you can still use the package, even if it's not on NuGet (at the moment). Just download the .nupkg, add a custom NuGet source to a local directory, and add it to your project. :smile:

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

    @BBright said:
    @TonyD

    I understand how you're waiting it, because same here.
    But as developer, due date is something that can't be stable.
    I believe you also know it already.
    I bet they are actually working really hard to archive it.

    The team is working hard indeed! I can definitely vouch for that.

    Thanks for the support.

  • DH_HA1DH_HA1 USMember ✭✭✭

    @DavidOrtinau thanks for the update. I am disappointed to see how far out the performance improvements have been pushed.

  • Jay_UKJay_UK GBMember ✭✭

    What about universal custom keyboards? I've noticed in the world of hashtags and @ symbols, its quite difficult to get the keyboard to universally display these. Instagram seem to have changed the 'return' button to the @ and hashtag.

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

    @Jay_UK said:
    What about universal custom keyboards? I've noticed in the world of hashtags and @ symbols, its quite difficult to get the keyboard to universally display these. Instagram seem to have changed the 'return' button to the @ and hashtag.

    That's a good use case for a Routing effect. On iOS it looks like Instagram uses UIKeyboardType.Twitter. I'm not sure offhand what the equivalent is on Android.

    Perhaps you have more in mind when you say "universal custom keyboard". If so, you may want to open a proposal on the Evolution forum.

  • zonkzenzonkzen PLMember ✭✭

    @DavidOrtinau @JLews That's a wonderful reminder of what's really important from the whole roadmap list. I love this reality check.
    Without performant XF, you're leaving people out there in the wild without any help. It's cruelty to even mention other points being important - really, nobody cares. Fix the important thing please. Hire 5x more people to work on XF and you'll see quickly it will give you wonders - Xamarin needs performance to be even an option for millions of companies. I back up JLews 100% - the amount of issues silently dropped by the support is just astonishing.

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

    Hi @JLews, you can talk to me and this is a great forum to do so. You can also message me directly anytime and I’ll do my best to reply in a timely fashion.

    Our goal is to deliver quality, performance, and features when they are ready. The roadmap is visibility into the windows of time when we anticipate being able to deliver.

    In addition to Bindable Picker and OnIdiom, the Startup Improvements and XAMLC enhancements were initially listed for 2.4, but we are able to release then with 2.3.4 because they were ready in time to go through the pre-release process. Those are performance improvements.

    What we have now is the second iteration of the roadmap. Obviously, things have and will change. What hasn’t changed is our commitment to visibility and communication. When it comes to making decisions about what we will focus on, this feedback and these discussions are all ammunition for me to make a strong case when aligning our priorities.

    Our team opened this bug 9 months ago, and sent no fewer than 20 support e-mails and communications and we've been getting "the team is working hard on this" excuse for the past 9 months. It has been repeatedly pushed out month after month, with zero improvements on the XF side. Why?

    I will follow up on this Monday. Please send me some specifics to track down.

    I think the XF team might be out of touch with how serious a problem that is.

    They are not, however that really doesn’t matter until we can ship you results. We are hearing reports of 2x startup time improvement on Android in 2.3.4. I realize there’s much work yet to be delivered overall on Android, but progress has been made.

  • JKayJKay USMember ✭✭✭
    edited February 2017

    Are the dates outlined an estimate for the "Start" "Middle" or "End" of that quarter?

    e.g. does 2.4.0 - Est Q2 2017 mean April, or July?

  • BjornBBjornB USMember ✭✭✭
    edited February 2017

    @DH_HA1 im with you on this one. I think a lot of XF users are aswell. If were to vote between new features vs performance I think we would know that answer.

  • DH_HA1DH_HA1 USMember ✭✭✭

    @BjornB if they use https://github.com/facebook/yoga as the engine for FlexLayout then we might see some layout performance gains.

    I believe the FastRenderers will reduce the number of views created. This is esp crucial for Android

  • ToniPetrinaToniPetrina HRUniversity ✭✭

    After migrating from native apps to Xamarin platform we are now looking to migrate to something else, probably React Native. Reason: Android performance mostly. It is simply not acceptable and I cannot recommend Xamarin right now to anyone targeting Android only or Forms.

  • agonzalezagonzalez USMember

    Great to see a roadmap! I would love to see some day in roadmap:

    • Xamarin.Forms for Web/WebAssembly
    • Drag&Drop like Blend designer
  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @ToniPetrina said:
    After migrating from native apps to Xamarin platform we are now looking to migrate to something else, probably React Native. Reason: Android performance mostly. It is simply not acceptable and I cannot recommend Xamarin right now to anyone targeting Android only or Forms.

    I'm sorry to hear that! I hope you'll give it another look as Xamarin.Forms releases the performance improvements for Android that we have on our roadmap.

    If you're targeting Android only, I'm curious why Xamarin.Android isn't working out for you also. I'll shoot you a direct message to follow up.

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @ToniPetrina Toni, have you considered late loading some views that don't need to be seen immediately? For instance like the bodies of tab views and such so that they are loaded on demand rather than at app or view startup? It might be easier to do that now than switch to a new framework.

  • ToniPetrinaToniPetrina HRUniversity ✭✭

    @BradChase.2654 The layouts are so simple and it would be easier to go native rather to try twisting this UI to make it work properly.

  • The question I keep asking myself (and this may answer the last part of what you said Michael) is why MS isn't putting all of Xamarin in to legacy support mode and focusing on taking UWP and .NET core and porting both of those using what they got out of Xamarin to build one system with Windows being the premiere support and Android and iOS coming along for the ride with EXACTLY the same syntax etc.

    We already know this is possible with the .NET framework minus UI. Doing .NET Core will be easier and with .NET Native around, if they built out the tools they could have everything doing native compilation with linking with a tiny runtime.

    So what's left is UWP, which the XAML is VASTLY better than AXML from Android and Xamarin Forms. If MS can create a rendering engine for both Android and iOS that will render real XAML to both platforms they would have a MASSIVE win, and Windows would become the first class citizen.

    Doing so on Android is relatively easy. They could use Unity (or similar) to actually draw the entire thing and make it look like Material Design and be hardware accelerated just like UWP is. You'd actually end up with UWP apps being faster than java apps on Android are today.

    iOS is the tricky one because Apple would no doubt push back on this type of scheme so MS would likely have to use iOS native controls and do layout, but since you can get very similar results (even though iOS's layout system is vastly more difficult to use) it's obviously doable with XF. The issue is that UWP supports way more, especially in the skinning department than iOS does so iOS apps would look basic compared to what you could produce for Android and Windows. But that's a selling feature to MS.

    If MS then created compile farms in Azure for iOS with emulation etc. then no one would ever have to use a Mac for anything which would be a massive win for Enterprise especially and all of those companies that have outsourced Mobile development for exactly this reason.

    The difficulty would come in the edge cases like encrypted DRM video etc. but the underlying platforms are pretty close in functionality at this point so doing what XF does with the custom renderers should be straight forward.

    If MS demoed this and showed say the Windows 10 Email and Calendar app ported with almost no code changes to Android and iOS they'd have a win. Even if the first version was just Android and windows and you had to build iOS separately they'd have a huge win based on market share.

    So if the sane gods of Microsoft are thinking logically it could explain a great deal about what's going on at Xamarin lately. It would also chart a course to where MS can win back the developers and that is the key to long term success.

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    @MichaelRumpler I agree that mistakes were made, I think developers got a little crazy wanting to add new features, management never recognized the goals, and then they walled themselves off from the community. They took their eye off the prize. BUT it seems they are changing that and I believe we have to give them a chance here. I am noticing a huge amount of response to the community as well as alot of our long-standing bugs being fixes. I mean bugs that have been a show stopper for some for a year. That's good stuff! That instills confidence. But it can't happen over night. Not everyone can do that rendering code, not everyone can think through the trees and find the gaps in speed. So let's give them time.

    On the handhand I don't agree with the Mac. Our app looks and now behaves like a beast on UWP. Our product has to be on Mac because of legacy users that are on silverlight. So yea Mac is very important to us. We have already put in custom renderers or new controls and solved our droid performance problems so that's not a large concern for us right now but I think it should remain top concern for xamarin so I don't agree pushing that one back.
  • BradChase.2654BradChase.2654 USMember ✭✭✭
    @JamesHancock.1360 you know it's not hard to write a custom renderer using Xamarin for MonoGame right? Then all you need to do is create custom styles for each os. And boom you have an extremely performant UI. I just used sprite batches to do it with xamarin's xamlc code. Well modified so it was less reliant on their internal stuff and instead interfaces.
  • @BradChase.2654 I'm not complaining about speed. I'm stating that the fractured nature of Xamarin right now doesn't actually help anything.

    MS needs a central vision that brings XAML everywhere. Having XF "XAML" and UWP XAML and WPF XAML isn't useful. Having .NET half-baked into iOS layout and AXML (google's rip off of WPF XAML) doesn't really move the goalposts ahead either.

    To put it succinctly MS is fighting a 2 front war: Developers MUST use a Mac to build iOS apps. AND they MUST use javascript to develop for the web. They CAN use a Mac to build for Android. And you CAN use javascript to build for Web, iOS and Android (and even UWP) with a single developer knowing only one language.

    But to be a .NET developer you can use Xamarin on a Mac and get Mobile, and then you still need to know Javascript which you'll do on a Mac too. If you are a .NET developer on Windows, you have to have a Mac, you have to go back and forth between the two, and you have to still know Javascript/Typescript and endlessly fight both systems to work.

    MS MUST change the playing field by providing a new unique value proposition: Write in .NET and XAML and have it run everywhere. That must be ONE version and only ONE version of XAML. UWP XAML. To do this they have to give us virtual Macs that we can compile against. They have to unify XAML and make it run as fast or faster (not hard on Android) as the native tools.

    They also have to make XAML and .NET compile to javascript and HTML.

    All of these things are proven to work (there are several projects for XAML/.NET to javascript/HTML that work pretty well (and typescript is the poster child for compile to javascript which is MS) and MS doing it would solve most of the rest of it and making EDGE just natively (without a plugin) and IE with a plugin (silverlight .next for backwards compatibility runtime that even worked on Windows 7) would provide a massive leg up.

    You once again could be a .NET guy and never need to know another language which is what businesses, especially small shops are looking for. One or two javascript guys can do everything in a small company. But with a hybrid .net environment you still have the javascript guy and you still have the mac. So the costs are significantly higher even though the product might be better (and xamarin isn't better than native right now as the comments above clearly outline).

    Imagine if you could write one app with a few transforms for customizations on each platform, and hit compile and it generated iOS binaries, Android binaries (faster than java and almost on par with C++), UWP binaries for Desktop, Mobile, Xbox and hololens, and a full web experience that didn't feel like a plugin because it compiled to HTML and javascript all in one shot?

    If you could, then you'd get people building WWWs as well as SPAs in UWP. You'd get developers off of Macs and back on Windows. You'd make Windows a first class citizen again while eliminating the cost gap between pure javascript with node and nativescript/react and .NET hybrid and you'd get the market back.

    But that can't happen with a fractured approach of keeping Xamarin separate creating their own dialects. And even if you got mobile and desktop in one, you still have web. But if you build the engine so that it can compile down using roslyn to ALL of them then you win.

    And honestly I'll take XAML + C# over HTML + Javascript any day. But what I and a ton of other developers won't do is waste endless hours trying to make windows talk to a mac and still have to have the damn mac there all to just use C# when I could be using NativeScript or React and Nodejs instead of .NET in the backend. Why would you when one skill can transfer across EVERYTHING versus endlessly fighting to use C# for anything other than backend code right now (or irrelevant UWP apps that no one uses)

    .NET Standard is an excellent start to this. If they created .NET standard that could also cross compile to javascript so that you could share code across all platforms (DTOs, client HTTP Rest libraries etc.) then it would be straightforward to build wrappers that worked like Xamarin Forms does now, but against the .net core runtime instead of mono. Further compiling XAML down to HTML and Javascript is a solved problem (see many projects online) and we know the same is true for android and iOS because of Xamarin Forms. So creating a unified framework that works on all of these fragmented platforms using one language: XAML for UI integrated with C#/.NET in the backend is the value proposition that MS needs to be presenting at BUILD.

    Not more Xamarin half-measures.

  • NMackayNMackay GBInsider, University ✭✭✭✭✭
    edited February 2017

    @JamesHancock.1360

    Easier said than done though, we have massive greenfield dev of a desktop app, quite frankly currently only WPF can do it, with UWP we'd be in trouble. Problem is, how do you give the power it has going cross platform with .NET standard?.

    Getting our new Xamarin Forms mobile framework onto UWP has been a bit painful but it's still a pretty good result with a high degree of code reuse and three platforms supported from one (seriously overworked) developer

    We were:

    Mobile: (iOS, Android and Windows mobile) C#
    Desktop WPF C# - (seriously big app, 7-+ modules, 1000s of screens)
    Web: MVC C#/Javascript
    UWP: Ignoring it except via Forms, Microsoft are throwing the kitchen sink at it but to me (and many other devs) it's a serious questionamrk for large scare LOB system development, I just see smaller apps pushed out in UWP despite all the shouting (maybe @DavidOrtinau has some input on UWP in this regard)

    .Net standard has already been pushed back to Q3 2017 from Q1 2017.

    The mac thing, as long as Apple are as difficult as they are regarding getting software onto their platform, I don't know how easy that will be to overcome, this is a war between Google, Apple and MS after all.

    I'd like to see a unified XAML UX approach as well across all platforms but I'm a realist and it's going to a while before that appears, seeing 85-90% code reuse and hitting three platforms isn't a bad start though thanks to Forms.

Sign In or Register to comment.