Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Concise, declarative C# UI markup for .NET browser / native UI frameworks

License

NotificationsYou must be signed in to change notification settings

VincentH-Net/CSharpForMarkup

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

59 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Use declarative style C# instead of XAML for Xamarin Forms UI.

November 18, 2021

#CSharpForMarkup 2 is coming to WinUI 3 and Uno Platform

I got the #webassembly target working today.

Build web apps with just C#. No HTML or XAML needed. Flutterize .NET (tweet)

October 18th, 2021

CSharpForMarkup 1 is ported to .NET MAUI Community Toolkit

Xamarin.CommunityToolkit.Markup is now ported toCommunityToolkit.Maui.Markup! Read all about it inthis blog post by Brandon Minnick

November 19th, 2020

CSharpForMarkup for Forms 5 is now part of the Xamarin Community Toolkit

Xamarin Community Toolkint C# Markup targets Xamarin Forms 5 and includes all the new features from theCSharpForMarkup Part 2 Forms PR. C# Markup is a separate XCT NuGet package without any dependencies on other XCT packages; nothing but Forms 5 is required.

Using Xamarin Forms 5? Check outXCT C# Markup!

Using Xamarin Forms 4.6 - 4.8? Use thebuilt-in C# Markup.

Why move to the Toolkit?

Asannounced, Xamarin.Forms 5.0 is the last major version of Xamarin.Forms; new major features and development will be in .NET MAUI and the Xamarin Community Toolkit. Because C# Markup in Forms 4.6 - 4.8 is an experimental feature which will evolve significantly, the team proposed to move C# Markup to the Xamarin Community Toolkit where there is less red tape (than is added to Forms 5) to ensure rapid innovation can continue. Microsoft owns and supports the Xamarin Community Toolkit just like other Xamarin libraries. Also, C# Markup for MVU and MVVM will be kept aligned while MAUI is developed (details)

July 15th, 2020

C# Markup introduction post published on the Xamarin Blog

See myIntroducing C# Markup for Xamarin.Forms guest post on the Xamarin blog to learn many C# Markup features while building a simple example.

Here is the2.5 minute video showing it from beginning to end, usingLiveSharp for hot-reload:

Introducing Xamarin Forms C# Markup

March 31st, 2020

CSharpForMarkup is incorporated in Xamarin Forms 4.6!

Thanks everyone for supporting theSpec CSharpForMarkup PR on the Xamarin Forms repo!

The PR received an unprecedented200+ positive reactions (the nr 2 most popular Forms PRever received just 40) and was merged into the Xamarin.Forms.Core 4.6 package in theXamarin.Forms.Markup namespace.It is available in the current Xamarin Forms prerelease NuGet as an experimental feature. The documentation for the feature, which is called"C# Markup", can be found indocs.microsoft.com.

CSharpForMarkupMergedInForms46

Note some helpers were renamed in Xamarin.Forms.Markup, and quite a few helpers and improvements were added. CSharpForMarkup users are encouraged to migrate:seeMigrate from CSharpForMarkup to Xamarin.Forms.Markup. Thanks!

To Be Continued

C# Markup is already included in.NET MAUI, the exciting next evolution of Forms, which amongst many other innovations adds support for MVU. See thisC# Markup for MVU and MVVM Spec PR for next-gen features.

In the mean time, I plan to add more features to C# Markup in new Xamarin Forms PR's. If you have issues or ideas, please add them in the Forms repo, include a link tothe PR and add CSharpForMarkup in the title. I also wil be working on tooling to support C# Markup (e.g. autoformat, convert XAML to C# Markup). Thanks!

Why use C# for Markup?

Becausedeclarative UI in C# has a much better developer experience than XAML, and reads either very similar or with more clarity.

Modern UI frameworks such asFlutter andSwiftUI offer declarative UI. Many developers really enjoy using a single powerful language for logic and markup. It makes things simpler and lets you use the same IDE features everywhere. CSharpForMarkup offers this for Xamarin Forms; no need to learn XAML.

If you do know XAML, you can keep using your knowledge, and gain productivity (because of the better IDE support for C# and because you don't need language bridging mechanisms). The syntax is very close to XAML and the same MVVM pattern is used; you should be familiar within a couple of hours.

Declarative C# versus XAML

Compare this Entry markup:

Entry X A M L XAML

Entry C Sharp Long C#, close to XAML

Entry C Sharp Short C#, shorter

SeePro's and Con's for a detailed comparison.

Real World Examples

See CSharpForMarkup in action withLiveSharp for hot reload:

CSharpForMarkup with LiveSharp

Check out this awesome Twitch stream byDavid Ortinau whereRyan Davis demonstrates these helpers - using hot reload!

CSharpForMarkup with Ryan Davis and David Ortinau

CSharpForMarkup has been battle tested for usability and stability. It has been used for years to build production apps, e.g. the app in this video:

LiveSharp Production App

How about some real-world source? Here is a simple registration code page (taken from a production app):

XAML:

Page X A M L

C#, close to XAML:

Page C Sharp Long

By using more helper methods, you can further improve C# readability (but it will be less simular to the XAML):

Page C Sharp Short

Declarative C# versus XAML considerations

Some observations that may help you if you like XAML but wonder whether declarative C# would work for you:

Patterns and Tooling Pro's:

C#

Compose Markup In CSharp

  • Simplycompose markup top-down withnamed methods or properties for better maintainability of complex UI. It can read like a story (see example above)
  • Refactorings like renaming a bindable property work reliably across logic and markup; zero chance of broken bindings.
  • Cleanly separate UI markup from UI logic while encapsulating both in a single class withpartial class files, e.g.LoginPage.cs +LoginPage.logic.cs.
  • No need for separateValue Converter classes. Inlining simple value converter code in your markup improves UI maintainability.
  • No need forXAML Triggers
  • No need forXAML Compilation
  • No need forXAML Compiled Bindings. Bindings are fully compiled, including bindings that specify theSource property (which XAML can't compile).

Reading Pro's:

C#

  • Numbers and enums don't need quotes
  • Constants don't need keyword or quotes (i.e.name vs"{StaticResource name}" )
  • Can use calculated constants (i.e.marginb = margina + 10)
  • Don't need parent class (i.e.RowDefinitions vsGrid.RowDefinitions)
  • Designed for human readability

XAML

  • Don't need enum name (i.e."End" vsLayoutOptions.End)
  • Don't neednew keyword for each control
  • Don't needChildren = { orContent = for child controls
  • Designed for (visual designer) tools

Editing Pro's:

C#

  • No strings for properties: rename, code lens (where/not) used, compile time safety all just work
  • Better IntelliSense (i.e. in XAML margins are strings)
  • Simpler markup reuse (control builder method with parameters)
  • Simple extensibility (i.e. don't need to write XAML extensions; customize your markup syntax with extension methods, creating your own DSL if you like)
  • Better Diff & Merge
  • HotReload inLiveSharp

XAML

  • Visual preview in IDE (very limited - no renderers etc)
  • HotReload inLiveXAML

Summary

The question of C# versus XAML is not so much "Why use C# for markup?" as it is "Why use XAML for markup?"

  • Why would you want to hand-code an object serialization format?
  • Why would you choose a different language for markup if it reads the same but has inferior IDE support?
  • Why would you scatter your UI markup with language bridging mechanisms? (converters etc)

Background

This repo resulted from this discussion on the Xamarin Forms forum:Using declarative style C# instead of XAML - should Xamarin redirect XAML efforts elsewhere?

Imo XAML in Xamarin Forms exists for historical reasons, to convince developers that are familiar with other Microsoft XAML dialects to onboard. However, if used as above, developers can use their existing XAML knowledge in C#. It should not take more than a day to become accustomed to the small syntax changes, to gain productivity every day.

Migrate from CSharpForMarkup helpers file to Markup in Xamarin.Forms 4.6 - 4.8

If you are using the original CSharpForMarkup helpers file from this repository, here is how you can migrate to markup Xamarin.Forms.

If you want to migrate to XCT C# Markup, first performs below steps and then continue with the migration steps described in theXCT C# Markup docs.

You can do these steps quickly with a regex replace or by renaming the helpers inXamarinFormsMarkupExtensions.cs and letting Visual Studio update your markup.These are the renames:

  • Helpers ending onH /V -> end onHorizontal /Vertical
  • Col ->Column throughout
  • BoolNotConverter ->NotConverter
  • EnumsForGridRowsAndColumns ->GridRowsColumns
  • sourcePropertyName parameter of the binding helpers ->path
  • NamespaceCSharpForMarkup ->Xamarin.Forms.Markup. After switching to the new namespace (you will need to update to Xamarin.Forms 4.6 or later) you can deleteXamarinFormsMarkupExtensions.cs.

Other changes:

  • To useLeft/TextLeft orRight/TextRight, add eitherusing Xamarin.Forms.Markup.LeftToRight orusing Xamarin.Forms.Markup.RightToLeft. For markup that is designed to support both left-to-right and right-to-left flow direction, it is recommended not to include either one of above namespaces, and instead use the newStart/TextStart &End/TextEnd helpers
  • Bind,Assign andInvoke helpers now targetBindableObject (was limited toElement)
  • Default bindable properties were added for most built-in Forms types
  • AddedDefaultBindableProperties.Register andDefaultBindableProperties.RegisterForCommand to register default bindable properties for custom/3rd party view types
  • Font helpers now support any IFontElement (was limited to Button, Label, Entry and Picker)
  • Gesture recognizers: more built-in gesture recognizer types are supported, support to initialize gesture recognizers was added, support all possible binding parameters
  • Converters: support for typed converter parameters and culture
  • AddedBindCommand helper to bind to defaultCommand +CommandParameter parameters with a single method call
  • AddedColumns.Define(width, width ...) andRows.Define(height, height...) overloads forGrid to support concise row / column definitions without using enums
  • RemovedRowCol; useRow +Column instead.
  • Removed PlatformSpecificsExtensions - replace with guidance in PR description on how to use any platform specific with .Invoke
  • Several bugfixes

NJoy!

About

Concise, declarative C# UI markup for .NET browser / native UI frameworks

Topics

Resources

License

Stars

Watchers

Forks

Sponsor this project

 

Packages

No packages published

Languages


[8]ページ先頭

©2009-2025 Movatter.jp