Using declarative style C# instead of XAML - should Xamarin redirect XAML efforts elsewhere?

2»

Posts

  • IceJovanoskiIceJovanoski MKMember ✭✭

    I did c# UI on my first Xamarin project, and ended up rewriting it in XAML, but I'd gladly give it another try now after 2 years of Xamarin development. I'd also like to note that I have no previous experience with XAML or anything desktop related coming from web development.

    I like your helpers and the approach, also the focus of Xamarin team that you point out. Do you think we can further expand this and maybe turn it into an OSS project?

    I'll also make some pages to get a better overview of the helpers and compare full pages XAML vs C# and will be back with results :)

  • MikeEEEMikeEEE USMember ✭✭✭

    Really good discussion here. Thank you for facilitating this, @VincentH. My take on this is that the primary point of enabling a format is cost savings. Whereas you had issues with the Blend->WPF workflow, I have had magic with it many times. The workflow between designer and developer is critical. A serialized format enables this at a much granular (and CHEAPER) degree than compiled code (or coded/scripted language).

    Additionally, a (compiled/scripted) language-agnostic serialized data format leads to a lower total cost of ownership for an application than one that is strictly code-based. If I have to hire a resource that simply has to maintain a data file for a project vs. having to get someone to manage code to make pixels move or otherwise configure the behavior of an application, that usually involves a lower rate per hour and therefore improved bottom line on the budget. This is even magnified when that data file can be easily edited by way of a visual designer. Now my maintenance requirement has moved from someone who understands a (language-agnostic) data format to someone who knows how to press buttons and make pretty pictures with an editor (that is based on a serialized and standardized data format). This is ultimately cheaper for me and the clients for which I have to acquire the resources to do this. If it's all compiled/scripted code, well, that is MUCH more expensive and therefore a higher barrier to pursue and keep to budget.

    The primary problem this space faces is tooling and innovation around such. WPF was very close to touching an ideal but certainly could have been improved (as you can attest @VincentH). But, not bad for a first shot at it, IMO. :) The problem of course is that a 2nd shot was never attempted and we are still suffering for answers to this day.

    BTW, I did read flutter's philosophy here and I am not in agreement whatsoever. I also am/was not impressed that Flutter does not even work on the web, nor plans to. Some innovation. :P

  • CharlesRoddieCharlesRoddie USMember ✭✭

    Really nice to avoid XAML with its primitve to non-existent type system. And to avoid bindings with all the boilerplate and value converter hacks.

    In F# my UI code looks like:

    let qL = Label( FontSize=22., Style = LabelStyle.StandardLayout, TextColor = Color.Red)
    do  vm.QLabel |> bind (fun s -> qL.Text <- s)
    
    Grid( BackgroundColor = Color.White, ColumnSpacing = 1.,
          ColumnWidths = [GridLength 200.; GridLength.Star; GridLength 50.],
          Row0 = [scoreL; qL; prevB]  )
    
  • MikeEEEMikeEEE USMember ✭✭✭
    edited May 2018

    @CharlesRoddie I am with you on the converter hacks, but Xaml (WPF's at least) has a great type system. Or I should say better than average, these days. Have you ever tried using using XmlSerializer or even DataContractSerializer? Additionally, the boilerplate dilemma is always a problem with MSFT products as the code they place in projects/project items are notoriously filled with poor practice and unnecessary code.

    Also, I am a fan of F# but first show me a designer (both visual design tool and human) that can work with the code you have presented and THEN I will be impressed. ;) The goal here is to leverage the talent and expert system provided by a UI/UX resource, via a medium that is easily accessible by them with the least amount of friction possible incurred. What you are proposing involves this resource to learn an proprietary language in order to provide any sort of meaningful value towards a production. Not the most viable (or profitable, I should say) of options/strategies. Knock yourself out if it works for you, though. :)

  • CharlesRoddieCharlesRoddie USMember ✭✭

    That is fair. But in order for Xaml to work well, the type system can't just be better than average. It has to be as good as the .Net type system. This is because properties of View objects may be of any type.

    An intermediate approach of defining a limited set of UI objects and supplementing with code (for bindings or more advanced types) would work OK and Xaml can do that. (Can use type providers in this way.)

    As is it works OK if you don't mind verbosity, magic strings, and a pseudo-reactive binding approach that ties not only the view but also the viewmodel to a specific UI framework.

  • GVxGVx USMember ✭✭✭

    @fabior said:

    But I cannot agree debates on such fundamental things like XAML since Xamarin still struggles with making Xamarin Forms stable (see ListView control as just an example).

    this!

  • GVxGVx USMember ✭✭✭

    @fabior said:
    Xamarin Forms remains a half baked framework, still buggy, and now Xamarin hopes open source community will do what they didn't for years. Sad.

    haha.. this is so true... It's as if they had a board meeting and said, 'hey we get the entire world to QA our software at no cost, why don't we take it to the next level and get them to also develop our software too' ...

    Smart move Xamarin, smart move! :neutral:

  • VincentHVincentH USBeta ✭✭

    @AndrewMobile said:
    Code always has so many ways of looking more personal, from naming variables to structuring. XAML can have some of that too, but to much less extent. When you open a XAML, you know exactly to expect, for the most part.

    I recognize from several reactions that some limitations of XAML can be used to an advantage (as a famous soccer genius once said, "every disadvantage has it's advantage"), if you need to ensure that developers stick to standard syntax, conventions and good separation.

    While limiting others can keep them from mischief, it also reduces their productivity, and makes them less happy about their jobs.

    Consider that you may achieve more with existing code quality control measures that do not limit productivity. E.g. if you put the helpers in a NuGet, effectively defining the markup DSL for your team(s), you can easily ensure standardization of your declarative C# files content in a build step or an analyzer, failing or warning when people check in code that violates your standards.

  • VincentHVincentH USBeta ✭✭

    @MikeEEE said:
    If I have to hire a resource that simply has to maintain a data file for a project vs. having to get someone to manage code to make pixels move or otherwise configure the behavior of an application, that usually involves a lower rate per hour and therefore improved bottom line on the budget.

    I see your point, however this is more about semantics when hiring people. If you would hire a "Xamarin Forms markup maintainer", and that person knows only XAML, they do not need to become a full fledged C# developer to become productive in declarative C# markup. Their real skills and learning curve are knowing the Xamarin Forms layouts and controls and how to use them. Learning a slightly different syntax should only require a few hours of practice and inspecting existing markup, because the C# reads almost identical to the XAML and the intellisense in C# is much better.

    Consider below images from https://github.com/VincentH-Net/CSharpForMarkup. Does that look like it requires an higher hourly rate?

    Also consider that the main point is that declarative C# is more productive than XAML. Given the same hourly rate, that would mean that declarative C# is less expensive than using XAML.

    Even more so when maintaining markup, because of the better refactoring support in Visual Studio. E.g. when a viewmodel property is renamed in code, all the bindings are renamed automatically in all markup files. When you compile, all bindings are checked, no more binding errors that are only discovered when running the app. Code Lens tells you where (and whether) viewmodel properties and commands are used, allowing you to quickly assess the impact of changes and to remove unused code.

    Here are some side by side comparisons:
    Entry markup:
    Entry in XAML XAML
    Entry in C# C#

    Registration code page in XAML:

    Registration code page in C#:

    For more examples, see https://github.com/VincentH-Net/CSharpForMarkup

  • MikeEEEMikeEEE USMember ✭✭✭

    @VincentH I appreciate the engagement in dialogue here. To start, all of the features you are describing are indeed part of the Visual Studio development process which is indeed quite expensive. All the screenshots you demonstrate here are in C#, so this (again like with F#) would require a resource to attain the knowledge of how to operate in such a system and corresponding language. Having spent what is approaching nearly 20 years in the subject myself I can assure you it will take them more than a few hours to onboard an become proficient at this. :)

    Consider that all of the features towards stabilizing the development experience are tooling-related, all of which can be also applied to a visual designer/tool as well.

    Along such lines, consider that visually inclined individuals (in my experience) want nothing to do with the code editor and prefer visual designers/tooling, and that is what I am personally angling for in my discussion here. A visual designer or additional tooling like Blend would be able to work with the formatted language like Xaml (or XML or JSON or YAML) and provide a more congruent, productive experience like what you are suggesting.

    Also consider that with a formatted data language you have the opportunity to provide additional semantics with expressions (such as bindings, or specifically markup extensions) that further mitigate costly (repetitive) tasks. Of course, this doesn't always pan out as we have already mentioned earlier with the converter hacks required for XAML-binding. However, I would suggest that this is a limitation of the language however and not the workflow which I am espousing.

    The point being that any data language that continues to evolve will improve upon it, much like a coded language. Unfortunately, we simply have not seen Xaml evolve like C# has over the years.

    I would also like to mention that attempts have been made in the past to "codify" UI and haven't been too successful. Nothing beats a visual experience. HOWEVER that is not to say that you won't be successful in your approach. If anything, I am glad to see you promote the greatest feature of Xaml which was for all intents an purposes an CLR object graph serializer. In fact, we call it Xaml but at the end of the day it was ultimately compiled into C#/IL via the .baml graph embedded in the assembly.

    Finally, I am not sure if you have tried WebFlow yet, but I find it really amazing. I would love to see something like this for .NET. I look at the experience it offers versus the experience you are describing above and it is simply not even a contest. However, that is just MY opinion and I wish you the best of luck in your efforts. Much like I was saying earlier ... if it works for you then all the power, Brogrammer!

  • MarcoTronconeMarcoTroncone GBUniversity ✭✭✭

    I've always created my UI using C# but I'm now mostly using XAML (Expecially now that I user LiveXAML).

    I have to say that I've completely rewritten an app to design my UI in XAML while it was written in C# and this is what I can tell of my experience:

    Why you should prefer XAML:

    It's cleaner
    You can separate you UI from your code in a better way
    With some tools you can see immediately what you are writing and this case save you hours!

    Why you should prefer C#:

    It's faster to run
    You can reuse a lot of your code
    You have more control over your UI (if you want a pixel-perfect UI)

    I have to say that in this moment I think that XAML is better that C# for UI but maybe it can change in future...especially is LiveXAML can implement its live preview with C# (this is the main reason why I'm now using XAML)

  • VincentHVincentH USBeta ✭✭

    @MikeEEE said:
    Along such lines, consider that visually inclined individuals (in my experience) want nothing to do with the code editor and > prefer visual designers/tooling, and that is what I am personally angling for in my discussion here.

    Thx Mike, that clarifies what your goal is here, which fits this discussion very well. Blend once was pretty good for WPF (worked for you, but didn't for me).

    Regrettably, there currently is no designer tool for Xamarin that comes anywhere near to what Blend was. People creating Xamarin production apps with XAML today use Visual Studio and run the app to see the UI; the VS designers simply can't display the UI due to their many limitations. My low time estimate for switching to declarative C# is for people already working with VS this way, as illustrated in the screenshots, given existing tooling.

    To get at Blend(+) level tools, you would need much more XAML tooling effort from the Xamarin team(s). The reason I started this discussion, given that the teams are too small as it is, was to redirect their scarce time to improvement of the core frameworks and tools.

    Who knows, maybe Microsoft will grow the Xamarin teams a lot and we will both get what we want :-)

  • VincentHVincentH USBeta ✭✭

    @MarcoTroncone said:
    I have to say that in this moment I think that XAML is better that C# for UI but maybe it can change in future...especially is LiveXAML can implement its live preview with C# (this is the main reason why I'm now using XAML)

    This is spot on Marco - the main reason for you switching to XAML is the tools. It so happens that as a result of this discussion, I am working with the LiveXAML creator Mihhail Maslakov to support declarative C#; he already has the declarative UI examples at https://github.com/VincentH-Net/CSharpForMarkup working in LiveXAML

    Once that is working... :-)

  • AndrewMobileAndrewMobile USMember ✭✭✭✭
    edited May 2018

    @VincentH said:

    @AndrewMobile said:
    Code always has so many ways of looking more personal, from naming variables to structuring. XAML can have some of that too, but to much less extent. When you open a XAML, you know exactly to expect, for the most part.

    I recognize from several reactions that some limitations of XAML can be used to an advantage (as a famous soccer genius once said, "every disadvantage has it's advantage"), if you need to ensure that developers stick to standard syntax, conventions and good separation.

    While limiting others can keep them from mischief, it also reduces their productivity, and makes them less happy about their jobs.

    If you think that using XAML means "makes them less happy about their jobs" then I guess all Windows XAML developers using WPF\Silverlight\UWP must feel miserable :)

    @VincentH said:
    Consider that you may achieve more with existing code quality control measures that do not limit productivity. E.g. if you put the helpers in a NuGet, effectively defining the markup DSL for your team(s), you can easily ensure standardization of your declarative C# files content in a build step or an analyzer, failing or warning when people check in code that violates your standards.

    Yes sure, you can setup different build things to ensure code standards, but if you think that's easier to than just sticking to XAML, which is simpler and more precise, then go for it.

    I am not sure what is the point you're trying to make to be honest. You seem like you have some strong opinions against XAML for some reason, even though you perfectly understand it. You are trying to promote the idea that "Xamarin should redirect XAML efforts elsewhere". Not really sure what's the point of this rant.
    Xamarin Forms going away from XAML, removing features, is the last thing Xamarin Forms would need, like it doesn't have enough problems already.

    If you have any constructive ideas how to improve Xamarin Forms, I'd be happy to applaud and discuss.

  • CharlesRoddieCharlesRoddie USMember ✭✭
    edited May 2018

    @MikeEEE said:
    I am with you on the converter hacks, but Xaml (WPF's at least) has a great type system. Or I should say better than average, these days.

    Just look at this issue:
    https://github.com/xamarin/Xamarin.Forms/issues/2753
    "[Binding] use DefaultValue on failed type conversion"

    It's clear from this that bindings have no type-safety. And bindings underlie real-world xaml usage. This is not better than average. It's vastly inferior to any static type system out there.

  • MikeEEEMikeEEE USMember ✭✭✭
    edited May 2018

    If I am not mistaken @CharlesRoddie that is the Xamarin Forms Xaml Model, not WPF's model, which I was referring to, in your quoted material of me. :smile:

    Additionally, after studying this for a bit, I believe you were/are (rightfully) concerned with type safety whereas I was/am more concerned about the serialized type model. In your case, the example you provide is an excellent one and I am in agreement.

    To clarify my point further, I was drawing a comparison to other serialization mechanisms such as the classic XmlSerializer and the DataContractSerializer. Both of these struggle mightily with recognizing basic .NET type model constructs (e.g. interface properties), and was actually one of the many reasons I felt compelled to write ExtendedXmlSerializer. (Warning: shameless plug. :lol:)

    With WPF and Silverlight, you have the ability to utilize the design-time namespace and DesignInstanceExtension to declare the types of objects you will be working with at runtime, which assists tooling in providing the appropriate feedback when creating your bindings. And, as far as I can recall, the DefaultValue and TargetNullValue properties can be used in conjunction to yield the desired result in the referenced GitHub issue -- in WPF's Xaml model.

    However, all said, I would say that you are correct in your sentiment, @CharlesRoddie. But also, keep in mind that WPF is going on a decade now in age. F# and other type systems (Haskell is the tops from what I have been reading) that have been created since then have produced certain expectations for current tooling that simply was not there when WPF/Xaml/Silverlight was created.

    That's probably a good segue into saying that I have been giving this problem space and area a little more thought, and given the constraints and resource challenges that are being faced here, I think @VincentH's approach is a good one. Keep in mind that I am not invested in Xamarin Forms like everyone here is, and my ideas/notions are rooted in the past and more in theory rather than in the here-and-now with actual investment and application (pardon the pun). I thought about your last response to me @VincentH and if I were in your shoes, your approach here would make sense to me, as well, FWIW. :+1:

  • CharlesRoddieCharlesRoddie USMember ✭✭
    edited May 2018

    This all makes sense. (Except Haskell is from 1990.) More relevant than other languages is .Net generics which came at the same time as WPF, in 2006. It's a shame that WPF's binding framework didn't make use of generics, and that Xamarin.Forms copied WPF.

  • MikeEEEMikeEEE USMember ✭✭✭

    Wow I had no idea that Haskell is that mature. FWIW, I have been following Mark Seemann's Blog for some time now and have been reading the good things about Haskell (and of course F#) there. I am certainly interested in any additional F#/functional resources/urls/blogs if anyone has others that they frequently visit.

    (Also, speaking of feeling compelled, I should clarify to avoid misrepresentation that I helped write ExtendedXmlSerializer -- specifically v2, and am one of two primary authors in the repository. I would've edited my earlier post but there is a time limit on this forum in doing so. I was too focused on my shameless plug and we can see where that got me. :wink: )

  • JeroMiyaJeroMiya Member ✭✭

    @VincentH Resurrecting an old thread, but this discussion is becoming increasingly relevant with the release of Flutter 1.0 and widespread adoption.

    I think your original post points out one major advantage of Flutter over Xamarin.Forms, but in my view there are four major innovations in Flutter that need to be addressed if Xamarin.Forms is to remain competitive:

    1. Declarative code-based layout, as opposed to XML-based layout. For all the reasons you stated in your original post. Now, C# is not (yet) the best language for declarative markup style APIs, but things have improved a little with C# 6/7/8, so we might be getting there. Of course there's always F#, which is AMAZING at declarative markup style APIs.
    2. Declarative C# UI definitions aren't enough. Flutter's react-style immutable UI framework has major benefits over the mutable UI with data-binding system of XAML based UI frameworks. This can't be added to Xamarin.Forms without creating a new independent layer or shadow DOM on top of Xamarin.Forms, which for many reasons is not the right path to take (see the many articles on why people moved from react native to flutter).
    3. Flutter does not use native controls - it draws everything to a Skia surface. Thus, your application looks, down to the pixel, exactly the same on all platforms you run it on. This is a MAJOR improvement over Xamarin.Forms use of native controls. A huge portion of the Xamarin.Forms bugs and my time as a developer spent testing and tweaking styling and layout on each individual platform. In Flutter the UI is almost pixel perfectly consistent on every platform. This also allows Flutter to be far more efficient and smooth, particularly with respect to scrolling and animations.
    4. STATEFUL Hot reload. Cannot stress enough how huge an advantage this is over Xamarin.Forms. It takes over a minute between making a UI change and seeing the results. With Flutter, changes are refreshed instantly.

    This post isn't a Flutter endorsement, but I think it's important to understand fully where the weaknesses and challenges are. The declarative C# framework takes care of point 1, but point 2 can't easily or efficiently be bolted onto the existing Xamarin.Forms framework. Point 3 could be implemented with custom platform renderers, but you lose many of the advantages without immutable UI as in point 2. Point 4 - I just don't know how that could be implemented in Xamarin.Forms. Flutter's runtime works together with the framework to preserve state and enable fast hot reloads of code at runtime. What is the equivalent on Mono/Xamarin runtime? Interpreted DLLs?

  • NMackayNMackay GBInsider, University mod

    @JeroMiya said:
    @VincentH Resurrecting an old thread, but this discussion is becoming increasingly relevant with the release of Flutter 1.0 and widespread adoption.

    I think your original post points out one major advantage of Flutter over Xamarin.Forms, but in my view there are four major innovations in Flutter that need to be addressed if Xamarin.Forms is to remain competitive:

    1. Declarative code-based layout, as opposed to XML-based layout. For all the reasons you stated in your original post. Now, C# is not (yet) the best language for declarative markup style APIs, but things have improved a little with C# 6/7/8, so we might be getting there. Of course there's always F#, which is AMAZING at declarative markup style APIs.
    2. Declarative C# UI definitions aren't enough. Flutter's react-style immutable UI framework has major benefits over the mutable UI with data-binding system of XAML based UI frameworks. This can't be added to Xamarin.Forms without creating a new independent layer or shadow DOM on top of Xamarin.Forms, which for many reasons is not the right path to take (see the many articles on why people moved from react native to flutter).
    3. Flutter does not use native controls - it draws everything to a Skia surface. Thus, your application looks, down to the pixel, exactly the same on all platforms you run it on. This is a MAJOR improvement over Xamarin.Forms use of native controls. A huge portion of the Xamarin.Forms bugs and my time as a developer spent testing and tweaking styling and layout on each individual platform. In Flutter the UI is almost pixel perfectly consistent on every platform. This also allows Flutter to be far more efficient and smooth, particularly with respect to scrolling and animations.
    4. STATEFUL Hot reload. Cannot stress enough how huge an advantage this is over Xamarin.Forms. It takes over a minute between making a UI change and seeing the results. With Flutter, changes are refreshed instantly.

    This post isn't a Flutter endorsement, but I think it's important to understand fully where the weaknesses and challenges are. The declarative C# framework takes care of point 1, but point 2 can't easily or efficiently be bolted onto the existing Xamarin.Forms framework. Point 3 could be implemented with custom platform renderers, but you lose many of the advantages without immutable UI as in point 2. Point 4 - I just don't know how that could be implemented in Xamarin.Forms. Flutter's runtime works together with the framework to preserve state and enable fast hot reloads of code at runtime. What is the equivalent on Mono/Xamarin runtime? Interpreted DLLs?

    1. That's personal preference, hate code based UI's but for really complex layouts, I'm sorry but XAML makes managing large projects easier in my experience, last app has over 100 pages.
    2. There's effortsbenefit if it supported native control rendering and Skia rendering for controls, Telerik's control suite is already a mix of both as it has a Skia dependency. Also clients/designers DO want native behavior, in my experience they want a mixture of both.
    3. You buy LiveXAML and you have that in Forms

    What you don't have with Flutter is as strong an eco-system as .net, nowhere near it, I couldn't recommend a platform that has over 4000 open issues currently.

    I haven't seen Flutter jobs advertised tbh, it's still new and people will dip their toe in the water, I do see people crying out for Xamarin devs, it's more mature and has strong eco system making it a less risky choice, so to say it's been widespread adoption for Flutter, I'd need to be convinced.

    It's looks very good but Dart is not as nice as C# hence Adam's efforts with Fluttersharp to try and bring the .net eco system into Flutter.

    It's fascinating and I keep a close eye on where it's going, for creative Flutter may gain quick traction, for Enterprise dev, I'm not so sure at all. A lot of us like XAML based UI's though, it get's a little tiresome when people propose only code based approaches.

  • NMackayNMackay GBInsider, University mod

    The key people within MS are listening...

  • JeroMiyaJeroMiya Member ✭✭

    @NMackay So first of all, I also much prefer C# and .NET to Flutter and Dart. I'm just pointing out places where Flutter has some advantages over Xamarin.Forms in the hopes Xamarin.Forms (or even a new framework) heads in a good direction and remains competitive. .NET does not currently have a good Reactive style UI framework with consistent vector based control rendering. It's something some developers want and prefer, but which doesn't have a first-class Microsoft-funded solution.

    As for the XAML vs Code debate - there's no reason both can't be supported. In fact Xamarin.Forms technically supports both now - however the API isn't very conducive to declarative code-based layout, which is why @VincentH made a library to improve that experience. If you're going to support code-based layout, the API needs to be adjusted to help make that less painful, especially in C# which is a bit verbose for those kinds of things (which is a valid point in favor of XAML, at least if you're using C#). I mention it along with the reactive style immutable UI because that style of UI framework typically starts with a top level function for building the UI, and has a declarative or fluent API. It's there that you would inject a XAML based layout. Something like this:

    public Widget Build() => new XAMLWidget("./MyPage.xaml");

    And even this could be auto-generated for you when you have a XAML/CodeBehind pair.

    As for adoption rates and developer mindset - we may be in different developer circles. I've been hearing about it a lot, especially since the 1.0 release. It's very popular in the dev conference scene, and it's getting a lot of buzz. There's nothing inherently enterprise-unfriendly about it other than a lack of high quality charting and data grid controls, and those will come sooner or later.

    More broadly, the react style immutable UI framework design has been winning over developers from template/MVVM based frameworks. For example: adoption rates of React (which works like Flutter) are pulling ahead of Angular (which works more like XAML/MVVM) by a wide margin.

  • NMackayNMackay GBInsider, University mod

    "As for the XAML vs Code debate - there's no reason both can't be supported"

    Agreed.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Personal two cents worth...

    For example: adoption rates of

    Statistics in many cases are meaningless or manipulated to the desired result by the entity collecting them.
    For example: CSS was added to Xamarin.Forms and suddenly the "adoption rates" went through the roof.
    That doesn't mean its actually used by developers for real programs. That just means that everyone that was already registered as a web developer was now classified also as a Xamarin developer since technically they could make UI using CSS (what a truly horrible thing). But it makes the numbers look great.

    No different than when Xamarin was bought and made free instead of paid or part of only the Enterprise version of Visual Studio. Suddenly there were 5 million more users. Well... Not really because not every Visual Studio user was a Xamarin user. But it sure boosts the statistics if every VS install is classified as a Xamarin user.

    I agree that's its fine to support both. No argument there. Let C# be used to make UI just like XAML. Fine.

    But what do you say they fix the underlying mechanisms and controls first? What's the point of adding 1:n different ways to make UI if the UI itself is broken? It doesn't matter if its made with XAML or C# or F# or ButterflyTears.

    There are still countless bugs (formerly bugzillas) that haven't been fixed since original reports 3 years ago.

    All I'm saying is that since there isn't unlimited man power... Prioritize. Fix the borked stuff. THEN add new ways to access that stuff. Doesn't seem like rocket science.

  • JeroMiyaJeroMiya Member ✭✭

    Yep, seems like there's some consensus on these points. Bug fixing should have a priority. Supporting both XAML and declarative C# - seems like a good idea.

    ButterflyTears is an awesome name for a programming language or tool, by the way.

  • EasyGoingPatEasyGoingPat GBMember ✭✭✭

    I'm undecided on this issue.

    I currently mostly work alone so am probably not a typical Xamarin developer. I haven't found any disadvantages with using XAML lately (now initial bugs have been fixed) but I haven't found any advantages either.

    There is one feature that is missing from Xamarin XAML (and also to my knowledge missing in WPF XAML) and that is support for conditional compilation.

    I currently have a couple of screens that have a 'Debug' control somewhere on them. This has to be added in code. And sometimes it is not easy, because I might want to change exactly where, how and what is added to the screen's visual tree in Debug builds.

    If I wanted, say, a button in only Debug builds, I guess I could add it with a name in XAML and simply set its visibility in C# but this doesn't seem like much of an improvement.

    • Patrick
  • MatthewJoughinMatthewJoughin ZAMember ✭✭

    This is awesome! I have been using coded UI with Xamarin.Forms for a while now, mainly for performance, but also for dynamic reasons, and this really assists with that. I was a WPF developer (and VB6 before that), so I have seen the worst I agree a markup language is not always the best solution to every problem. I do agree it should still exist, but I also agree investment in the Xamarin team shouldn't be spent on making new designers - to me designers are so VB6 - they shouldn't exist in modern software dev. Apples Interface designer a case in point - it is horrible

  • JeroMiyaJeroMiya Member ✭✭
    edited January 16

    So this project is focused on F#, and I don't know if it can be used cleanly from C#, but I thought it was very interesting and provides both a declarative layout API and an immutable UI/state reactive style API similar to Flutter/React. And, it "renders" its internal UI representation to Xamarin.Forms (with efficient diffs/etc..):

    https://fsprojects.github.io/Fabulous/

    Those F# folks are way ahead of us! :P

  • VovaKamishnikovVovaKamishnikov USMember ✭✭

    Main advantage of using XAML for me is I no longer need a separate ViewModel.
    XAML is View and code behind is ViewModel.
    This greatly simplifies the application architecture

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @VovaKamishnikov said:

    Main advantage of using XAML for me is I no longer need a separate ViewModel.
    XAML is View and code behind is ViewModel.
    This greatly simplifies the application architecture

    Then you have no understanding of MVVM. Code behind the UI is NOT the ViewModel.

    The point is you ARE supposed to separate view and viewmodel. ViewModel knows nothing of the 0:n views that are using it as the binding context. You could have 50 different views all using the same VM as its binding.

    If its your intention to one day get paid to do development I URGE you to stop coding until you can take the time to LEARN. The longer you keep doing it wrong the harder it will be to unlearn all the bad concepts and practices - and you'll still have to go through the learning process to understand the correct way to do things. There is no positive reason to keep going the way you are.

  • VovaKamishnikovVovaKamishnikov USMember ✭✭
    edited January 17

    @ClintStLaurent said:

    Then you have no understanding of MVVM. Code behind the UI is NOT the ViewModel.

    Why not ? My typical codebehind-ViewModel is just an ordinary ViewModel

    @ClintStLaurent said:
    You could have 50 different views all using the same VM as its binding

    Do you really have many views for one VM in Xamarin Forms ?

    @ClintStLaurent said:
    There is no positive reason to keep going the way you are.

    Definitely is. It makes everything so much easier

  • AdamMeaneyAdamMeaney USMember ✭✭✭✭

    Is the world really that much easier than creating another file for your VMs?

    It takes about 2 seconds to make a file and reference it in your page.

    But this ignores things like Unit Testing your VMs as now you are tied to the Xamarin ecosytem for that.

    At least for testability, the 2 seconds a separate file takes win out.

    And while I usually only have 1 view with my viewmodel, there are plenty of cases I have had multiple views using the same view model.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Its not a ViewModel if its the code behind for the View. That's the point I'm trying to make. You have your terms confused. If its the code behind a view... and it knows anything about the view, then its View layer not data/logic which is what a ViewModel is.

    Do you really have many views for one VM in Xamarin Forms ?

    Absolutely. Just one example: Human Resources app or a scheduling app. You might have 10 different views pertaining to an Employee or a Shift. But they still all use the ShiftViewModel because that's where all the data pertaining to a work shift resides. But one View is a calendar layout. One view is a manager's view. One view is limited to just the employee view. and so on.

    Look. Its no skin off my nose. But just to let you know... If you're just doing hobby coding for yourself then do it however you like. But if you're hoping to work for a company developing software one day... What you have there is so far out of practices and standards that if you submitted it as part of a coding test at an interview it would nearly certainly get your resume shuffled to the bottom of the pile. I don't say that to be mean. Like I said, what you do and how you do it doesn't affect me. I'm just trying to help guide you back in the right direction if it matters for your future plans.

  • VovaKamishnikovVovaKamishnikov USMember ✭✭
    edited January 18

    @AdamMeaney said:
    Is the world really that much easier

    I've written separete VMs for many years and I say yes it's really much easier have VM in code behind

    @ClintStLaurent said:

    Do you really have many views for one VM in Xamarin Forms ?

    Absolutely. Just one example: Human Resources app or a scheduling app. You might have 10 different views pertaining to an Employee or a Shift. But they still all use the ShiftViewModel

    No problem. I'd create base class ShiftViewAbstract

2»
Sign In or Register to comment.