|
From Feature Roadmap · xamarin/Xamarin.Forms Wiki · GitHub[^] as of 1st March:
Transition to .NET MAUI
July 15, 2020 Pull Request Policy Changes
As noted below, Xamarin.Forms 5.0 is due out at the end of September. At that time we will re-sync dotnet/maui and work on preparing our first preview release of .NET MAUI. In order to be considered for release by or before Xamarin.Forms 5.0, feature pull requests should be submitted for review by July 15.
After July 15, any new feature pull requests may still be submitted to this repository (xamarin/xamarin.forms). We will label those for migration to dotnet/maui. Be aware that the bulk of renderer refactoring will happen after Xamarin.Forms 5.0, so contributions to controls and renderers may require refactoring.
Pull requests to fix issues will continue to be reviewed through November 2022, and sync'd with dotnet/maui using a combination of automation and manual implementation.
The text above has now been replaced with this:
Current Version
Xamarin.Forms 5.0.0 is the current stable release. Release notes
We will continue to service Xamarin.Forms 5 through November 2022.
Next Major Version - .NET 6
The development of our next major version is underway at dotnet/maui. .NET MAUI will ship with .NET 6, now in preview.
Your existing and new Xamarin.Forms applications will migrate to .NET MAUI with tooling assistance and documentation which we will provide later in the .NET 6 preview timeframe.
Also see MAUI in .NET 6: Xamarin.Forms Does Desktop, but Not Linux or VS Code -- Visual Studio Magazine[^].
|
|
|
|
|
Thank you!
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
Kevin Marois wrote: Is Xamarin really dead?
Yes.
Failed marketing.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Marketing alone can't bridge failed effort.
I've considered picking up Xamarin for 3 different projects during the course of it's existence. Never did.
The appeal of Xamarin was having a C# compatible front-end that could replace SilverLight in the LoB space.
In theory, XAML components could be written and tested for WPF desktop use, and then be ported to mobile platforms with low overhead costs.
Or, to put it pragmatically: it made Android and iOS expansion look cheap if you where doing WPF at the time.
In practice, the benefits just never materialized.
They used Mono as their C# framework, which is probably what killed them in the end. Mono is great for running arbitrary C# code, but it doesn't support WCF and a bunch of other business-oriented one-offs that are cheaper to propagate than to replace.
Their XAML was a dialect, so none of the major XAML designers could create Xamarin compatible components, making the use of XAML entirely pointless from a budget perspective.
At the time, I really thought they would contribute to XAML Standard 1.0, or at least align with a XAML designer.
But, as time went on, it seemed like they doubled-down on their core-value without ever really having one.
|
|
|
|
|
You need to consider that the article is written by a services company that wants it dead. Of course it will find all sort of reasons (some far from the truth: Xamarin developers hate it, Rider is the editor, really?!) that is dead and point you to the direction it wants - from their website, flutter and native.
Viewing the issue objectively, I think the future of Xamarin is in-line with the future of .NET - unifications - and it will not just die (as some might want). If that is called Xamarin, MAUI or whatever, that's just marketing term.
Obviously, things change as they evolve and some things might be dropped but I highly doubt it Xamarin Forms based apps will just stop working or won't be migrated.
It comes down to: would you trust Microsoft or foresightmobile for the future of Xamarin? I bet on Microsoft.
Eusebiu
|
|
|
|
|
"It comes down to: would you trust Microsoft or foresightmobile for the future of Xamarin? I bet on Microsoft.".
Microsoft may be a better bet but that doesn't mean that you might not someday still be left behind.
Microsoft technologies that I used in the 90s and 00s that got dropped after we had committed years of development to them include:
Visual C++ cross-compilation to Mac
Visual J++ (and the Microsoft JVM)
Visual Basic 6.
|
|
|
|
|
Quote: Microsoft technologies that I used in the 90s and 00s that got dropped after we had committed years of development to them include:
Visual C++ cross-compilation to Mac
Visual J++ (and the Microsoft JVM)
Visual Basic 6.
Don't get me started. I'm a VB.NET web developer. After years of being told that language selection was a "life-style choice", I'm now being told that for web development C# is the only option moving forward.
--A. Lovhaug
|
|
|
|
|
I wasn't very excited about the switch to C# but it ended up taking about 3 days.
|
|
|
|
|
MadGerbil wrote: I wasn't very excited about the switch to C# but it ended up taking about 3 days.
I could, but my plan is to go a different route as I'm a freelancer and my customers don't care about the technology choices. Instead, I intend to switch to RemObjects Mercury, which is almost fully compatible with VB.NET, plus supports many platforms, including ASP.NET Core, WASM, iOS, Android, and Linux development. Currently in beta, and the company is very responsive.
--A. Lovhaug
|
|
|
|
|
|
I don't think it got to mainstream - WPF which is also present "evolved" into Xamarin Forms, WinUI/UWP/MAUI and also into Uno (which in my opinion is the most complete one). So, those skills are not dead if one wants to continue with XAML/C#!
If you ask me, Silverlight was killed by HTML5/CSS3.
Eusebiu
|
|
|
|
|
Any technology comes to an end due to various reasons but Microsoft always provided ways forward (maybe with technologies that did not make it to mainstream).
Eusebiu
|
|
|
|
|
|
Use Flutter. Even that article suggests so. You can code Flutter using Visual Studio Code, which is one of the most popular editor right now.
|
|
|
|
|
I actually enjoy reading C++ reference documentation because of all the plot twists. Take for example:
A constexpr function must satisfy the following requirements:
it must not be virtual (until C++20)
Way to bury the lede guys! So the compiler can call virtual functions at compile time in C++ 20?
Or wait. Maybe (slightly) more sane, it can eliminate virtual calls to a target class altogether if that virtual can be made constexpr?
 
I don't know if I should be elated or terrified for what they've done to C++
Real programmers use butterflies
|
|
|
|
|
I believe constexpr means that the value can be computed at compile time. I guess this could apply even to virtual functions, with the value placed in, and accessed from, the vtbl.
|
|
|
|
|
Quote: it can eliminate virtual calls to a target class altogether if that virtual can be made constexpr?
That's about right. Peter Dimov and Vassil Vassilev started this one with: Allowing Virtual Function Calls in Constant Expressions
Their key argument was: Since in a constant expression the dynamic type of the object is required to be known (in order to, for example, diagnose undefined behavior in casts), the restriction is unnecessary and artificial.
This argument will probably propagate to all corners of the language were it applies, because that only makes sense.
Quote: I don't know if I should be elated or terrified for what they've done to C++
Elated.
While not every (if any?) compiler implementation currently provide full C++ 20 support, things are improving.
Compile-time expression evaluation and meta-template programming are immensely useful, but until now you could only do useful stuff in ways that were hard to understand, requiring all sorts of template trickery.
With C++ 20 I can do meta-template programming more easily, and even more important: easily explain what I do to other people.
With constexpr functions, the need for most of the template trickery that has evolved over the last decades goes away, and once that door was opened people started to ask reasonable questions, such as:
I know that the compiler knows which implementation of a virtual function will be called at runtime, and if that is the case, it would be awfully nice if I could use that function in a constant evaluated context, so how about we put that into the standard?
And, now that we have ranges, I guess many C++ developers will do pretty sophisticated meta-template programming without even realizing it - and suddenly it will not be scary anymore, because we are all doing it.
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
modified 13-Mar-21 19:30pm.
|
|
|
|
|
Espen Harlinn skrev: And, now that we have ranges, I guess many C++ developers will do pretty sophisticated meta-template programming without even realizing it - and suddenly it will not be scary anymore
I will still be scared. And let's not pussyfoot around: the goal of template metaprogramming is to eliminate the need to run programs. Simply compiling them will enough. 
|
|
|
|
|
Quote: Simply compiling them will enough.
There is a surprising amount of truth to that. 
When I look at stuff I've done previously, I'm surprised by the amount of things that can be computed ahead of time.
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
If they can get rid of the code bloat and eliminate all the stuff i never use at run time once the compiler is done with it rather than leaving orphaned code in my binaries I'll be happy, since I do a lot of IoT development where RAM, program space, and CPU cycles are all at a premium. I feel like I need metaprogramming a lot but I often can't afford it.
Real programmers use butterflies
|
|
|
|
|
Quote: If they can get rid of the code bloat
With the latest compilers there should not be much, if any, of that.
Quote: I feel like I need metaprogramming a lot
you do 
Quote: I often can't afford it.
and you can …
While coding I still find that I am continuously backsliding towards my pre C++ 20 ways of doing things. That is my fault, and not an inherent deficiency of C++ 20.
When I succeed at getting into "C++ 20" mode, shedding much of the mental baggage accumulated over more than 25 years of C++ development, the machine-code generated by the compiler is usually superior to the machine-code generated for code developed in pre "C++ 20" mode.
When I reason about code in "C++ 20" mode, how things will be laid out in memory comes more into focus, while in pre "C++ 20" mode there is more emphasis on the flow of execution - this is obviously very subjective, since this is me reviewing my own ways of thinking. What I think is interesting, is that the actual execution paths for the code I develop when I manage to get into "C++ 20" mode is shorter than before, sometimes significantly so.
For me, altering how I reason about coding is pretty d**n hard work. Reasoning about code in terms of compile-time computations and type selection, is not all that hard - making my brain pick solutions based on that, while actually trying to solve something else is, and that is what I mean by "C++ 20" mode.
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
I don't have access to the C++20 standard on my cross-compiler toolchain for my embedded devices - precisely where I need it the most.
The best I can do right now is C++17.
Real programmers use butterflies
|
|
|
|
|
Quote: The best I can do right now is C++17
Which makes it harder, perhaps even unpalatable … personally, I was never a great fan of std::enable_if<>, even if it performs something very useful. Concepts nearly made it into C++ 11, and I don't think anybody expected 9 more years to pass before we got a decent alternative to std::enable_if<> …
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
On the bright side, it gives me a chance to get up to speed.
I just now caught up to C++11 variadic templates which allows me to do a lot more metaprogramming (or at least more easily) than I used to be able to do.
I'm doing it for now, without using STL for it just because I want to make sure I get the mechanics of any of the library I rely on. The standards docs are just never that helpful to me for expressing concepts and rationales but I can learn those by implementing them myself.
I'm doing pretty well with it right now. I've got a pixel template struct, that takes a series of channel traits that describe "channels" that make up a pixel (usually color channels R, G, B, but also it supports other color models, grayscales, monochromes) etc, - you can specify the bit depth and layout of the bits for the whole thing, including endianness.
I needed it because "device drivers" on IoT devices don't exist, and LCD screens and JPEGs and PNGs each have very different binary pixel formats. And LCD screens come in a variety of binary pixel bitmap formats at a variety of capabilites.
Keep in mind I'm not using iostreams below because it adds static initialization code and other cruft that's interfering with my ability to examine the output in assembly
And I can't afford to mess with any of this at run time. So I've made a little something to give me rich compile time pixel information I can use to do things like resolve the shifts I need to do pixel channel manipulation (like changing the "green" color component of a 16-bit rgb565be value (big endian) which is six bits squashed in the middle and then (if you're on an LE platform) flipped.
Anyway, I'm still working on it, but what I have so far incurs no overhead for anything.
So:
typedef channel_traits<channel_name::R, channel_kind::color, uint8_t, 5> red_5bit_color_channel_t;
typedef channel_traits<channel_name::G, channel_kind::color, uint8_t, 6> green_6bit_color_channel_t;
typedef channel_traits<channel_name::B, channel_kind::color, uint8_t, 5> blue_5bit_color_channel_t;
typedef pixel<uint16_t, color_model::rgb, false, red_5bit_color_channel_t, green_6bit_color_channel_t, red_5bit_color_channel_t> rgb565be_t;
rgb565be_t p;
constexpr static const int index = 1;
using ch = rgb565be_t::get_channel<index>;
printf("index: %llu ",(unsigned long long)ch::index);
printf("name: %s, ",ch::name);
printf("type: %s, ",to_string(ch::kind));
printf("int-type size: %llu, ",(unsigned long long)sizeof(ch::int_type));
printf("min: %llu, ",(unsigned long long)ch::min);
printf("max: %llu, ",(unsigned long long)ch::max);
printf("bit-depth: %llu, ",(unsigned long long)ch::bit_depth);
printf("bits_to_left: %llu, ",(unsigned long long)ch::bits_to_left);
printf("bits_to_right: %llu, ",(unsigned long long)ch::bits_to_right);
printf("mask: %llx, ",(unsigned long long)ch::mask);
printf("pixel_mask: %llx\r\n",(unsigned long long)ch::pixel_mask);
Ouput
index: 1 name: G, type: color, int-type size: 1, min: 0, max: 63, bit-depth: 6, bits_to_left: 5, bits_to_right: 5, mask: 3f, pixel_mask: 7e0
Assembly
.LC0:
.string "index: %llu "
.LC1:
.string "G"
.LC2:
.string "name: %s, "
.LC3:
.string "color"
.LC4:
.string "type: %s, "
.LC5:
.string "int-type size: %llu, "
.LC6:
.string "min: %llu, "
.LC7:
.string "max: %llu, "
.LC8:
.string "bit-depth: %llu, "
.LC9:
.string "bits_to_left: %llu, "
.LC10:
.string "bits_to_right: %llu, "
.LC11:
.string "mask: %llx, "
.LC12:
.string "pixel_mask: %llx\r\n"
main:
push rax
mov esi, 1
mov edi, OFFSET FLAT:.LC0
xor eax, eax
call printf
mov esi, OFFSET FLAT:.LC1
mov edi, OFFSET FLAT:.LC2
xor eax, eax
call printf
mov esi, OFFSET FLAT:.LC3
mov edi, OFFSET FLAT:.LC4
xor eax, eax
call printf
mov esi, 1
mov edi, OFFSET FLAT:.LC5
xor eax, eax
call printf
xor esi, esi
mov edi, OFFSET FLAT:.LC6
xor eax, eax
call printf
mov esi, 63
mov edi, OFFSET FLAT:.LC7
xor eax, eax
call printf
mov esi, 6
mov edi, OFFSET FLAT:.LC8
xor eax, eax
call printf
mov esi, 5
mov edi, OFFSET FLAT:.LC9
xor eax, eax
call printf
mov esi, 5
mov edi, OFFSET FLAT:.LC10
xor eax, eax
call printf
mov esi, 63
mov edi, OFFSET FLAT:.LC11
xor eax, eax
call printf
mov esi, 2016
mov edi, OFFSET FLAT:.LC12
xor eax, eax
call printf
xor eax, eax
pop rdx
ret
Real programmers use butterflies
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
