Maui Xaml
Matilda Equiluz
In a .NET Multi-platform App UI (.NET MAUI) app, XAML is mostly used to define the visual contents of a page and works together with a C# code-behind file. The code-behind file provides code support for the markup. Together, these two files contribute to a new class definition that includes child views and property initialization. Within the XAML file, classes and properties are referenced with XML elements and attributes, and links between the markup and code are established.
The first file pairing is App.xaml, a XAML file, and App.xaml.cs, a C# code-behind file associated with the XAML file. Both App.xaml and App.xaml.cs contribute to a class named App that derives from Application. The second file pairing is AppShell.xaml and AppShell.xaml.cs, which contribute to a class named AppShell that derives from Shell. Most other classes with XAML files contribute to a class that derives from ContentPage, and define the UI of a page. This is true of the MainPage.xaml and MainPage.xaml.cs files.
The first XML namespace declaration means that tags defined within the XAML file with no prefix refer to classes in .NET MAUI, for example ContentPage. The second namespace declaration defines a prefix of x. This is used for several elements and attributes that are intrinsic to XAML itself and which are supported by other implementations of XAML. However, these elements and attributes are slightly different depending on the year embedded in the URI. .NET MAUI supports the 2009 XAML specification.
At the end of the first tag, the x prefix is used for an attribute named Class. Because the use of this x prefix is virtually universal for the XAML namespace, XAML attributes such as Class are almost always referred to as x:Class. The x:Class attribute specifies a fully qualified .NET class name: the MainPage class in the MyMauiApp namespace. This means that this XAML file defines a new class named MainPage in the MyMauiApp namespace that derives from ContentPage (the tag in which the x:Class attribute appears).
The x:Class attribute can only appear in the root element of a XAML file to define a derived C# class. This is the only new class defined in the XAML file. Everything else that appears in a XAML file is instead simply instantiated from existing classes and initialized.
When Visual Studio builds the project, a source generator generates new C# source that contains the definition of the InitializeComponent method that's called from the MainPage constructor and adds it to the compilation object.
At runtime, code in the MauiProgram class bootstraps the app and executes the App class constructor, which instantiates AppShell. The AppShell class instantiates the first page of the app to be displayed, which is MainPage. The MainPage constructor calls InitializeComponent, which initializes all the objects defined in the XAML file, connects them all together in parent-child relationships, attaches event handlers defined in code to events set in the XAML file, and sets the resultant tree of objects as the content of the page.
Many shortcuts exist to set the values of these properties. Some properties are basic data types. For example, the Title and Text properties are of type string, and Rotation is of type double. The HorizontalTextAlignment property is of type TextAlignment, which is an enumeration. For a property of any enumeration type, all you need to supply is a member name.
For properties of more complex types, however, converters are used for parsing the XAML. These are classes in .NET MAUI that derive from TypeConverter. For the example above, several .NET MAUI converters are automatically applied to convert string values to their correct type:
When you run a .NET MAUI app, the MainPage is typically displayed. To see a different page you can either set that as the new startup page in the AppShell.xaml file, or navigate to the new page from MainPage.
The child of most ContentPage derivatives is a layout, such as a StackLayout or a Grid, and the layout can contain multiple children. In XAML, these parent-child relationships are established with normal XML hierarchy:
Displaying a Slider value using a Label can be achieved entirely in XAML with a data binding. However, it's useful to see the code solution first. Even so, handling the Button click definitely requires code. This means that the code-behind file for XamlPlusCodePage must contain handlers for the ValueChanged event of the Slider and the Clicked event of the Button:
Notice that assigning a handler to an event has the same syntax as assigning a value to a property. In addition, for the ValueChanged event handler of the Slider to use the Label to display the current value, the handler needs to reference that object from code. Therefore, the Label needs a name, which is specified with the x:Name attribute. The x prefix of the x:Name attribute indicates that this attribute is intrinsic to XAML. The name you assign to the x:Name attribute has the same rules as C# variable names. For example, it must begin with a letter or underscore and contain no embedded spaces.
In the example above the Button simulates a response to a Clicked event by displaying an alert with the Text of the button. Therefore, the event handler can cast the sender argument to a Button and then access its properties:
The OnButtonClicked method is defined as async because the DisplayAlert method is asynchronous and should be prefaced with the await operator, which returns when the method completes. Because this method obtains the Button firing the event from the sender argument, the same handler could be used for multiple buttons.
XAML is mostly designed for instantiating and initializing objects. But often, properties must be set to complex objects that cannot easily be represented as XML strings, and sometimes properties defined by one class must be set on a child class. These two needs require the essential XAML syntax features of property elements and attached properties.
I can't seem to find a simple text Input field to use in a .net maui xaml app. Looking at the docs in the User interface/Controls/Views section there is a a number of components handling user interaction/input such as checkbox and slider and even a searchfield-component (Which to me should only be a specialized input field), but no text input.
I'm building a MAUI app, the main page is stored in a file called MainPage.xaml. I also created a popup with the CommunityToolkit package. I was wondering if there is a way to include this PopUpPage inside my MainPage when a button is clicked. the PopupPage.xaml looks like this:
What you want to do, is put only this piece in a separate XAML file. Let's say that we name this PopupContent.xaml. As a template you might want to choose the ContentView (XAML) although it doesn't really matter as long as it's a XAML file. Make sure the content looks like this:
The major focus for .NET MAUI in the .NET 8 release is quality. As such, alotof our focus has been fixing bugs instead of chasing lofty performance goals. In.NET 8, we merged 1,559 pull requests that closed 596 total issues. Theseinclude changes from the .NET MAUI team as well as the .NET MAUI community. Weare optimistic that this should result in a significant increase in quality in.NET 8.
We hope to enable this feature by default in .NET 9, but for now we areproviding the setting as an opt-in, experimental feature. Applications that onlytarget one architecture, such as RuntimeIdentifier=android-arm64, will likelybe able to enable this feature without issue.
A JNI marshal method is a JNI-callable function pointer providedto JNIEnv::RegisterNatives(). Currently, JNI marshalmethods are provided via the interaction between code we generate andJNINativeWrapper.CreateDelegate():
Activity.GetOnCreate_Landroid_os_Bundle_Handler() is part of the typeregistration infrastructure, providing a Delegate instance toRegisterNativeMembers .RegisterNativeMembers(), which is eventually passed toJNIEnv::RegisterNatives().
In .NET 7, we started an experiment to see what it would take to supportNativeAOT on iOS. Going from prototype to an initial implementation: .NET 8Preview 6 included NativeAOT as an experimental feature for iOS.
NoteWe may consider unifying and improving MSBuild property names for this featurein future .NET releases. To do a one-off build at the command-line you mayalso need to specify -p:PublishAotUsingRuntimePack=true in addition to-p:PublishAot=true.
One of the main culprits for the first release was how the iOS workload supportsObjective-C interoperability. The problem was mainly related to the typeregistration system which is the key component for efficiently supportingiOS-like platforms (see docs for details). In its implementation,the type registration system depends on type metadata tokens which are notavailable with NativeAOT. Therefore, in order to leverage the benefits of highlyefficient NativeAOT runtime, we had to adapt.dotnet/runtime#80912 includes the discussion around howto tackle this problem, and finally inxamarin-macios#18268 we implemented a new managed staticregistrar that works with NativeAOT. The new managed static registrar does notjust benefit us with being compatible with NativeAOT, but is also much fasterthan the default one, and is available for all supported runtimes (see docs fordetails).
As .NET 8 Preview 6 came along, we finally managed to release our first versionof the NativeAOT on iOS which also supports MAUI. See the blog post on .NET 8Preview 6 for details about what we were able to accomplish in theinitial release.
In subsequent .NET 8 releases, results improved quite a bit, as we wereidentifying and resolving issues along the way. The graph below shows the .NETMAUI iOS template app size comparison throughout the preview releases:
Furthermore, in the latest RC 1 release the app size went even further downreaching -50% smaller apps for the template .NET MAUI iOS applications comparedto Mono. Most impactful issues/PRs that contributed to this:
64591212e2