@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.
@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.
@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'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!
@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.
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
@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
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:
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
Focus on performance: measure & tweak performance on the layout engine and the built-in renderers, data-binding performance, XAML performance.
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.
@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.
@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:
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
Focus on performance: measure & tweak performance on the layout engine and the built-in renderers, data-binding performance, XAML performance.
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.
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.
@TonyD said: @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.
There are performance updates in the current pre-release, and we're continuing to work on more. We have been most recently collaborating with other teams internally to identify additional opportunities for improvements. We will be spiking on some of those ideas in the coming weeks to see what can be gained.
Keep an eye on the blog tomorrow. I have a post coming that'll be of interest to anyone tracking the very latest about Forms.
Please re-read the disclaimer in the initial post. The Roadmap is to give visibility to what we are working on and when we anticipate being able to deliver. Things will and have changed since I shared the roadmap at the beginning of January, and as such I'll be updating it within the next week with the latest information.
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.
I've just posted an update to the Roadmap. Please give it a look. You'll see some things have shifted, and I've adjusted the time windows within which we hope to release.
I anticipate not everyone will have a ringing endorsement for some changes. With a fantastic, active community as large as ours, we are bound to have some competing priorities. This thread is the place to discuss and advocate for what is important to you. And I sincerely welcome that discussion.
Please feel to reach out to me directly as well. Direct message me or Slack me.
If you have something you want to see done, create a proposal in the Evolution Forum. We're accepting proposals and merging PRs all the time.
On a related note, there are currently a handful of Accepted Proposals in the Evolution Forum. If there's one you like, comment on it and we'll work on getting you assigned to it.
Since I joined last month, I've been talking to many of you and many of our Xamarin.Forms customers. Your feedback is a major factor that helps guide us. Keep it coming!
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.
@DavidOrtinau who is responsible for the decision to push back perf improvements that far out? And who do we talk to to get this moved back to #1? 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?
We've moved a lot of our code to custom renderers but short of dropping XF entirely there is nothing more we can do on our end. We've cut a bunch of features from Android for being too slow (while the iOS ones are fine), and we've even disabled all pre-2013 Android phones. We have to deal with 150,000 users complaining about Android perf every day, and it's beginning to cost us a lot of money. I don't think features like "bindable pickers" or "onidiom support" that somehow made it into 2.3.4 are even close in priority. Our perf monitor shows 3:1 UI performance between iOS and Android which is ridiculous.
So please, point me to whoever is behind this decision so that our team can escalate up their management team and get this resolved. If devs are giving you the run-around, then please point me to their dev manager so I remind him his devs have been "working on this" for nearly a year and haven't delivered anything. I think the XF team might be out of touch with how serious a problem that is. Our team will be happy to spend the next month on the phone or e-mail reminding them of this.
@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.
@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.
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.
@DavidOrtinau the performance improvements should be top priority. FastRenderers, less view creation etc. Every view on Android is wrapped in a ViewGroup which is not necessary and creates 2 views per control. We have been asking for this for a long time.
@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.
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.
@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.
@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.
I'm longing for the performance enhancements as everybody else, but I thing you're a bit unfair here.
Xamarin cannot release those improvements when they are not finished. Rewriting the whole rendering/layout system is a big task. But unfortunately this is a task where you need to have much insight of how everything works together. So even if they would push 20 more developers on the project, they would not be finished faster because those new devs would have no clue what to do.
I'm sure you all worked on a project which was behind schedule. Did your bosses also call the developers or their managers every few minutes? Did that improve your performance?
We asked for a roadmap for years and now that we have it, you complain again. There will be delays. Delays are normal.
If I had something to say, I would move more exisiting Forms devs (no new ones) to work on the performance improvements. Rui works on XF for Mac which is completely useless IMHO. Mobiles and desktops need different UI so why should they share the UI code? But Rui could help with the performance improvements. I don't know what the others do currently.
New developers could work on new features or test automation. Thats something where they should not clash with and slow down the others too much. Actually I thought that Microsoft would put more resources to XF when they bought Xamarin, but unfortunately that did not happen.
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.
@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.
@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.
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.
Posts
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.
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.
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.
@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'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!
I don't have that yet. When we do I'll share the results.
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
@DavidOrtinau People have been whining about this for years now. If this commit is what it took, well, shrugs head.
Keep up the pace!
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:
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
Focus on performance: measure & tweak performance on the layout engine and the built-in renderers, data-binding performance, XAML performance.
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.
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.
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:
Come on David...
@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.
@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.
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
@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.
There are performance updates in the current pre-release, and we're continuing to work on more. We have been most recently collaborating with other teams internally to identify additional opportunities for improvements. We will be spiking on some of those ideas in the coming weeks to see what can be gained.
Keep an eye on the blog tomorrow. I have a post coming that'll be of interest to anyone tracking the very latest about Forms.
Please re-read the disclaimer in the initial post. The Roadmap is to give visibility to what we are working on and when we anticipate being able to deliver. Things will and have changed since I shared the roadmap at the beginning of January, and as such I'll be updating it within the next week with the latest information.
The team is working hard indeed! I can definitely vouch for that.
Thanks for the support.
Hi All,
I've just posted an update to the Roadmap. Please give it a look. You'll see some things have shifted, and I've adjusted the time windows within which we hope to release.
I anticipate not everyone will have a ringing endorsement for some changes. With a fantastic, active community as large as ours, we are bound to have some competing priorities. This thread is the place to discuss and advocate for what is important to you. And I sincerely welcome that discussion.
Please feel to reach out to me directly as well. Direct message me or Slack me.
If you have something you want to see done, create a proposal in the Evolution Forum. We're accepting proposals and merging PRs all the time.
On a related note, there are currently a handful of Accepted Proposals in the Evolution Forum. If there's one you like, comment on it and we'll work on getting you assigned to it.
Since I joined last month, I've been talking to many of you and many of our Xamarin.Forms customers. Your feedback is a major factor that helps guide us. Keep it coming!
@DavidOrtinau thanks for the update. I am disappointed to see how far out the performance improvements have been pushed.
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.
@DavidOrtinau who is responsible for the decision to push back perf improvements that far out? And who do we talk to to get this moved back to #1? 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?
We've moved a lot of our code to custom renderers but short of dropping XF entirely there is nothing more we can do on our end. We've cut a bunch of features from Android for being too slow (while the iOS ones are fine), and we've even disabled all pre-2013 Android phones. We have to deal with 150,000 users complaining about Android perf every day, and it's beginning to cost us a lot of money. I don't think features like "bindable pickers" or "onidiom support" that somehow made it into 2.3.4 are even close in priority. Our perf monitor shows 3:1 UI performance between iOS and Android which is ridiculous.
So please, point me to whoever is behind this decision so that our team can escalate up their management team and get this resolved. If devs are giving you the run-around, then please point me to their dev manager so I remind him his devs have been "working on this" for nearly a year and haven't delivered anything. I think the XF team might be out of touch with how serious a problem that is. Our team will be happy to spend the next month on the phone or e-mail reminding them of this.
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.
@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.
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.
I will follow up on this Monday. Please send me some specifics to track down.
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.
Are the dates outlined an estimate for the "Start" "Middle" or "End" of that quarter?
e.g. does
2.4.0 - Est Q2 2017mean April, or July?@DavidOrtinau the performance improvements should be top priority. FastRenderers, less view creation etc. Every view on Android is wrapped in a ViewGroup which is not necessary and creates 2 views per control. We have been asking for this for a long time.
@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.
@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
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.
Great to see a roadmap! I would love to see some day in roadmap:
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.
@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.
@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.
I'm longing for the performance enhancements as everybody else, but I thing you're a bit unfair here.
Xamarin cannot release those improvements when they are not finished. Rewriting the whole rendering/layout system is a big task. But unfortunately this is a task where you need to have much insight of how everything works together. So even if they would push 20 more developers on the project, they would not be finished faster because those new devs would have no clue what to do.
I'm sure you all worked on a project which was behind schedule. Did your bosses also call the developers or their managers every few minutes? Did that improve your performance?
We asked for a roadmap for years and now that we have it, you complain again. There will be delays. Delays are normal.
If I had something to say, I would move more exisiting Forms devs (no new ones) to work on the performance improvements. Rui works on XF for Mac which is completely useless IMHO. Mobiles and desktops need different UI so why should they share the UI code? But Rui could help with the performance improvements. I don't know what the others do currently.
New developers could work on new features or test automation. Thats something where they should not clash with and slow down the others too much. Actually I thought that Microsoft would put more resources to XF when they bought Xamarin, but unfortunately that did not happen.
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.
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.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.
@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.