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

pie_flavor

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

All of this may be technically correct, but utterly irrelevant to the discussion at hand. These values are nullable at the conceptual level the language presents, how this is implemented is of no consequence to the discussion.

Right on the money. When I type yield return, the compiler does some absolute craziness to make it work. And I never have to see it. It just works.

pie_flavor

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

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

There's nothing factually confusing about any of them, and more importantly none of them refer to the same process. Did you know in C# you have reference types and value types, and you can also pass any type by reference or even as an out reference, and that these value types can also be made to be nullable even though reference types are always nullable, except value types passed by reference can't be null, unless they're nullable, and that value types can't extend anything except for when they extend ValueType but they can also implement interfaces and variables of interface types can be null?

If you're confused about reference and value types, you shouldn't be a programmer.

If you're confused about multi platform compilation, you shouldn't be a programmer.

pie_flavor

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

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

I think you deliberately click on shit that you know isn't relevant just so you can act like it's more popular than it is.

So I bring up things that aren't relevant so I can act like it is relevant?

:/

Yes, pretty much. There is no fucking way you googled Kotlin and got Anko before the Kotlin website, the Kotlin GitHub, the Kotlin Wikipedia page, and a couple articles about Kotlin.

blakeyrat

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

If you're confused about multi platform compilation, you shouldn't be a programmer.

If you're confused about what 14 point font size is, you shouldn't be writing programming tools. (Talking to you, Visual Studio Code.)

pie_flavor

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

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

If you're confused about multi platform compilation, you shouldn't be a programmer.

If you're confused about what 14 point font size is, you shouldn't be writing programming tools. (Talking to you, Visual Studio Code.)

Absolutely. JetBrains IDEs never fuck anything like that up.

The_Bytemaster

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

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

You seem to be conflating ".Net" with "ASP.Net". This is not correct.

It's close enough. If Microsoft is going to confusingly name all their technologies like that, then fuck them when I mix them up.

You should enjoy that Windows Server is not called Windows .Net Server as it was going to be at one point. Pretty much anything with ".Net" in the name is the ".Net" version of it. ASP.Net was preceded by ASP. ADO.Net was preceded by ADO.

Enjoy your ASP.Net Core 2.0 which is newer than .Net 3.5 which actually uses CLR 2.0 which .Net 2.0 used, unless you're replacing it with .Net 4.0 which uses CLR 4.0 because there's no CLR 3.0 or 3.5. If you update to .Net 4.5 or higher you'll still be using CLR 4. I don't know why you would confuse .Net and ASP.Net, given that their version numbers increment in the exact same way, and are released nearly in lock-step with each other. And you absolutely don't want to mix it with ASP.Net Core, which sounds like it's ASP.Net without extensions, but is actually a new version of ASP.Net and has nothing to do with ASP.Net (non-Core), even though ASP.Net Core follows the exact same version numbering of 1.0, 1.1 then 2.0.

Yeah, at one point marketing got involved in the version numbering of .Net and that caused all sorts of problems. The WTF of the .Net versioning. Here is the easy primer:

1.0, 1.1 - early versions, don't use
2.0 - major upgrade, introduces generics
3.0 - ".Net FX" originally, Just added features to 2.0, but marketing thought it was too big of release to just call it a point release, so they called it 3.0. It backfired. Not only did it make it more confusing, administrators, after dealing with 1.1 to 2.0 headaches, often refused to let people use the functionality for several years, even though it uses CLR 2. (this release includes WPF, WCF, an earlier version of workflow, and the deprecated CardSpace)
3.5 - This actually did modify the 2.0 runtime (2.0 SP1). Introduced LINQ. Modern times you typically install the latest release of 3.5 and it is often referred to as 2.0/3.0/3.5 since they all share the same runtime core.
4.x - these are the modern releases of the .Net framework. Each one supersedes the other, but if your metadata is right should be backwards compatible with the earlier versions of 4, including emulating bugs in some cases.
.Net Core - This is the full Open Source version of the .Net framework. It was originally going to be called "5.0", but this led to a different confusion because it was not fully compatible with 4.x and, in many cases, removed functionality. .Net Core is cross-platform as well, and is the future, but there is some confusion in the mean time. There is now a compatibility pack to make it much more compatible with code written for 4.0 if you need it.
.Net Standard - this is the new "standard" API template to be used by the various runtimes (.Net Framework, .Net Core, Mono including Xamarin). Targeting this gives you the most cross-runtime compatible code, but may leave out some features. This is an attempt to mend the sins of the past.

And don't forget when you're setting up your ASP.Net 3.5 project that uses .Net Framework to go into IIS and set the App Pool to target .Net Framework v4.0.30319, because v4.0.30319 is actually .Net Framework 3.5 and higher (all the way up to 4.7.1, which is only for Windows 10, unless you install the extension for Windows 7).

That is actually incorrect. Your 3.5 project should be set to use a 2.0 app pool, for full compatibility. If it works under the 4.0 app pool, that is good. 4.0 is almost completely backwards compatible with 2.0/3.0/3.5.

TheCPUWizard

@the_bytemaster 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:

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

You seem to be conflating ".Net" with "ASP.Net". This is not correct.

It's close enough. If Microsoft is going to confusingly name all their technologies like that, then fuck them when I mix them up.

You should enjoy that Windows Server is not called Windows .Net Server as it was going to be at one point. Pretty much anything with ".Net" in the name is the ".Net" version of it. ASP.Net was preceded by ASP. ADO.Net was preceded by ADO.

Enjoy your ASP.Net Core 2.0 which is newer than .Net 3.5 which actually uses CLR 2.0 which .Net 2.0 used, unless you're replacing it with .Net 4.0 which uses CLR 4.0 because there's no CLR 3.0 or 3.5. If you update to .Net 4.5 or higher you'll still be using CLR 4. I don't know why you would confuse .Net and ASP.Net, given that their version numbers increment in the exact same way, and are released nearly in lock-step with each other. And you absolutely don't want to mix it with ASP.Net Core, which sounds like it's ASP.Net without extensions, but is actually a new version of ASP.Net and has nothing to do with ASP.Net (non-Core), even though ASP.Net Core follows the exact same version numbering of 1.0, 1.1 then 2.0.

Yeah, at one point marketing got involved in the version numbering of .Net and that caused all sorts of problems. The WTF of the .Net versioning. Here is the easy primer:

1.0, 1.1 - early versions, don't use

2.0 - major upgrade, introduces generics

3.0 - ".Net FX" originally, Just added features to 2.0, but marketing thought it was too big of release to just call it a point release, so they called it 3.0. It backfired. Not only did it make it more confusing, administrators, after dealing with 1.1 to 2.0 headaches, often refused to let people use the functionality for several years, even though it uses CLR 2. (this release includes WPF, WCF, an earlier version of workflow, and the deprecated CardSpace)

3.5 - This actually did modify the 2.0 runtime (2.0 SP1). Introduced LINQ. Modern times you typically install the latest release of 3.5 and it is often referred to as 2.0/3.0/3.5 since they all share the same runtime core.

4.x - these are the modern releases of the .Net framework. Each one supersedes the other, but if your metadata is right should be backwards compatible with the earlier versions of 4, including emulating bugs in some cases.

.Net Core - This is the full Open Source version of the .Net framework. It was originally going to be called "5.0", but this led to a different confusion because it was not fully compatible with 4.x and, in many cases, removed functionality. .Net Core is cross-platform as well, and is the future, but there is some confusion in the mean time. There is now a compatibility pack to make it much more compatible with code written for 4.0 if you need it.

.Net Standard - this is the new "standard" API template to be used by the various runtimes (.Net Framework, .Net Core, Mono including Xamarin). Targeting this gives you the most cross-runtime compatible code, but may leave out some features. This is an attempt to mend the sins of the past.

And don't forget when you're setting up your ASP.Net 3.5 project that uses .Net Framework to go into IIS and set the App Pool to target .Net Framework v4.0.30319, because v4.0.30319 is actually .Net Framework 3.5 and higher (all the way up to 4.7.1, which is only for Windows 10, unless you install the extension for Windows 7).

That is actually incorrect. Your 3.5 project should be set to use a 2.0 app pool, for full compatibility. If it works under the 4.0 app pool, that is good. 4.0 is almost completely backwards compatible with 2.0/3.0/3.5.

Great Summary. The only thing I would add, is that .Net Standard is a public standard where anyone (with sufficient resources) can make their own implementation. Since Core is OpenSource, you can start there, or anywhere else you like.

The_Bytemaster

Dood. Microsoft made XAML for Silverlight, then later used it as the basis for Window Store Apps or whatever we're calling those this week when Windows 8 came out.

Actually, Microsoft made XAML for WPF. They then worked on a project that would let you take your WPF everywhere. They called it WPF/e, and then renamed it to Silverlight on release. A version of Silverlight was used for Windows Phone, but it was designed for in-browser first.

Carnage

@lorne-kates 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:

Kotlin v1.0 was released on February 15, 2016

And the latest breaking change was introduced, according to https://github.com/Kotlin/anko/releases, in Nov 22, 2017.

Mature.

As has been said, anko is a library for android development to skip having to fiddle with the fugly xml horribleness that is the UI bits.
I tried it way back in 2016, and wasn't entirely impressed with how the UI code turned out so unless something major has changed in it since then, my general recommendation is to stay away from it.
The only connection to kotlin is that it's a showcase for how easy it is to implement DSLs in kotlin, although it admittedly wasn't very good at solving the problem it wants to solve when I tried it.

dkf

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

It was originally going to be called "5.0", but this led to a different confusion because it was not fully compatible with 4.x and, in many cases, removed functionality.

If they'd been following semantic versioning (as opposed to “marketing versioning” ) that would have been mostly OK. Functionality removed? It's a new major version; what did you expect, squire?

MrL

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

There is a lot of bad XAML docs out there. Yes, the visibility converters can be "fun", but typically you need one for a bool and that is about it.

The question is: why do you need a converter for that at all? In UWP there are only two states, why tf do I need to write a whole class for that? And of course, visibility is only an example, more converters pop up as you develop the UI. Why there are no standard converters built in? Why can't I inline simple conversions in XAML?

As for INotifyPropertyChanged, you typically have a helper function for that which allows very simple view models. If you keep repeating boilerplate code, you are doing it wrong.

Oh yes, you have the magnificent helper method that raises notification event. Such wow. Thanks to it, this property declaration:

public MyThing { get; set; }

still looks like this:

private myThing;
public MyThing
{
    get { return myThing; }
    set
    {
        if(myThing != value)
        {
            myThing = value;
            Notify();
        }
    }
}

For. Every. Fucking. Property.

I see developers get frustrated, and there are a couple of pain points, but it really is a very fast way to build up an app. I personally have found all of those promises to be true

I have no idea what you have to compare XAML to, to say that it's fast to develop.

Spencer

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

The question is: why do you need a converter for that at all? In UWP there are only two states, why tf do I need to write a whole class for that?

Because it's based on WPF, which has three values for visibility, and presumably with XAML Standard UWP will have the 3 visibility states again as WPF, UWP and Xamarin.Forms (plus others) will all be using the same XAML components.

As for INotifyPropertyChanged, you typically have a helper function for that which allows very simple view models. If you keep repeating boilerplate code, you are doing it wrong.

Oh yes, you have the magnificent helper method that raises notification event. Such wow. Thanks to it, this property declaration:
public MyThing { get; set; }
still looks like this:
private myThing;
public MyThing
{
    get { return myThing; }
    set
    {
        if(myThing != value)
        {
            myThing = value;
            Notify();
        }
    }
}
For. Every. Fucking. Property.

Every single class I write that needs to implement INotifyPropertyChanged implements a Observable base class (usually included with MVVM frameworks) that turns it into

private myThing;
public MyThing
{
    get { return myThing; }
    set { Set(ref myThing, value); }
}

And I'd much rather that tiny bit of boilerplate, plus all the benefits of binding and MVVM than the crapton of work that's typically required by doing it in the codebehind instead.

MrL

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

Because it's based on WPF, which has three values for visibility, and presumably with XAML Standard UWP will have the 3 visibility states again as WPF, UWP and Xamarin.Forms (plus others) will all be using the same XAML components.

Please familiarise yourself with a concept of rhetorical question.

As for INotifyPropertyChanged, you typically have a helper function for that which allows very simple view models. If you keep repeating boilerplate code, you are doing it wrong.

Oh yes, you have the magnificent helper method that raises notification event. Such wow. Thanks to it, this property declaration:
public MyThing { get; set; }
still looks like this:
private myThing;
public MyThing
{
    get { return myThing; }
    set
    {
        if(myThing != value)
        {
            myThing = value;
            Notify();
        }
    }
}
For. Every. Fucking. Property.
Every single class I write that needs to implement INotifyPropertyChanged implements a Observable base class (usually included with MVVM frameworks) that turns it into
private myThing;
public MyThing
{
    get { return myThing; }
    set { Set(ref myThing); }
}
And I'd much rather that tiny bit of boilerplate, plus all the benefits of binding and MVVM than the crapton of work that's typically required by doing it in the codebehind instead.

You are doing the same crapton of work, with a lot of repeated code, plus you type kilometers of xml. But it's placed in front xml and 'view model', so it's not 'codebehind'. And you don't do 'events', but 'commands', so it's automatically great.

Rhywden

@mrl Some verbosity is to be expected. I've worked with Frameworks which also abstract that bit away again.

And promptly cause a boatload of issues if something is not to the framework's liking.

TheCPUWizard

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

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

Because it's based on WPF, which has three values for visibility, and presumably with XAML Standard UWP will have the 3 visibility states again as WPF, UWP and Xamarin.Forms (plus others) will all be using the same XAML components.

Please familiarise yourself with a concept of rhetorical question.
As for INotifyPropertyChanged, you typically have a helper function for that which allows very simple view models. If you keep repeating boilerplate code, you are doing it wrong.

Oh yes, you have the magnificent helper method that raises notification event. Such wow. Thanks to it, this property declaration:
public MyThing { get; set; }
still looks like this:
private myThing;
public MyThing
{
    get { return myThing; }
    set
    {
        if(myThing != value)
        {
            myThing = value;
            Notify();
        }
    }
}
For. Every. Fucking. Property.
Every single class I write that needs to implement INotifyPropertyChanged implements a Observable base class (usually included with MVVM frameworks) that turns it into
private myThing;
public MyThing
{
    get { return myThing; }
    set { Set(ref myThing); }
}
And I'd much rather that tiny bit of boilerplate, plus all the benefits of binding and MVVM than the crapton of work that's typically required by doing it in the codebehind instead.
You are doing the same crapton of work, with a lot of repeated code, plus you type kilometers of xml. But it's placed in front xml and 'view model', so it's not 'codebehind'. And you don't do 'events', but 'commands', so it's automatically great.

Yes, there are many ways. An alternate (which has pro's and con's so I use it situationally)

        public static SmartProperty<int> MyThing { get; } = new SmartProperty<int>();

Magus

@spencer That usually makes things worse, honestly. There's a project out there somewhere that adds attribute-style macros that will expand [Notify] public <type> <name> { get; set; } to the full implementation, but I haven't used it.

EDIT: Looks like I was thinking of PostSharp, but apparently Fody is also a thing that exists?

EDIT2: I would have to be 100% sure I was going to be using it for the forseeable future with a price like this, but you have to admit what it does is cool: https://www.postsharp.net/xaml I wish Microsoft would just build that stuff in. I bet you could do cool compiler extensions for it now...

Magus

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

But it's placed in front xml and 'view model',

Putting stuff in the viewmodel essentially just means you're working directly with the datacontext the view is designed to look at. It just ends up being easier, honestly.

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

And you don't do 'events', but 'commands', so it's automatically great.

Events have their place. But purely for user input handling, and feeding that back into the datacontext? Commands are really good at that.

WPF is easier to work with and reason about if you assign a datacontext. That's really all it is. You can set your datacontext to be your view, and that can sometimes help, but usually there's no need, and that has it's own problems.

dcon

@lorne-kates 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:

WinForms

You're a goober. Stop being a dinosaur GRANDPA!

That's not a dinosaur. I'm a dinosaur with Win32/C++/WTL.

TheCPUWizard

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

@spencer That usually makes things worse, honestly. There's a project out there somewhere that adds attribute-style macros that will expand [Notify] public <type> <name> { get; set; } to the full implementation, but I haven't used it.

EDIT: Looks like I was thinking of PostSharp, but apparently Fody is also a thing that exists?

EDIT2: I would have to be 100% sure I was going to be using it for the forseeable future with a price like this, but you have to admit what it does is cool: https://www.postsharp.net/xaml I wish Microsoft would just build that stuff in. I bet you could do cool compiler extensions for it now...

Yes, they can be cool. Microsoft has laid the groundwork with the switch to Roslyn. Given that all code is a red/green tree pair, and this pair can be manipulated, the possibilities are extensive (and many of them are coming from Microsoft - have you looked in the Gallery lately???)

CodeJunkie

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

@tsaukpaetra said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
... Classic ASP (also not a real term) which is actually VBScript.

Actually no, Active Server Pages could be written using VBScript or JScript (Microsoft's JavaScript implementation).

Magus

@thecpuwizard I've thought about trying to implement a compiler extension like that myself, but have no idea how currently :/

Spencer

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

You are doing the same crapton of work, with a lot of repeated code, plus you type kilometers of xml. But it's placed in front xml and 'view model', so it's not 'codebehind'. And you don't do 'events', but 'commands', so it's automatically great.

Well no, I'm not. Binding takes care of that, all I have to do is assign values to properties in my ViewModel. XAML also means I have to do less work to adjust to window size changes, because that's automatically handled by the built-in layout engine and the container controls you've placed the other controls in.

There's no need to type kilometres of xml; it can all be done using Blend. Better yet, you can hand that off to an actual designer who just builds to the view models you've built with design-time data while you focus on the rest of the actual application logic.

I could go on about the virtues of MVVM in WPF/UWP, but it's also possible to use MVVM with WinForms, but again that requires more work - the bindings have to be set up manually in the codebehind, not to mention handling control's changed events (eg SelectionChanged) for things like ComboBox and ListBox.

MrL

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

Well no, I'm not. Binding takes care of that, all I have to do is assign values to properties in my ViewModel.

Which consists of tons of repeated code, plus converters and commands*.

XAML also means I have to do less work to adjust to window size changes

Except when you have to do a lot more work. See one of my previous posts.

There's no need to type kilometres of xml; it can all be done using Blend.

Sure it can, except every tutorial I read admits that it's better to write it by hand.

Better yet, you can hand that off to an actual designer who just builds to the view models you've built with design-time data while you focus on the rest of the actual application logic.

Just like with any other technology.

I could go on about the virtues of MVVM in WPF/UWP

Please don't.

* Actually for me this was the most surprising thing when I first encountered XAML. I read many times that it makes binding a breeze, so I was really curious. Then I started to piece together some Hello World and my first reaction was "I have to write so much convoluted crap to bind a label???".

Spencer

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

my first reaction was "I have to write so much convoluted crap to bind a label???".

what convoluted crap are you doing that this doesn't work?
<Label Caption="{Binding TextToDisplay}" />
Or are you talking about building the MVVM framework by hand?

I'll admit the Command boilerplate is a bit more than I'd like, but I don't think this is really too much

private RelayCommand _myCommand;
public RelayCommand MyCommand => _myCommand ?? (_myCommand = new RelayCommand(MyAction));
private void MyAction()
{
    // ...
}

That Command boilerplate is the extent of any repeated code I ever write while using XAML. I like the Value Converters because they're independently testable, and very reusable across products. Instead of repeated code defining those converters again and again in each window/control/frame/page's resource dictionary, they instead go into either the app.xaml resource dictionary or a shared one. Same with data templates, styles etc. XAML in WPF and UWP lends itself very well to reuse.

powerlord

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

@carnage I learned streams and lambdas the instant they came out, and I was 14 then. Your coworkers are ridiculous.

Wait, so you're only 17 right now? 'cause Java didn't have streams or lambdas until 3 years, 11 months, and 27 days ago.

pie_flavor

@powerlord You expect me to pay attention to things like that? :P

Magus

@mrl Started writing some compile-time codegen stuff with some Compiler Platform tools, and I'm fairly confident that I could kill off all that boilerplate in a week or two.

EDIT: Property changed itself is probably just a day's work.

They should build it all in...

Zmaster

So, I’ve updated to the latest Xamarin release.
Here’s what happened with VSmac:

it always remembers the files that I had open before updating. No matter what I do, every time I open the project those are the files that I get.
highlighting is a bit broken, it flickers every time you type a character
it gets unusable after coding for a while, freezes for a few seconds before finishing “accepting” what I type
the Android project didn’t build anymore. To fix it I had to clean the build files. And BTW doing a Clean o Rebuild is not good enough. It should, but no, you need to manually delete the obj and bin directories.

But hey, they’ve changed the icon for starred projects. Now the star is bigger.

I actually quite like VSmac (MonoDevelop, XS, whatever you want to call it) but Microsoft seems to break everything lately.

MrL

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

@mrl Started writing some compile-time codegen stuff with some Compiler Platform tools, and I'm fairly confident that I could kill off all that boilerplate in a week or two.

I thought about doing that, but I got angry every time I starter researching it, because..

They should build it all in...

Yeah, that's why.

Anyway, I'd love to see what you come up with.

Spencer

btw, since @Lorne-Kates is an ASP.NET dev, has anyone suggested doing whatever app this is all for as a PWA?

Bulb

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

btw, since @Lorne-Kates is an ASP.NET dev, has anyone suggested doing whatever app this is all for as a PWA?

Yes, of course I did

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

Effectively you can chose between: Cordova(+Ionic)/Electron (mobile/desktop), […] Since you did web, I suspect you would have much easier time with the first […]

Also

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

Microsoft is not eating this dogfood, but doing anything new as hybrid app instead

Spencer

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

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

btw, since @Lorne-Kates is an ASP.NET dev, has anyone suggested doing whatever app this is all for as a PWA?

Yes, of course I did

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

Effectively you can chose between: Cordova(+Ionic)/Electron (mobile/desktop), […] Since you did web, I suspect you would have much easier time with the first […]

That sounds like a web app. Not a PWA (distinct difference). PWA can be (and in a lot of cases, will be) an actual responsive web site, written in whatever you fancy, with javascript service workers for any background tasks, and converting/packaging it as a PWA. Even though they're web sites, a PWA is completely able to be run offline.

Google and Microsoft are actually working together on making sure this is supported on Android and Windows in their stores, and Apple may be coming to the table too.

Progressive Web Apps: Going Offline | Google for Developers

Progressive Web Apps made easy with ASP.NET Core

Zecc

@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.
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).

WinJS!

Magus

@mrl It's essentially just going to be some rewriting before compliation, so prepending [Notify] to a class implements the interface and expands all the properties. I'm considering doing the same with dependency properties, but I'm not sure that's as good an idea. Normal properties just work, and the notify property changed implementation really doesn't affect them, as far as the developer is concerned, but dependency properties do weird xaml registration things, so intellisense wouldn't like whatever I do.

Lorne Kates

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

actually

Thank you for you input, person who hasn't logged on for three years, but suddenly felt the need to rush in to whiteknight fucking XAML. I assume you have the term on your Google Alerts, and show up unwanted into any new discussion about it. You are a human being of great use to society at large.

Lorne Kates

And since googling for "The Bytemaster" Xamarin leads me to a Github with a couple crappy plugins for XAML and Xamarin, I'm going to assume you're whatever the equivalent of a discodev is for Xamarin. I don't know what the name is, but it's probably stupid, and once you tell use we can properly mock it.

pie_flavor

@lorne-kates Dude, what the fuck is your problem?

Lorne Kates

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

@lorne-kates Dude, what the fuck is your problem?

Right now? I'm out of cake.

Though, tobe faire, it's because I just ate cake.

Tsaukpaetra

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

Well no, I'm not. Binding takes care of that, all I have to do is assign values to properties in my ViewModel.

Except in my personal case, where I practically have to handheld notify property changed with dispatcher hell because it's sooo easy and quick.

Tsaukpaetra

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

They should build it all in...

But they won't for the same reasons Epic Games won't allow doubles and int64s into their blueprint system, despite it taking hardly a week of my inexperienced time to do so.

Magus

@tsaukpaetra I'm fairly certain that's because you've got other issues going on.

Magus

@tsaukpaetra It seems to be a matter of, the only way to really solve something like this is metaprogramming, since adding even more reflection to XAML would be awful. And that requires a lot of work by the team that builds the VS tooling around debugging and stuff, and lots of UX meetings.

The_Bytemaster

@lorne-kates I login in when I actually have something to contribute. My workstation typically logs me out.

The "Plugin" in question was a patch I was working on for an existing plugin that worked with Xamarin and MVVMCross. It was broken for UWP and I was building out support for it. There are a lot of plugins like that that allow access to things like SMS, Camera, etc. that are implemented differently on each platform, but you utilize them the same in your code. It compiles with the native version for the platform and works without having to write the code to do it on each platform. Many are very simple plugins. In this case, I actually needed the fixed code for the project I was working on.

The_Bytemaster

Incidentally, it looks like Xamarin has been reading this thread. New features in Xamarin Forms 3:

Style using CSS - it converts it to the native styling at compile time.
Real time change and debug - on all targets and emulators including iOS, Android, and UWP
New compilation target previews: WPF, MacOS, Tizen, GTK+

stillwater

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

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).

I read this 4 months back and thought "Well, surely it could not be that bad. Most documentation is fucked up and always require some googling."

I decided to install the Xamarin workload on VS 2017 and give it a shot. Might as well know how to make apps. Took quite some time to download it over a painfully slow network. All set after an hour or so and good to go. Open up the docs and

The steps in the documentation to create the basic fucking project are WRONG. Code breaks all over the place. This was already covered in the OP's post. What bothered me even more was not how the code broke, but the instructions gave no details on why we're doing each step. It was basically "click this, open that dialog, add a class, copy paste below code" for like 5 consecutive steps. On TOP of broken code that is.

This is by far the worst documentation I've ever seen and this is the basic getting started tutorial. Somebody in the team gives zero fucks about getting people interested in Xamarin. Comparing the Xamarin docs with the ASP .NET Core docs and the difference is night and day.

Even if Xamarin was the best cross platform framework for mobile apps, I doubt anyone would use it cos the documentation that is supposed to get people hands-on the very first time is broken AF. I am mindblown by how shitty the documentation is.

stillwater

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

Incidentally, it looks like Xamarin has been reading this thread. New features in Xamarin Forms 3:

Style using CSS - it converts it to the native styling at compile time.

Real time change and debug - on all targets and emulators including iOS, Android, and UWP

New compilation target previews: WPF, MacOS, Tizen, GTK+

These new features don't account for shit if the getting started tutorial is beyond fucked up.

Lorne Kates

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

@lorne-kates I login in when I actually have something to contribute. My workstation typically logs me out.

https://i.imgur.com/gO5FVBy.png

Lorne Kates

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

Well, surely it could not be that bad

Mmm-hmm?

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

The steps in the documentation to create the basic fucking project are WRONG

Yup.

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

Somebody in the team gives zero fucks about getting people interested in Xamarin

And that's AFTER posting on their official forums and notifying them on Twitter (and getting responses of 'thanks we'll look into that').

Even if they had fixed the documentation when I pointed out it was broken, they'd probably have REBROKEN it again. Because Xamarin loves to change everything with every release. Method signatures. .Net frameworks. Project templates. Everything.

stillwater

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

And that's AFTER posting on their official forums and notifying them on Twitter (and getting responses of 'thanks we'll look into that').

I was too pissed to even go that far. And obviously they did not do shit because I tried it yesterday painstakingly doing the exact steps and fuckton of build errors and missing assemblies.

Also, I've noticed whenever I've reported issues with documentation, I always get a response to some issue tangential to it and not the actual goddamn issue.

Eg: "Hey guys, the tutorial says Do A then B but it does not work until you do step X before B. Maybe you should add it.

Response: "Hey thanks, the tutorial uses B at the moment without X."

That's exactly why the thing did not work in the first place motherfucker what kind of response is that.

This is frustrating because I know XAML, I know C#, and I could reuse those skills easily but fuck no, let us make a product to exactly do that but fuck up the documentation right in the first tutorial.

stillwater

Fuck this shit. I'm going with Android studio + Java. Probably phase out Java and learn Kotlin at some point. Xamarin won't do. Piece of shit.

EDIT: Just noticed https://forums.xamarin.com/discussion/89286/xamarin-sucks-lessons-learned-from-weeks-wasted. Time wasted and precious data wasted on my daily data cap. Might have downloaded some solid HD pornography instead of this POS. Atleast would have been useful one time.