How will updates to the assamblies be handled? Wait till the next android version is released? And then again wait till the other brands update their versions?
In related news from Google I/O: Support Library v26 adds Font Provider support, which utilizes Google Play Services to cache fonts across apps. (EmojiCompat also requires Play services, since they're fonts as well.)
As a note: Google Play Services typically just tells the user to update to the latest version, if an update is required.
I don't know how it handles compatibility with older apps.
OpenCV Manager makes it clear to the user which versions of OpenCV are loaded, and apps implementing OpenCV requests a specific version from the Manager.
As a result, I don't think it'd be completely unheard of for a common "Xamarin services" APK that handles management of Xamarin assembly versions required by apps that you use.
@DavidOrtinau said:
This roadmap outlines our anticipated feature releases.
Great selection of upgrades. Thank you!
Xamarin.Forms for macOS Xamarin.Forms for GTK# Xamarin.Forms for WPF
Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.
Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.
@DavidOrtinau said: Xamarin.Forms for macOS Xamarin.Forms for GTK# Xamarin.Forms for WPF
Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.
Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.
I agree that there needs to be a better way to find 3rd party components.
Preferably with a way to specify open-source (with links to Github) or license type.
Whenever I've gone to the Xamarin Components site, I've always left dissatisfied and ended up Googling what I wanted.
As a developer, I can certainly understand why Microsoft might want to promote (or allow developers to pay them to promote) paid components... But it often seems that this leads to a bunch of components unrelated to what I'm looking for being suggested instead.
In addition to improved discovery of 3rd party Xamarin.Forms components, I think it might be nice for the Forms team to re-evaluate how certain cross-platform components work.
e.g. The TabbedPage: Google's Material Design spec (which has been promoted by @JamesMontemagno himself) now specifies Bottom Navigation which is analogous to Apple's UITabBarController.
Perhaps add a TabPosition property that allows the user to specify Bottom or Top with the default behavior being the current.
The Top tabs could be like the existing Android and WP implementation, with iOS possibly using a UISegmentedControl added to the Navigation Bar.
I certainly respect that the original goal was to prefer a platform's behavior, in order to make the user of that platform feel more comfortable... But I'll note that the MasterDetailPage is kind of foreign to native iOS.
In native iOS, this would be a UISplitViewController with a UITableViewController as the Master, rather than a slide-out drawer. To this day, Apple hasn't added a Navigation Drawer (and to the best of my knowledge as an avid iOS user, they haven't utilized any such control in their standard apps.)
The Navigation Drawer only really rose to use in iOS as a result of people wanting cross-platform apps to behave more similarly.
For that matter, I actually think something more like a UISplitViewController has value as a Page component.
Let's take a "file manager" or email setup as an example: You click on the file or email that you want to view and (on small phones) transition to the detail view. Having a "slide-out" Navigation Drawer doesn't make much sense in that use case.
@Qwin said:
I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc).
Example :
I have a xamarin forms page with Button X
I convert the page to xamarin native iOS and Android
Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc
With the new implementation I would be able to have a way to grab the Button based on an simple method
now I can adjust the buttonX control natively to my likings.
I believe you can just use Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add a GetMyButton() method and use the x:Name.
@Qwin said:
I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc).
Example :
I have a xamarin forms page with Button X
I convert the page to xamarin native iOS and Android
Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc
With the new implementation I would be able to have a way to grab the Button based on an simple method
now I can adjust the buttonX control natively to my likings.
I believe you can just use Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add a GetMyButton() method and use the x:Name.
That is true that we could use Platform.GetRenderer, however I noticed a lot of problems when using it, these might be just bugs hopefully fixed in the future. (problems like rendering the native control, some things go missing or not converted correctly)
Also I wanted to mention another problem I always get with Renderers is their extensibility. Let's say I wanted to add different libraries to the Listview (ListviewRenderer). I would need to change immense a lot of code to support for instance swiping features which are available by third party libraries. (I tried it, and got even into issues of memory management, caching and other stuff which made it a separate project by itself. Definitely the handling of recycling without causing memory leaks was almost impossible). So I hope renderers get simplified and easier to manage in the future of Xamarin Forms 3.0.
@ChrisBoyd@CharlesRoddie great feedback, thank you. Discoverability between NuGet and the Component Store, and the overlap is something the component team has discussed needing and deserving improvement. I'll make sure to pass this along.
We are evaluating changing platform design, Bottom Navigation being a great example. And we'll be improving that. That's great feedback, thanks!
@DavidOrtinau I proposed Bottom Nav for android in the Evolution a while back. I would love to see this added as this is now the defacto material design for tabbed navigation
When should we expect PR 853 to be merged into master? I need to start developing a new app that relies on this control. Instead of waiting till Q3, I'd like to work off of nightly builds or XF fork till Q3, but it'd be nice to see this in master soon.
Alternatively, I might grab the Nuget / plugin, so I'm debating if it's worth the wait. Please advise.
Is it time to do start doing some regression testing on Xamarin releases?
every time I update there is a surprise - the most recent ones were "build failed dll used by another process" and ios breakpoints aren't hit.
should there be some idea of a minimum software quality that's acceptable for release? or is it just whatever goes is ok? I don't get it.
to be honest Xamarin spoils the perception of quality of Visual Studio environment. takes it from 10-star to 1-star. Does anyone at Microsoft care about quality of VS as as development environment?
Android is broken as well fyi. I think two things need to change. One, there really doesnt seem to be much internal testing what so ever when it comes to releases(alpha or otherwise). It appears the greatest testing asset they have currently is us. The second part is, because of the current issues with releases and cycles, it might be a good idea on the newly released channel selector for VS2017 to update the extension and allow us to pick a version to use instead of only 3 channels.
And dont stop there. Allow us to select which version we want with which OS. Currently there are issues with Droid that are find on iOS but then another version has one where something is fine on iOS but broken on Droid. It would be nice to just pick which version we can use best with each OS.
EDIT: To add, I hope I am not being too harsh. I know these quick non tested releases tend to happen more often than not during conference time unfortunately . It isnt always this bad guys...
WOW that's indeed a great list.
I'm especially turned on by XAML Standard.
Besides, I'm waiting for Xamarin to start supplying more controls, even non-native, maybe in a different namespace. ItemsControl, RadioButton, CheckBox, DateTimePicker etc. With the lack of ItemsControl counterpart, you feel like crippled.
As a mainly WPF and former Silverlight dev concentrating in LoB apps, these controls are very demanding and are total deal-changers.
Anyway thanks for all your efforts guys, since MS acquired Xamarin it's definitely on the right path again!
@DavidOrtinau Thanks for the updates. Would it be possible to start a thread to discuss the new VisualStateManager on the roadmap? Keen to understand how this will work and what it will do, as we have built our own and interested to see what the migration path will be.
When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions
@DavidAllen I think the XF team is still busy implementing features no one asked for. Maybe once they're done with the 3.0 gimmicks they can focus on performance and the existing broken features again.
@DavidAllen said:
When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions
@DavidAllen, as Sean mentioned it its already decided what's gonna happen.
https://github.com/alexrainman/CarouselView
That's the controll which will be merged into XF and its recommended to use it until its part of XF...hopefully in Q3.
It works pretty well, especially compared to XF Carousel View.
And if your project has multiple 3rd party components - like Telerik, or any other plugins, you are more and more in black hole of "it's not compiling at all, even your *.CS code is fine".
@seanyda & @wend0rlin, thanks for the information. I had assumed that the Xamarin Carousel control was the one they would be supporting. WIll migrate over
@JLews said: @DavidAllen I think the XF team is still busy implementing features no one asked for. Maybe once they're done with the 3.0 gimmicks they can focus on performance and the existing broken features again.
I'm sorry for having to say this but I've rarely seen a project so badly managed as Xamarin Forms.
Xamarin is announcing with fanfare on their blog different features in Xamarin Forms when in reality, there are still issues with common features or some are still missing.
iOS and Android support is still buggy and performance is pretty bad with even basic pages. It's not hard to see a lag when navigating between simple pages.
I understand Xamarin Forms will never have same speed as native, but looking at the code and architecture of the Xamarin Forms, it's obvious there is much room for improvement.
Despite the fact I still don't understand why Microsoft would pay many millions of $ in salaries for the implementation and support of a mobile development platform for Android and iOS, I thought after Xamarin joined Microsoft, Xamarin Forms development progress will "explode", given than there are extraordinary people at Microsoft who designed and implemented the XAML frameworks WPF, Silverlight, especially WindowsPhone, UWP, people which can help or at least share critical knowledge to Xamarin related to architecture and performance.
Xamarin encourages people to contribute, but there are important contributions in PRs which haven't been reviewed for weeks \ months:
I'm NOT pointing fingers at the Xamarin Forms team members, they are not to blame! There's so much things to do and team is small.
It makes no sense. Xamarin Forms is announcing with fanfare Xamarin Forms 3.0 adopting XAML Standard (which will require a lot of work), support for Samsung's Tinzen, but in the same time you don't have time to really nail the support for at least iOS and Android.
Xamarin also announced in a blog post support for WPF, but "forgot" to mention that it's actually a PR by someone outside the team: https://github.com/xamarin/Xamarin.Forms/pull/895
I personally don't appreciate these marketing attempts at all, Xamarin is shooting themselves in the foot.
Also, what is "CSS-Like Styling" in the roadmap. Who asked for that?
How are you going to actually deliver all these promised features in a timely manner? Are they going to be just some half baked implementations like other features? When is XAML Preview for Xamarin Forms going to actually work 100%?
With the slow progress, by the time Xamarin Forms is really working, JavaScript (or something else) will look and work like C# and web development will have almost all the capability of native, including access to camera and sensors. Some of these are already happening.
I'm sorry but Xamarin Forms looks to me mostly like a marketing gimmick used by Microsoft.
It's a shame that Forms is giving Xamarin a bloody nose. I've been using Xamarin.iOS and Xamarin.Android for years and they have benefitted me tremendously. They are both rock solid technologies. With good design you can achieve high code reuse between platforms. That said, I will give XF Embedded a spin. That's a feature I will welcome. I suspect a lot of developers who have not been brave enough to fully adopt Forms are looking forward to the ability to integrate Forms in such a manner. That particular part of XF 3.0 is going to be well received. Not by those who jumped fully into Forms but by those who didn't but would like to leverage just parts of XF. If it turns out that even that is too buggy I'll just go back to doing what I've been doing....which works perfectly. Being able to use the same UI code will be nice but I have to keep things in perspective. A recent project had me adding several non-trivial dialogs to one of my enterprise apps. It only took me 2 days to fully duplicate the dialogs in iOS on Android. Granted, I don't have a desktop version of the app too.
It was interesting for many, many users (see thread) and contains many useful proposals...
Instead of take the proposal serious and improve the processes, Xamarin has “deactivated” the thread by prevent it from pop, if a new posting was added...
You can copy-paste the information’s in the thread from May 2015 to May 2017...
I further had direct contact to some Xamarin employees (to .forms and to the VS-integration) in the history and have wasted more time by describe the problems in detail and further describe proposals in detail...
Nothing has changed...
The base still don’t work (debugger often don’t work, variables are not viewable in debugger, the whole development environment works not stable and is very slow)
And... this is daily base work of every developer and cost ”count of developer” x “every day wasted time”
For Xamarin, it’s further self-evident, that:
the developers has to find out new bug’s and not solved solved bugs after every update
the developers have to create a “minimum sample project” for almost any bug, as Xamarin don’t want to invest the time to find out the reason / cause to the bug according the posted bugzilla description entry to the bug
Every update (.forms but also new versions of VS integration SW, VS versions, and also all related SW like MAC, OS, Xcode and so on) has to be feared, as the chance is greater than 50% that the app will not be usable after the update and every developer has to invest hours if not days, only to be able to compile and user the app again after the update...
How should we be able to work productive in such an environment...?
Instead of make the base (.forms itself and the related software) rock-solid, nothing in the processes is changed (copy-paste from 2015), but new, not needed and not working “features” are added so that .forms becomes more and more instable...
Periodically (once again in this thread) , Xamarin say’s, that the bug solving and stabilization hast the highest priority... I... don’t... can... see... any sign..
So the proposals in the thread of 2015 still are valid in 2017!
Please hold your promises:
first make .forms (and the whole environment) stable and really test new versions, before you use the word “stable” in the new version and let us do our daily work on a productive way
then, add missing new functions features, that every developer needs (like, e.g. such trivial things as set a font size to a piker without the need to create a “custom render”, or add a usable popup control that can be used without the need to search and add some other package to be able to show a popup)
then add features and gimmicks that only and "handful" developer
Make no mistakes, Xamarin Forms is a great technology!
However, I think due to poor management, because team remained too small, it's been progressing slow, too slow.
It's a bit irresponsible from Xamarin to engage and promise to developers so many Xamarin Forms features at once, not being able to make at least iOS and Android(which is what mobile is today) run as good and as fast as possible.
Xamarin should stop everything and have a simple roadmap for 2017:
Refactor \ rewrite Xamarin Forms with an architecture which delivers as much performance as possible. Since Xamarin is part of Microsoft, I was expecting Microsoft's XAML platform (especially Windows Phone since it runs on mobile) architects to help with this.
Stabilize as much as possible the implementation for iOS and Android.
Add as many features related to controls and XAML as possible. For this, listen to developers. Don't promise features like "CSS-Like Styling" which honestly do not make much sense. How did that go into the roadmap?
In parallel, at least make Xamarin Forms XAML Preview work as good as possible.
I've seen tweets from Miguel this week about hiring new people to join Xamarin Forms team. Which is good news.
I hope at least 5-7 positions are available.
But this is unrelated to starting and promising too many features at once, instead of focusing on iOS and Android.
I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.
The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.
My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.
but I think that there will always be a certain amount of pain that you as a developer will need to live with.
Yeah, that's part of the developer's job. But please let's not mix up the usual challenges with Xamarin Forms still not being to draw the borders of a Button correctly in all versions of Android. There's a very recent fix, like a week ago, for that, which hopefully will go soon into the released package. And this is only an example, there are several others referring to bug in controls or incomplete basic features. And of course, again there's the performance issues(converting all renderers to the new "fast" renderers should be a priority).
Again: I am NOT pointing any fingers at the Xamarin Forms team members. The team is too small, very small, I wish the team got bigger soon after Xamarin joined Microsoft. More than 1.3 years passed and that didn't happen.
Meanwhile, Xamarin has been promising A LOT of crazy new stuff while implementation for Android and iOS still has issues.
@void said:
My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls.
You mean Silverlight-like where buttons for example are not native but drawn by painting brushes? Oh please for God's sake, no!
Hi all, there's a lot here, but let me give you a general update on what we are working on now and have been since Build.
Quality. Period.
The reason you're not seeing movement on feature PRs is our core team is only working on fixing bugs and improving quality. This extends beyond commits to Support and CI and QA and Testing processes as well. Issue reports incoming have been steady or dropping, and we are making great progress on the overall backlog of issues. Numbers aren't everything, but it's one metric I'm reporting on. Priority and severe issues (performance, crashes, leaks, volume of users impacted) is another and the team is clearing tons of those.
The blog is a marketing and education channel. It is not an indicator of what the core engineering team is doing on a daily basis.
Tizen is a contribution by Samsung. WPF and GTK# are contributions by contractor teams. Our core engineering team is not actively coding on those.
I hope this small update helps balance the perspective on what is currently happening on the platform.
What does this mean for the feature roadmap and the things announced as a part of 3.0? As we have always said, the roadmap will change as needed but it communicates our intention and the current roadmap is still just that. If or when any of those features need to slip to a future target, or we juggle the priority of anything else, I'll update the roadmap.
What the roadmap doesn't indicate is anything beyond features, and I need to improve how I communicate the non-feature work. Please know that the desire for improved quality, stability, and performance is very much shared and driving our day to day efforts.
@DavidOrtinau said:
The reason you're not seeing movement on feature PRs is our core team is only working on fixing bugs and improving quality. This extends beyond commits to Support and CI and QA and Testing processes as well. Issue reports incoming have been steady or dropping, and we are making great progress on the overall backlog of issues. Numbers aren't everything, but it's one metric I'm reporting on. Priority and severe issues (performance, crashes, leaks, volume of users impacted) is another and the team is clearing tons of those.
I just hope the practice of marking a bug as FIXED or COMPLETED on Bugzilla when the issue it's actually not fixed nor complete, goes away.
If you want to have Bugzilla as purely feedback forum, like the "user voice" site, then fine, but state that clear. Otherwise it's not OK to mark bugs as FIXED or COMPLETED with a message like "we're already working it". If you're working on it, it's not complete.
While an open issue might not look OK on the statistics, by closing an issue like that you're showing the middle finger to the developer who spent time reporting.
The blog is a marketing and education channel. It is not an indicator of what the core engineering team is doing on a daily basis.
I am not sure what you mean by that. I should not take the blog seriously?
Also, marketing? What are you guys selling?
Tizen is a contribution by Samsung. WPF and GTK# are contributions by contractor teams. Our core engineering team is not actively coding on those.
I was aware of that.
But given the fact that you don't have time to evaluate PRs for features much more important than WPF support, it would make sense to honestly communicate that while you're announcing WPF support, that's just a contributor PR, something you might even have time to take a look at. Although, it was funny to see how easily the WPF PR was accepted. But If I were to start using it to tomorrow, I have no idea though what's supposed to work or not....
Yep, like I already mentioned, thumbs up for that. And again, I hope the # of positions is at least 5 or 7.
The most important aspect however remains the architecture and performance. Hiring more people won't fix the issues if things continue to be in 20 different directions, Xamarin Forms will continue to be Jack of all trades, master of none.
I hope this small update helps balance the perspective on what is currently happening on the platform.
Honestly? It doesn't help.
If or when any of those features need to slip to a future target, or we juggle the priority of anything else, I'll update the roadmap.
OK, I hope the ball called "CSS-Like Styling" is dropped in the juggling process and gets broken into pieces.
What the roadmap doesn't indicate is anything beyond features, and I need to improve how I communicate the non-feature work. Please know that the desire for improved quality, stability, and performance is very much shared and driving our day to day efforts.
I am positive Xamarin can pull it off. Even though Xamarin Forms was a framework nobody believed in and took Xamarin by surprise
@void said:
I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.
The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.
My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io)where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.
Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing. However, I generally agree with you. The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term. I'd wager my house that will prove to be the case. They will either have to use an approach like you recommend or go with a lightweight implementation that isn't so ambitious. There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.
@DavidCaraway said:
Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing.
Swing!? Yes, "plague" is the appropriate word.
The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term.
No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though.
Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.
Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework
It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.
I'd wager my house that will prove to be the case.
Don't. You will lose your house.
There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.
Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method.
Let's keep Silverlight dead for good. Please.
With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.
@DavidCaraway said:
Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing.
Swing!? Yes, "plague" is the appropriate word.
The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term.
No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though.
Might be a case of both
Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.
Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework
It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.
I'd wager my house that will prove to be the case.
Don't. You will lose your house. No I won't
Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method.
Let's keep Silverlight dead for good. Please.
With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.
Drawing controls was hardly my idea of a lightweight approach. I've been using homemade "lightweight" approaches since the time I first started using Xamarin. They are admittedly laughable though. I don't care. I work on my own dime. I go with what works. It's been a very long time since I've ever banged my head against the wall for days trying to find a workaround.
So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.
@DavidCaraway said:
So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.
I was going to argue that the right question is "when", not "if". But I think you're right. Anything in regards with technology has a deadline. Even if you do it, it might be too late, so yeah maybe "if" is correct.
@fabior@DavidOrtinau@MigueldeIcaza The image above is the Android hierarchy view of "Hello world" for Xamarin Forms (as is). It is 13 layers deep. For hello world. Our app, which is a pretty simple Tinder-like interface (one picture, few buttons, and some text) was several pages wide and would even crash hierarchy viewer OOM. We moved it out of XF into one giant custom renderer and now it's flat and fits in one page.
If you actually publish a purely XF app to the app store (rather than just building hello worlds), the google play developer console gives you warnings of slow UI threads over 50% of the time.
^ this is after a month of XF-only optimization. We've moved away from XF now.
I can't imagine how badly more complex apps are doing but I'm sure it won't be long before Google starts flagging those apps as underperforming.
Our team filed some of the original perf bugs in early 2016 but there really hasn't been enough progress on perf to reflect 12 months of work. So I agree with the other posters above that it's very frustrating when the Xamarin blog (and visual studio) keep bringing up new features when the core functionality is not production-grade.
@TonyD said:
I can't imagine how badly more complex apps are doing but I'm sure it won't be long before Google starts flagging those apps as underperforming.
Exactly, this is the unfortunate reality of Xamarin Forms app.
Our team filed some of the original perf bugs in early 2016 but there really hasn't been enough progress on perf to reflect 12 months of work.
Would love to see links to those if possible. Let's bring the discussion to the most practical level possible.
Let's force Xamarin to give feedback and take action on precise items. Otherwise it's just chit-chat "we're working on it \ things are improving".
So I agree with the other posters above that it's very frustrating when the Xamarin blog (and visual studio) keep bringing up new features when the core functionality is not production-grade.
Exactly my point too. I dislike a lot these gimmicks. Xamarin is doing themselves a grave disservice.
I'm not sure which person from Xamarin approved those blog posts. He shouldn't get a cake.
Posts
As examples: Google Play Services and OpenCV Manager
In related news from Google I/O: Support Library v26 adds Font Provider support, which utilizes Google Play Services to cache fonts across apps. (EmojiCompat also requires Play services, since they're fonts as well.)
As a note: Google Play Services typically just tells the user to update to the latest version, if an update is required.
I don't know how it handles compatibility with older apps.
OpenCV Manager makes it clear to the user which versions of OpenCV are loaded, and apps implementing OpenCV requests a specific version from the Manager.
As a result, I don't think it'd be completely unheard of for a common "Xamarin services" APK that handles management of Xamarin assembly versions required by apps that you use.
Great selection of upgrades. Thank you!
Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.
Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.
I agree that there needs to be a better way to find 3rd party components.
Preferably with a way to specify open-source (with links to Github) or license type.
Whenever I've gone to the Xamarin Components site, I've always left dissatisfied and ended up Googling what I wanted.
As a developer, I can certainly understand why Microsoft might want to promote (or allow developers to pay them to promote) paid components... But it often seems that this leads to a bunch of components unrelated to what I'm looking for being suggested instead.
As an example of a components discovery site done well, there's Google's https://www.webcomponents.org/
Granted, Google benefits from having great search algorithms...
Maybe the Xamarin team could get some help from the Bing team here?
In addition to improved discovery of 3rd party Xamarin.Forms components, I think it might be nice for the Forms team to re-evaluate how certain cross-platform components work.
e.g. The
TabbedPage: Google's Material Design spec (which has been promoted by @JamesMontemagno himself) now specifies Bottom Navigation which is analogous to Apple'sUITabBarController.Perhaps add a
TabPositionproperty that allows the user to specifyBottomorTopwith the default behavior being the current.The
Toptabs could be like the existing Android and WP implementation, with iOS possibly using aUISegmentedControladded to the Navigation Bar.I certainly respect that the original goal was to prefer a platform's behavior, in order to make the user of that platform feel more comfortable... But I'll note that the
MasterDetailPageis kind of foreign to native iOS.In native iOS, this would be a
UISplitViewControllerwith aUITableViewControlleras theMaster, rather than a slide-out drawer. To this day, Apple hasn't added a Navigation Drawer (and to the best of my knowledge as an avid iOS user, they haven't utilized any such control in their standard apps.)The Navigation Drawer only really rose to use in iOS as a result of people wanting cross-platform apps to behave more similarly.
For that matter, I actually think something more like a
UISplitViewControllerhas value as aPagecomponent.Let's take a "file manager" or email setup as an example: You click on the file or email that you want to view and (on small phones) transition to the detail view. Having a "slide-out" Navigation Drawer doesn't make much sense in that use case.
I believe you can just use
Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add aGetMyButton()method and use thex:Name.That is true that we could use Platform.GetRenderer, however I noticed a lot of problems when using it, these might be just bugs hopefully fixed in the future. (problems like rendering the native control, some things go missing or not converted correctly)
Also I wanted to mention another problem I always get with Renderers is their extensibility. Let's say I wanted to add different libraries to the Listview (ListviewRenderer). I would need to change immense a lot of code to support for instance swiping features which are available by third party libraries. (I tried it, and got even into issues of memory management, caching and other stuff which made it a separate project by itself. Definitely the handling of recycling without causing memory leaks was almost impossible). So I hope renderers get simplified and easier to manage in the future of Xamarin Forms 3.0.
@ChrisBoyd @CharlesRoddie great feedback, thank you. Discoverability between NuGet and the Component Store, and the overlap is something the component team has discussed needing and deserving improvement. I'll make sure to pass this along.
We are evaluating changing platform design, Bottom Navigation being a great example. And we'll be improving that. That's great feedback, thanks!
@DavidOrtinau I proposed Bottom Nav for android in the Evolution a while back. I would love to see this added as this is now the defacto material design for tabbed navigation
@Qwin please file some reports on specific renderers that have issue with Platform.GetRenderer. I'm not aware of any, so that would be very helpful.
Agreed, renderer extensibility is indeed an improvement we are making in 3.0, and ListView and cells is a big one.
Re: swipe cells, I just saw some work from @MatthewRobbins that did this and looked great.
thats great!
would be nice to have a link to the dev-sources, maybe to contribute some stuff!
@DavidOrtinau, @Qwin Regarding swipeable cells; I'm planning on doing a blog post and open sourced repo to show how we did it when I get the time.
@DavidOrtinau
When should we expect PR 853 to be merged into master? I need to start developing a new app that relies on this control. Instead of waiting till Q3, I'd like to work off of nightly builds or XF fork till Q3, but it'd be nice to see this in master soon.
Alternatively, I might grab the Nuget / plugin, so I'm debating if it's worth the wait. Please advise.
Is it time to do start doing some regression testing on Xamarin releases?
every time I update there is a surprise - the most recent ones were "build failed dll used by another process" and ios breakpoints aren't hit.
should there be some idea of a minimum software quality that's acceptable for release? or is it just whatever goes is ok? I don't get it.
to be honest Xamarin spoils the perception of quality of Visual Studio environment. takes it from 10-star to 1-star. Does anyone at Microsoft care about quality of VS as as development environment?
I'm seeing the iOS breakpoint issue when debugging on device. Simulator seems to work OK though. But the dll in use issue is getting really annoying.
Android is broken as well fyi. I think two things need to change. One, there really doesnt seem to be much internal testing what so ever when it comes to releases(alpha or otherwise). It appears the greatest testing asset they have currently is us. The second part is, because of the current issues with releases and cycles, it might be a good idea on the newly released channel selector for VS2017 to update the extension and allow us to pick a version to use instead of only 3 channels.
And dont stop there. Allow us to select which version we want with which OS. Currently there are issues with Droid that are find on iOS but then another version has one where something is fine on iOS but broken on Droid. It would be nice to just pick which version we can use best with each OS.
EDIT: To add, I hope I am not being too harsh. I know these quick non tested releases tend to happen more often than not during conference time unfortunately
. It isnt always this bad guys...
I am very excited about the g18n and RTL support, as it's the only thing holding me off from using XF right now. Well done guys!
I'm well aware of this issue, hence why we're stuck on cycle8 but at least we can debug.
WOW that's indeed a great list.
I'm especially turned on by XAML Standard.
Besides, I'm waiting for Xamarin to start supplying more controls, even non-native, maybe in a different namespace.
ItemsControl,RadioButton,CheckBox,DateTimePickeretc. With the lack ofItemsControlcounterpart, you feel like crippled.As a mainly WPF and former Silverlight dev concentrating in LoB apps, these controls are very demanding and are total deal-changers.
Anyway thanks for all your efforts guys, since MS acquired Xamarin it's definitely on the right path again!
@DavidOrtinau Thanks for the updates. Would it be possible to start a thread to discuss the new VisualStateManager on the roadmap? Keen to understand how this will work and what it will do, as we have built our own and interested to see what the migration path will be.
Thanks!
When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions
@DavidAllen I think the XF team is still busy implementing features no one asked for. Maybe once they're done with the 3.0 gimmicks they can focus on performance and the existing broken features again.
There are updates on the CarouselView if you follow the GitHub...
https://github.com/xamarin/Xamarin.Forms/pull/853
Xaamrin.Forms is still buggy
@DavidAllen, as Sean mentioned it its already decided what's gonna happen.
https://github.com/alexrainman/CarouselView
That's the controll which will be merged into XF and its recommended to use it until its part of XF...hopefully in Q3.
It works pretty well, especially compared to XF Carousel View.
I've just came after a few months to Xamarin Forms, and I though, that it would be more mature, then before... but it isn't.
God f.. damn it.
Everything is broken - building app requires some stupid workarounds - https://acaliaro.wordpress.com/2017/05/29/the-xamlctask-task-failed-unexpectedly/
Newest XF nugets has broken DataTriggers - https://bugzilla.xamarin.com/show_bug.cgi?id=56515
Everything is messy, building and signing apps required stupid workaround!
And if your project has multiple 3rd party components - like Telerik, or any other plugins, you are more and more in black hole of "it's not compiling at all, even your *.CS code is fine".
@seanyda & @wend0rlin, thanks for the information. I had assumed that the Xamarin Carousel control was the one they would be supporting. WIll migrate over
My thoughts too.
CC'ing Miguel and Nat: @MigueldeIcaza @NatFriedman
I'm sorry for having to say this but I've rarely seen a project so badly managed as Xamarin Forms.
Xamarin is announcing with fanfare on their blog different features in Xamarin Forms when in reality, there are still issues with common features or some are still missing.
iOS and Android support is still buggy and performance is pretty bad with even basic pages. It's not hard to see a lag when navigating between simple pages.
I understand Xamarin Forms will never have same speed as native, but looking at the code and architecture of the Xamarin Forms, it's obvious there is much room for improvement.
Despite the fact I still don't understand why Microsoft would pay many millions of $ in salaries for the implementation and support of a mobile development platform for Android and iOS, I thought after Xamarin joined Microsoft, Xamarin Forms development progress will "explode", given than there are extraordinary people at Microsoft who designed and implemented the XAML frameworks WPF, Silverlight, especially WindowsPhone, UWP, people which can help or at least share critical knowledge to Xamarin related to architecture and performance.
Xamarin encourages people to contribute, but there are important contributions in PRs which haven't been reviewed for weeks \ months:
These are just a few...
I'm NOT pointing fingers at the Xamarin Forms team members, they are not to blame! There's so much things to do and team is small.
It makes no sense. Xamarin Forms is announcing with fanfare Xamarin Forms 3.0 adopting XAML Standard (which will require a lot of work), support for Samsung's Tinzen, but in the same time you don't have time to really nail the support for at least iOS and Android.
Xamarin also announced in a blog post support for WPF, but "forgot" to mention that it's actually a PR by someone outside the team: https://github.com/xamarin/Xamarin.Forms/pull/895
I personally don't appreciate these marketing attempts at all, Xamarin is shooting themselves in the foot.
Also, what is "CSS-Like Styling" in the roadmap. Who asked for that?
How are you going to actually deliver all these promised features in a timely manner? Are they going to be just some half baked implementations like other features? When is XAML Preview for Xamarin Forms going to actually work 100%?
With the slow progress, by the time Xamarin Forms is really working, JavaScript (or something else) will look and work like C# and web development will have almost all the capability of native, including access to camera and sensors. Some of these are already happening.
I'm sorry but Xamarin Forms looks to me mostly like a marketing gimmick used by Microsoft.
It's a shame that Forms is giving Xamarin a bloody nose. I've been using Xamarin.iOS and Xamarin.Android for years and they have benefitted me tremendously. They are both rock solid technologies. With good design you can achieve high code reuse between platforms. That said, I will give XF Embedded a spin. That's a feature I will welcome. I suspect a lot of developers who have not been brave enough to fully adopt Forms are looking forward to the ability to integrate Forms in such a manner. That particular part of XF 3.0 is going to be well received. Not by those who jumped fully into Forms but by those who didn't but would like to leverage just parts of XF. If it turns out that even that is too buggy I'll just go back to doing what I've been doing....which works perfectly. Being able to use the same UI code will be nice but I have to keep things in perspective. A recent project had me adding several non-trivial dialogs to one of my enterprise apps. It only took me 2 days to fully duplicate the dialogs in iOS on Android. Granted, I don't have a desktop version of the app too.
Although, I waste my time one more time to write here (it’s at least good for my nerves and my soul)...
@fabior is absolutely right...
I have posted the thread below in May 2015
https://forums.xamarin.com/discussion/41588/how-to-make-forms-stable/p1
It was interesting for many, many users (see thread) and contains many useful proposals...
Instead of take the proposal serious and improve the processes, Xamarin has “deactivated” the thread by prevent it from pop, if a new posting was added...
You can copy-paste the information’s in the thread from May 2015 to May 2017...
I further had direct contact to some Xamarin employees (to .forms and to the VS-integration) in the history and have wasted more time by describe the problems in detail and further describe proposals in detail...
Nothing has changed...
The base still don’t work (debugger often don’t work, variables are not viewable in debugger, the whole development environment works not stable and is very slow)
And... this is daily base work of every developer and cost ”count of developer” x “every day wasted time”
For Xamarin, it’s further self-evident, that:
Every update (.forms but also new versions of VS integration SW, VS versions, and also all related SW like MAC, OS, Xcode and so on) has to be feared, as the chance is greater than 50% that the app will not be usable after the update and every developer has to invest hours if not days, only to be able to compile and user the app again after the update...
How should we be able to work productive in such an environment...?
Instead of make the base (.forms itself and the related software) rock-solid, nothing in the processes is changed (copy-paste from 2015), but new, not needed and not working “features” are added so that .forms becomes more and more instable...
Periodically (once again in this thread) , Xamarin say’s, that the bug solving and stabilization hast the highest priority...
I... don’t... can... see... any sign..
So the proposals in the thread of 2015 still are valid in 2017!
Please hold your promises:
Make no mistakes, Xamarin Forms is a great technology!
However, I think due to poor management, because team remained too small, it's been progressing slow, too slow.
It's a bit irresponsible from Xamarin to engage and promise to developers so many Xamarin Forms features at once, not being able to make at least iOS and Android(which is what mobile is today) run as good and as fast as possible.
Xamarin should stop everything and have a simple roadmap for 2017:
Refactor \ rewrite Xamarin Forms with an architecture which delivers as much performance as possible. Since Xamarin is part of Microsoft, I was expecting Microsoft's XAML platform (especially Windows Phone since it runs on mobile) architects to help with this.
Stabilize as much as possible the implementation for iOS and Android.
Add as many features related to controls and XAML as possible. For this, listen to developers. Don't promise features like "CSS-Like Styling" which honestly do not make much sense. How did that go into the roadmap?
In parallel, at least make Xamarin Forms XAML Preview work as good as possible.
I've seen tweets from Miguel this week about hiring new people to join Xamarin Forms team. Which is good news.
I hope at least 5-7 positions are available.
But this is unrelated to starting and promising too many features at once, instead of focusing on iOS and Android.
I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.
The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.
My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.
@void said:
Yeah, that's part of the developer's job. But please let's not mix up the usual challenges with Xamarin Forms still not being to draw the borders of a Button correctly in all versions of Android. There's a very recent fix, like a week ago, for that, which hopefully will go soon into the released package. And this is only an example, there are several others referring to bug in controls or incomplete basic features. And of course, again there's the performance issues(converting all renderers to the new "fast" renderers should be a priority).
Again: I am NOT pointing any fingers at the Xamarin Forms team members. The team is too small, very small, I wish the team got bigger soon after Xamarin joined Microsoft. More than 1.3 years passed and that didn't happen.
Meanwhile, Xamarin has been promising A LOT of crazy new stuff while implementation for Android and iOS still has issues.
You mean Silverlight-like where buttons for example are not native but drawn by painting brushes? Oh please for God's sake, no!
Hi all, there's a lot here, but let me give you a general update on what we are working on now and have been since Build.
Quality. Period.
The reason you're not seeing movement on feature PRs is our core team is only working on fixing bugs and improving quality. This extends beyond commits to Support and CI and QA and Testing processes as well. Issue reports incoming have been steady or dropping, and we are making great progress on the overall backlog of issues. Numbers aren't everything, but it's one metric I'm reporting on. Priority and severe issues (performance, crashes, leaks, volume of users impacted) is another and the team is clearing tons of those.
The blog is a marketing and education channel. It is not an indicator of what the core engineering team is doing on a daily basis.
Tizen is a contribution by Samsung. WPF and GTK# are contributions by contractor teams. Our core engineering team is not actively coding on those.
We are hiring.
I hope this small update helps balance the perspective on what is currently happening on the platform.
What does this mean for the feature roadmap and the things announced as a part of 3.0? As we have always said, the roadmap will change as needed but it communicates our intention and the current roadmap is still just that. If or when any of those features need to slip to a future target, or we juggle the priority of anything else, I'll update the roadmap.
What the roadmap doesn't indicate is anything beyond features, and I need to improve how I communicate the non-feature work. Please know that the desire for improved quality, stability, and performance is very much shared and driving our day to day efforts.
I just hope the practice of marking a bug as FIXED or COMPLETED on Bugzilla when the issue it's actually not fixed nor complete, goes away.
If you want to have Bugzilla as purely feedback forum, like the "user voice" site, then fine, but state that clear. Otherwise it's not OK to mark bugs as FIXED or COMPLETED with a message like "we're already working it". If you're working on it, it's not complete.
While an open issue might not look OK on the statistics, by closing an issue like that you're showing the middle finger to the developer who spent time reporting.
I am not sure what you mean by that. I should not take the blog seriously?
Also, marketing? What are you guys selling?
I was aware of that.
But given the fact that you don't have time to evaluate PRs for features much more important than WPF support, it would make sense to honestly communicate that while you're announcing WPF support, that's just a contributor PR, something you might even have time to take a look at. Although, it was funny to see how easily the WPF PR was accepted. But If I were to start using it to tomorrow, I have no idea though what's supposed to work or not....
Yep, like I already mentioned, thumbs up for that. And again, I hope the # of positions is at least 5 or 7.
The most important aspect however remains the architecture and performance. Hiring more people won't fix the issues if things continue to be in 20 different directions, Xamarin Forms will continue to be Jack of all trades, master of none.
Honestly? It doesn't help.
OK, I hope the ball called "CSS-Like Styling" is dropped in the juggling process and gets broken into pieces.
I am positive Xamarin can pull it off. Even though Xamarin Forms was a framework nobody believed in and took Xamarin by surprise
Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing. However, I generally agree with you. The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term. I'd wager my house that will prove to be the case. They will either have to use an approach like you recommend or go with a lightweight implementation that isn't so ambitious. There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.
Swing!? Yes, "plague" is the appropriate word.
No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though.
Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.
Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework
It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.
Don't. You will lose your house.
Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method.
Let's keep Silverlight dead for good. Please.
With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.
Might be a case of both
Drawing controls was hardly my idea of a lightweight approach. I've been using homemade "lightweight" approaches since the time I first started using Xamarin. They are admittedly laughable though. I don't care. I work on my own dime. I go with what works. It's been a very long time since I've ever banged my head against the wall for days trying to find a workaround.
So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.
I was going to argue that the right question is "when", not "if". But I think you're right. Anything in regards with technology has a deadline. Even if you do it, it might be too late, so yeah maybe "if" is correct.
@fabior @DavidOrtinau @MigueldeIcaza The image above is the Android hierarchy view of "Hello world" for Xamarin Forms (as is). It is 13 layers deep. For hello world. Our app, which is a pretty simple Tinder-like interface (one picture, few buttons, and some text) was several pages wide and would even crash hierarchy viewer OOM. We moved it out of XF into one giant custom renderer and now it's flat and fits in one page.
If you actually publish a purely XF app to the app store (rather than just building hello worlds), the google play developer console gives you warnings of slow UI threads over 50% of the time.
^ this is after a month of XF-only optimization. We've moved away from XF now.
I can't imagine how badly more complex apps are doing but I'm sure it won't be long before Google starts flagging those apps as underperforming.
Our team filed some of the original perf bugs in early 2016 but there really hasn't been enough progress on perf to reflect 12 months of work. So I agree with the other posters above that it's very frustrating when the Xamarin blog (and visual studio) keep bringing up new features when the core functionality is not production-grade.
@TonyD That's really an excellent feedback! I hope @MigueldeIcaza @NatFriedman or @DavidOrtinau takes a minute or two to respond...
Exactly, this is the unfortunate reality of Xamarin Forms app.
Would love to see links to those if possible. Let's bring the discussion to the most practical level possible.
Let's force Xamarin to give feedback and take action on precise items. Otherwise it's just chit-chat "we're working on it \ things are improving".
Exactly my point too. I dislike a lot these gimmicks. Xamarin is doing themselves a grave disservice.
I'm not sure which person from Xamarin approved those blog posts. He shouldn't get a cake.