Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery

Lorne Kates

So for the past couple months, I've been dabbling in learning how to make apps. For all my career thusfar (and most of my schooling), I've dealt solely with web development. My mind is completely entrenched in the "stateless request/reply" paradigm. I figured this would be a good way to keep from falling too much into a rut, and who knows, maybe get things on an app store or two.

After some research (ie: 5 seconds of Googling #Millenial), I settled on Xamarin Forms for Visual Studio. Mainly because I use Visual Studio every day, so I'm used to it. And because I've done development in not-Visual Studios, both for personal and professional work, and it is much like eating a glass bottle, shitting out the glass shards, then gathering up the mess of glass-shards-and-intestine pieces, and eating that again. So I'd rather just stick to an IDE that works.

Xamarin made a name for themselves making a cross-platform framework-- as much of it in XAML (instead of HTML), and c# code-behind, with minimal interface overrides for platform specific (Android, IOS, Windows PHahahahahahahahahah yeah right). Then they got bought by Microsoft, rolled into Visual Studio, and that's where we are.

Since this was to be a whole new learning experience, I figured I might as well hop on board with the latest and greatest. I installed Visual Studio 2017-but-is-constantly-updated-because-developers-love-everychanging-and-unstable-code-to-work-with, and snagged the latest Xamarin Forms from NuGet (new get? nugget? fuck off whichever, you Kid Rock humping asshole). Went right to xamarin's own page, to documentation, to getting started, and...

Well, my experience so far has been littered around the various Status and WTF-esque threads. Mostly laden with swears. If I had known it was going to be like this, I would have started this thread long ago. But from memory:

The documentation was a couple months old. In other words, the Xamarin platform and Visual Studio interface had both radically changed since, because see above comment about constantly upbreaking. So not only did the Quick Start demo have incorrect information in every screen shot (including what type of project to select, and the options to use)-- but the code itself on the page was broken and wouldn't compile. Because they kept updating the .Net Framework the project target. And just switched to Core 2.0 or whatever. And they DIDN'T BOTHER TO UPDATE THE SINGLE MOST IMPORTANT ENTRY POINT DOCUMENTATION FOR ANY NEW DEVELOPER!
Even after getting latest on everything, when trying to compile and run on Android, VS threw an error saying my Android SDK was out of date. The output window had a guide on where to go in Visual Studio to launch the SDK manager, and where to click to update the SDK. Literally every single step of that process was wrong.
Did I mention most of their sample code is also broken? (Beyond the getting started).

This is almost Blackberry-level of shitty development support.

So after following way too many StackOverfuck threads, modifying the stock code, and having to manually change things in the .vsproj (!!!) file, I got a Hello World to pop up.

And then the adventure begins. I'll post my fuckery here. I already have a couple lined up.

Lorne Kates

First is their rather shitty documentation. Want to know how to put a header on your listview? Well, Intellisense tells you that you can do ListView.Header or ListView.HeaderTemplate. The documentation tells you-- nothing. You need to Google for those to find a dozen StackOverflow threads asking how the hell you do a header, to be pointed to other StackOverflow threads, to finally be pointed to a GitHub with someone's Hello World for it.

The ListView is one of the most basic and oft used controls.

Lorne Kates

Speaking of ListView; much like in .Net, you can use databinding. Basically, you give it an object that's a dataset, or some other IEnumerable, and say Bind. In your HTML, you'd use binding constructs to access the data columns, or other public properties via reflection with Eval.

<a href='<%# "http://example.com?id=" & Eval("itemno") %>'><%Eval("ItemName")%></a>

Pretty easy. Since Xamarin is leveraging the .Net framework, it'll be just as easy, right?

ahahahahahha-a-- nope.

Instead, on SOME properties of SOME controls, you would do binding like this: <Label Text='{Binding ItemName}' />

Why the different syntax? I mean, sure the project started life as it's own non-VS thing-- but it's been YEARS since it's been rolled into Visual Studio. Surely using the convention Visual Studio developers are already used to would be-- you know-- smart.

Lorne Kates

And it's even better. Consider this from .Net

<asp:Label runat='server' id='lblOutOfStock' Text='No Stock!' Visible='<% Eval("IsOutOfStock")' />

Nice. Easy to understand. How does Xamarin do it?

Is that a blank codeblock? Yes it is, because XAMARIN DON'T! For their databinding, everything is treated as a String. And I don't mean Object.ToString(), so that 1 becomes "1". The binding property has to be a string. If it isn't a string, then you have to use a String Format. As in:

<Label Text="{Binding IsOutOfStock, StringFormat='Is this out of stock? {0}'}" />

That's how you get ToString. You'll notice the fact that both the Binding statement AND the String Format statement use { } constructs. Yup. If you don't enclose the StringFormat inside quotes (which are already inside quotes because of the Text property), it could blow up the XAML compiler.

pie_flavor

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Speaking of ListView; much like in .Net, you can use databinding. Basically, you give it an object that's a dataset, or some other IEnumerable, and say Bind. In your HTML, you'd use binding constructs to access the data columns, or other public properties via reflection with Eval.

<a href='<%# "http://example.com?id=" & Eval("itemno") %>'><%Eval("ItemName")%></a>

Pretty easy. Since Xamarin is leveraging the .Net framework, it'll be just as easy, right?

ahahahahahha-a-- nope.

Instead, on SOME properties of SOME controls, you would do binding like this: <Label Text='{Binding ItemName}' />

Why the different syntax? I mean, sure the project started life as it's own non-VS thing-- but it's been YEARS since it's been rolled into Visual Studio. Surely using the convention Visual Studio developers are already used to would be-- you know-- smart.

That's actually standard for XAML. It's different for HTML, but this isn't the same process as HTML - instead, it's the same process as WPF and UWP apps. The convention you're talking about is the one that's standard for ASP.NET webpages, which this isn't.

blakeyrat

@lorne-kates I think part of your confusion here is mixing up Razor (if it's still called that-- the standard HTML templating engine in ASP.NET) with XAML, which is wholly unrelated AFAIK.

Lorne Kates

AND IT'S EVEN BETTER!

Consider this from .Net

<asp:Label runat='Server' id='lblGameOver' Text='Game Over!' Visible='<%# CurrentGameState = GameStates.GameOver %>' />

Well, we've already established Xamarin doesn't handle typed objects, but even if we convert it into a String, how do we do comparison like that?

Another blank code block. The databinding is only for output. There is no evaluation at all. None. If you want to do something like the above, you have to use a "converter". Which is a whole complicated function. I'll save you the bullshittery, but this is how I would do the above:

        <Label x:Name="lblGameOver" Text="GameOver"
                  IsVisible="{Binding CurrentGameLoopInputState, 
            Converter={StaticResource isCurrentGameStateConverter}, 
            ConverterParameter={x:Static local:ViewModel.GameLoopInputState.GameOver}}"                  
 />

Of course "StaticResource" sounds fishy, right? Because you have to declare that resource (which is a reference to a what will do the converting) in the Xaml resources:

<local:IsCurrentGameState x:Key="isCurrentGameStateConverter"  />

AND IT DOESN'T END THERE, because you still need a WHOLE CLASS TO DO THE COMPARISON!

    public class IsCurrentGameState : IValueConverter
    {

        object IValueConverter.Convert(object value, Type targetType, object parameter, CultureInfo culture)
        {
            bool rv = false;

            rv = value.Equals(parameter);

            return rv;
        }


        object IValueConverter.ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
            throw new NotImplementedException();
        }
    }

All that just to check if a bindable value is equal to something else. And notice it's value.Equals(parameter), because those Enums are passing in as strings. Not a string'd integer. But the actual string "GameState.GameOver".

Because in 2018, strongly typed objects iz hard.

The_Quiet_One

You are triggering every stressor I've had when I was delving into Xamarin a year or two ago. Just wait until you get into building your app for iOS, although that's more of a general mobile app problem that Apple created for people who dare develop in an OS they didn't create.

Lorne Kates

And then there's today's dumbshittery. Some foundation dumbshittery first...

Even though .Net has a billion different, useful IEnumerable objects you can bind to-- like List<T> or Dictionary<T, T> or any other you can think of-- well you can't bind a ListView to those. Why?

Because Xamarin has it's OWN class you need to bind to. ObservableCollection<T>. I sortof understand the basics of why. The ObservableCollection also implements INotifyPropertyChanged, which lets any controls binding to this collection be alerted when the collection changes OR when the properties of one of it's T has changed.

But why couldn't that observer be part of the Xamarin ListView (and other controls) rather than rewrite the standard collections. But never mind. As long as they've just inherited from List<T>... hahahaha, just fucking kidding.

They implemented it from scratch. Which means it doesn't have:

AddRange(array)
Sort
Other things that fucking should be there because they are part of every fucking .Net collection you cockchoking cockholes!

...

masonwheeler

As has been pointed out already, these things you are ranting about are not Xamarin issues; they're XAML issues, created by Microsoft as part of the massive that is WPF.

Lorne Kates

... so anyways, the actual dumbshittery.

ObservableCollection bound to a ListView. The ListView is showing the current roll of the dice-- a collection that will change as dice are rolled, added, and put aside for scoring.

Knowing that the UI layer and the rest should be separate-- especially if I ever want to implement a game server-- I have the non-UI work spun off into a thread.

User pressed "Roll Dice", UI layer notifies the thread, then waits for the GameState to change (which is INotifyPropertyChanged).

Game layer rolls the dice, splits them into groups, etc, etc. It assigns each of the groups a unique GroupHeader, and changes the GameState to "RollHasOccured".

And Xamarin crashes with a "This Key has already been added to the collection". Anyone in .Net knows this is what happens when you add the same value to a unique collection. But I'm absolutely 100% sure all the GroupNames I gave are unique. Check again and again. Download and cache all the Xamarin symbols so I can even see where the stacktrace is (because, of course, by default, it's in system code and no useful information is given in the exception). I can't really make heads or tales, but from what I can tell, it's when the Xamarin framework is grouping together my bound collection into groups. BUT ALL THE GROUPS ARE UNIQUE!

Lots of Googling later, and I find a StuckOverfuck thread with someone who has the same error. (Notice I keep saying StackOverflow-- and not Xamarin's own forums or documentation. Yeah).

OP is all "wtf I'm doing listview binding with grouping here's my code wtf"

Someone (I don't even know if they are from Xamarin or not) finally replies. "You can't do Grouping if you are modifying an Observable Collection in a thread".

Accepted answer.

Wawhatfuyajlksd;f?!? HOW? WHY? No reason given. No technical limitation. No links to a KB on the Xamarin site. Just "LOL FUK YOU".

And when I instead raise an event and have the UI thread do the re-binding-- lolnope, because the new dataset came from the not-UI thread, Xamarin throws an exception when that dataset tries to modify any UI.

So you have to instead make your ViewModel inherit from Activity (in the Mono framework), which in turn exposes a RunInUIThread function which you give your function to, and then that function is run in the UI thread and THEN you can work with that dataset.

Which entirely breaks the concept of Xamarin of "Just databind to things and let OnPropertyChanged notifications handle the changes in the UI for you"

aaaaaaaaaaaaaaaaaa

Lorne Kates

Oh, and last thing (that I can think of).

There's no pre-compiler errors for syntax errors in your XAML.

Did you accidentally put <Label Visible='False' /> instead of <Label IsVisible='False' />?

Well, go ahead and start debugging-- launch the Android simulator, compile your code, build your apk, send it to the simulator, simulator launches your code-- that all takes time--

Only to have the code Exception out with what MAY (but probably isn't) be a useful error message. If you're lucky, you'll get "Visible is not a property of Label". Otherwise you get a generic Object Reference exception, or something else vague and unhelpful.

Lorne Kates

And the worst thing about all this?

THIS IS THE BEST-IN-THE-MARKET FRAMEWORK TO USE THAT MEANS ANY OTHER ONES THAT MAY EXIST AR WORSTT THAN THEESSKJHLDKJFHLJ

Lorne Kates

@masonwheeler said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

are not Xamarin issues; they're XAML issues

Guess why Xamarin's name starts with an X.

As far as I'm concerned, it's a Xamarin issue if it fucks up when I'm trying to use the Xamarin framework.

And it ABSOLUTELY is a Xamarin issue if they can't keep their fucking documentation up to date-- at least enough that their "developer's first code" examples actually work.

Lorne Kates

Yes there's a typo in the title (continuing) but I don't see where Edit Title is anywhere so FUCK IT, it stays.

Also Firefuck has decided to randomly turn off  Spellcheck This Field on the title input so DOUBLE FUCK IT

Unperverted Vixen

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

And it's even better. Consider this from .Net

<asp:Label runat='server' id='lblOutOfStock' Text='No Stock!' Visible='<% Eval("IsOutOfStock")' />

Nice. Easy to understand.

Asides from allowing the Eval tag inside the attribute value of another server tag. Does Web Forms really do multiple parsing passes?

@blakeyrat said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

I think part of your confusion here is mixing up Razor (if it's still called that-- the standard HTML templating engine in ASP.NET) with XAML, which is wholly unrelated AFAIK.

Razor is the newer MVC (*.cshtml) syntax, which is decidedly not what @Lorne-Kates used. I don't think there ever was a name for the older one besides "the abomination that is Web Forms" and "MVC that looks like the abomination that is Web Forms at first glance". ;)

Greybeard

I am so glad I don’t do front-end.

bb36e

@the_quiet_one said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

You are triggering every stressor I've had when I was delving into Xamarin a year or two ago. Just wait until you get into building your app for iOS, although that's more of a general mobile app problem that Apple created for people who dare develop in an OS they didn't create.

Apple values consistency above all. and so, with xcode and mac os, everyone's experience is now consistently shit

Scarlet_Manuka

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

upbreaking

That is a good and all too useful word. I shall adopt it.

Carnage

Whenever I read posts or threads about the "Everything on Everything!" frameworks for building apps, I just feel that the amount of fuckery and derps and nuclear landmines hidden behind the thin veil of shiny is far worse than just implementing the apps in native, and thus also getting full use of the advantages of each native environment and getting native look and feel.
It's not that hard to do it native. Once for web, once for iOS and once for Android.

But I'm just a backend ogre, frontendy things makes me feel all ragey and hungry.

Zecc

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Guess why Xamarin's name starts with an X.

Because it was made by Ximian?

Atazhaia

@carnage Yeah. Reading this thread makes me think that learning Swift and then do the same app twice (once in Java for Android and one more time in Swift for iOS) is the correct choice. I didn't have a good experience learning Cordova and looking at Xamarin, which is supposedly better, doesn't exactly fill me with confidence.

Although if I start poking at games I'll probably have to get into using a cross-platform engine like Unity, but as writing a game engine is a complicated matter I think the benefits outweighs the drawbacks in that case.

powerlord

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Because Xamarin has it's OWN class you need to bind to. ObservableCollection<T>

Um, isn't ObservableCollection<T> part of the standard .NET Framework?

MrL

XAML is fucking terrible. Every little thing you try to do ends in frustration, googling for answer and swearing.
It's completely undiscoverable, highly resistant to intellisense, verbose and unstable.

There's a million of small retarded idiocies sprinkled everywhere. First thing from top of my head...
visibility. Simple concept, right? Something is visible or not. True or false, yeah? Fuck no, in XAML it's Visibility.Visible, Visibility.Collapsed and Visibility.Hidden. So to bind visibility to pretty much anything, you must create a converter, a whole new class just to do

return input ? Visibility.Visible : Visibility.Collapsed;

BooleanVisibiiltyConverter, yeah. It's quickly followed by IntBoolConverter, TrueIsGreenFalseIsRedConverter, NumericToFontWeightConverter, and so on.

INotifyPropertyChanged... what a terrible idea. Simplest view models become a mile long planes of reapeated get, set, notify.

XAML's promises were: powerful and simple binding, easy and expressive syntax, fast development.
None of them are true. In fact it's exactly the opposite.

Carnage

@atazhaia said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@carnage Yeah. Reading this thread makes me think that learning Swift and then do the same app twice (once in Java for Android and one more time in Swift for iOS) is the correct choice. I didn't have a good experience learning Cordova and looking at Xamarin, which is supposedly better, doesn't exactly fill me with confidence.

I'd say Kotlin is a better choice than Java on Android. Not only is it a first class language, but it's also a nicer language, and Swift and Kotlin are seriously similar.

Atazhaia

@carnage Java for Android is something I know, which makes it easier to get going with, although I should considering looking into Kotlin too. I learnt Android development before Kotlin was a thing and haven't had time to see if it is any easier/better yet.

Carnage

@atazhaia said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@carnage Java for Android is something I know, which makes it easier to get going with, although I should considering looking into Kotlin too. I learnt Android development before Kotlin was a thing and haven't had time to see if it is any easier/better yet.

Play around with it. It's easy to learn and has s a significant advantage to java 1.6 at least.
I miss it every time I go back to Java again.

Bulb

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

And the worst thing about all this?

THIS IS THE BEST-IN-THE-MARKET FRAMEWORK TO USE THAT MEANS ANY OTHER ONES THAT MAY EXIST AR WORSTT THAN THEESSKJHLDKJFHLJ

I would dispute that. Since Microsoft is not eating this dogfood, but doing anything new as hybrid app instead, it is effectively like obsolete.

Effectively you can chose between: Cordova(+Ionic)/Electron (mobile/desktop), ReactNavtive/ReactJS and QtQuick (if you are a masochist, because that is another unwanted child that's passing from hand to hand all the time). Since you did web, I suspect you would have much easier time with the first (though it has its own idiosyncrasies; and I am sure you'll find plenty of in anything you touch).

pie_flavor

@atazhaia said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@carnage Java for Android is something I know, which makes it easier to get going with, although I should considering looking into Kotlin too. I learnt Android development before Kotlin was a thing and haven't had time to see if it is any easier/better yet.

Literally everything in Java is easier in Kotlin, but the greatest returns in that regard are when the API was designed for older versions of Java, which the Android API absolutely is.

Bulb

@atazhaia said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

I learnt Android development before Kotlin was a thing and haven't had time to see if it is any easier/better yet.

Basically what I understand is that it brings all the good from Java 8 and some more, but can compile down to Java 6 bytecode that Android only supports.

boomzilla

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Speaking of ListView; much like in .Net, you can use databinding. Basically, you give it an object that's a dataset, or some other IEnumerable, and say Bind. In your HTML, you'd use binding constructs to access the data columns, or other public properties via reflection with Eval.

<a href='<%# "http://example.com?id=" & Eval("itemno") %>'><%Eval("ItemName")%></a>

Pretty easy. Since Xamarin is leveraging the .Net framework, it'll be just as easy, right?

ahahahahahha-a-- nope.

Instead, on SOME properties of SOME controls, you would do binding like this: <Label Text='{Binding ItemName}' />

Why the different syntax? I mean, sure the project started life as it's own non-VS thing-- but it's been YEARS since it's been rolled into Visual Studio. Surely using the convention Visual Studio developers are already used to would be-- you know-- smart.

As a guess, because the new syntax is much better. Eval?!?! But then I'm used to JSF where the equivalent would be #{ItemName} which seems better than both of those.

boomzilla

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

As far as I'm concerned, it's a Xamarin issue if it fucks up when I'm trying to use the Xamarin framework.

Hi, Blakey!

Carnage

@bulb said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@atazhaia said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

I learnt Android development before Kotlin was a thing and haven't had time to see if it is any easier/better yet.

Basically what I understand is that it brings all the good from Java 8 and some more, but can compile down to Java 6 bytecode that Android only supports.

Yeah, pretty much.
The design spec for Kotlin early on was "Lets take all the best parts of every other language, mash it together and make it work coherently, on the JVM. With 100% bytecode compatability". Of all the languages I've been inflicted with, it's the one that gets the least in my way of getting shit done.

MrL

@boomzilla said in [Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery]

As a guess, because the new syntax is much better. Eval?!?! But then I'm used to JSF where the equivalent would be #{ItemName} which seems better than both of those.

Example with Eval is from old ASP.NET, with Razor it would be just @ItemName.

new syntax

It's not new. In fact {Binding ...} is the old syntax, new one is {x:Bind ...}.

Here, some description of this, yet another, XAML idiocy:

Difference between Binding and x:Bind

What to use in UWP, Binding or x:Bind and what is the difference between them? Because I see a lot of posts where people use Binding and I only Bind with x:Bind in UWP. At the MSDN Homepage it only

TheCPUWizard

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Why the different syntax? I mean, sure the project started life as it's own non-VS thing-- but it's been YEARS since it's been rolled into Visual Studio. Surely using the convention Visual Studio developers are already used to would be-- you know-- smart.

Yes, there are issues. Yes, there is a mind shift for those who have only (or largely) followed the Web paradigm..... BUT

WPF, UWP, (and even back in the day Silverlight) use the SAME semantics. Xamarin was designed to allow those people who have developed Windows Desktop (and, yeah, phone) applications to leverage the information they already know.

TheCPUWizard

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

ere's a million of small retarded idiocies sprinkled everywhere. First thing from top of my head...
visibility. Simple concept, right? Something is visible or not.

And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....

So it is Trinary, not Binary.

TheCPUWizard

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

NotifyPropertyChanged... what a terrible idea. Simplest view models become a mile long planes of reapeated get, set, notify.

a) Use Dependency Properties [enables lots of power]
b) Use a common base class and encapsulate

OR use both in combination....

coldandtired

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....
So it is Trinary, not Binary.

They removed hidden from UWP (and possibly others)

jwmsft

Visibility Enum (Windows.UI.Xaml) - Windows UWP applications

Specifies the display state of an element.

MrL

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

ere's a million of small retarded idiocies sprinkled everywhere. First thing from top of my head...
visibility. Simple concept, right? Something is visible or not.

And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....

Two different things cobbled together.

So it is Trinary, not Binary.

No.

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

NotifyPropertyChanged... what a terrible idea. Simplest view models become a mile long planes of reapeated get, set, notify.

a) Use Dependency Properties [enables lots of power]

Which is even more repeated useless boilerplate.

b) Use a common base class and encapsulate

Which changes exactly nothing.

Unperverted Vixen

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....

Two different things cobbled together.

I disagree. They’re two separate things in CSS, which is far from intuitive. Making them the same property makes it more obvious that Hidden keeps the space where Collapse/None releases it.

TheCPUWizard

@unperverted-vixen said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....

Two different things cobbled together.

I disagree. They’re two separate things in CSS, which is far from intuitive. Making them the same property makes it more obvious that Hidden keeps the space where Collapse/None releases it.

Additionally, two distinct items introduces a 4th conceptual condition, which would map to "Don't Reserve the Space", but "Do Show It"

MrL

@unperverted-vixen said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....

Two different things cobbled together.

I disagree. They’re two separate things in CSS, which is far from intuitive. Making them the same property makes it more obvious that Hidden keeps the space where Collapse/None releases it.

Ok, so I think those are two different concepts, you think it's one. And MS...

They removed hidden from UWP (and possibly others)

They think both.

TheCPUWizard

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

NotifyPropertyChanged... what a terrible idea. Simplest view models become a mile long planes of reapeated get, set, notify.

a) Use Dependency Properties [enables lots of power]

Which is even more repeated useless boilerplate.

b) Use a common base class and encapsulate

Which changes exactly nothing.

If you think Dependency Properties are "useless" then you are likely missing the full point of the paradigm [I will agree they may be over-kill for some scenarios, but if the (developer) overhead of using them is minimized enough, then consistency can be an outweighing consideration].

I tend to use lots of "generated code" so that the human developer expresses one "source of truth" about something, and all of the necessary semantic elements are consistently implemented by the machine. This took a fair amount of time to develop, but has eliminated a complete class of errors and reduced the time needed to create and maintain the codebase.

MrL

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

NotifyPropertyChanged... what a terrible idea. Simplest view models become a mile long planes of reapeated get, set, notify.

a) Use Dependency Properties [enables lots of power]

Which is even more repeated useless boilerplate.

b) Use a common base class and encapsulate

Which changes exactly nothing.

If you think Dependency Properties are "useless"

Wow, that's some serious reading comprehension fail.

anonymous234

@bulb said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

I would dispute that. Since Microsoft is not eating this dogfood, but doing anything new as hybrid app instead, it is effectively like obsolete.

Yeah, I don't think Microsoft cares much about it anymore. It can't help Windows Phone anymore so why would they?

Lorne Kates

@blakeyrat said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@lorne-kates I think part of your confusion here is mixing up Razor (if it's still called that-- the standard HTML templating engine in ASP.NET) with XAML, which is wholly unrelated AFAIK.

It isn't so much confusion between the two, but more of a "huh, given how close the syntaxes are, and given how much Microsoft has put into obtaining this platform, and given how much Microsoft loves changing shit, and given how ABSOLUTELY FUCKING USEFUL RAZOR IS, I would have thought they'd have merged them together somehow".

Lorne Kates

@unperverted-vixen said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Asides from allowing the Eval tag inside the attribute value of another server tag. Does Web Forms really do multiple parsing passes?

I don't know if it's doing multiple parsing passes-- but yes, it does allow Eval inside another server tag. You can do most anything inside <%# %>. You could even do `<%# CType(Container.DataItem, YourCustomObject).SomeProperty.SomeSubProperty %>

Lorne Kates

@greybeard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

I am so glad I don’t do front-end.

Only backdoor stuff you, huh?

Lorne Kates

@zecc said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Guess why Xamarin's name starts with an X.

Because it was made by Ximian?

YOU'RE GUESSING WRONG! BANNED!

Lorne Kates

@powerlord said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:

Because Xamarin has it's OWN class you need to bind to. ObservableCollection<T>

Um, isn't ObservableCollection<T> part of the standard .NET Framework?

Maybe? I've literally never encountered it before now.