Hello,
I'm actually looking to move a WPF application, using Telerik UI for WPF, to MAUI, so it can run also on Mac.
Looking at what's currently used in the application and what's available in Telerik UI for MAUI, I found that the following is missing:
- The Ribbon control.
- The Docking control.
- In the DataGrid control, the possobility to have row details.
- The window control, used to display dialog boxes.
Do you intend to add these controls, and to add row details in the DataGrid control?
1 Answer, 1 is accepted
Hello Patrick,
To get an official answer to your question, the UI for MAUI Roadmap is the only official answer I can provide. However, you'll find that page is currently empty because it is still very much a preview technology, with no go-live license or guarantee of stability (there are breaking changes every release). Once we have v1.0 available, then we'll have more info to share.
The easiest way to get an "unofficial" initial understanding of what is initially coming to Telerik UI for MAUI is to look at what is available for Telerik UI for Xamarin. We are working hard to bring as much of that functionality/components over to MAUI as possible (either as pure native MAUI handlers or compatibility shims), in addition to new components and functionality.
For now, I can give you some initial hints. Please note that these are not official answers, but some initial things to think about.
1. Ribbon
This is, generally-speaking, not a cross-platform/mobile-friendly component which MAUI is mostly focused on.. don't forget that MacCatalyst is really iOS running on MacOS.
We do have a Ribbon available for WinUI 3, but it isn't something that yet works well mobile devices. However, there are many ways you can still achieve the same goal with other components for a more mobile friendly UX (e.g. RadTabView with custom TabHeader content).
That being said, you can open a Feature Request for this here (please open one Feature Request for each distinct thing) => Progress® Telerik® UI for .NET MAUI Feedback Portal.
2. Docking
We already have RadDocking control in MAUI => .NET MAUI DockLayout Documentation | Overview.
3. Detail Row for DataGrid
You'll want to open a Feature Request for this, it is not currently available in the cross-platform MAUI DataGrid
The most common UX pattern, that is also mobile friendly, is to show a modal popup when DataGrid selection is made. this can be done with a RadPopup (see #4) or an actual navigation to a modal ContentPage. (a modal navigation doesn't navigate away form the current page, instead it "slides" the new page on top of the the existing page. this is helpful when you do not want to unload an existing page's viewmodel/data state/etc.
Again, we're in early preview and I don't have an official answer for you on the state of a detail row being developed or considered. The feature is available on some native platforms already, so I recommend opening a Feature Request so the developers can keep track of demand and communicate any status changes.
4. Window
There is no concept of "Window" in MAUI, this is because not every platform has such a thing (i.e., iOS and Android). Instead, you use ContentPages. However, as you mentioned, you're really referring to a simple popup or dialog itself, in that case:
- We already have a component available RadPopup for complex UI popups => .NET MAUI Popup Documentation | Overview.
- Alternatively, you can use the MAUI's built-in DisplayAlert() method for simple messages with/without user-action:
Ultimately, MAUI is not a drop-in replacement for WPF where you can can instant Mac support for all the WPF components you're currently using. This is for two main reasons; 1) WPF XAML is different than MAUI XAML, and 2) some components are not small-form-factor friendly. However, you can can achieve your goal with some preparation and component replacement considerations.
I hope this helps answer your initial questions and gives oyu food for thought. I would wait until we get closer to official .NET MAUI release so that you can have a wider range of components to compare against and plan out what you might want.
Regards,
Lance | Manager Technical Support
Progress Telerik
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Rank 2
Iron
Iron
Iron
Hello Lance,
Thank you for your answer.
In my case, the goal is not to run on mobile devices, but only on Windows and Mac desktop computers. It's an application to manage competitions and there are too many data to display to make it usable on mobile.
1. Ribbon
RadTabView is really not the same as a ribbon, where icons are used to show data and also to execute commands.
2. Docking
MAUI RadDocking is not the same as WPF RadDocking: WPF Docking Control | Telerik UI for WPF
Microsoft and Telerik (and others) are too much focused on mobile for MAUI, just see that almost all examples are for mobile. But they both forget that MAUI can also be used to make desktop applications running both on Windows and Mac computers, without the need to run also on mobile.
Hi Patrick,
Indeed, I completely understand your goal and I am intimately familiar with the UI for WPF Ribbon and Docking components. What's important to keep in mind is that .NET MAUI is intended for all the platform targets available to it and Telerik UI for MAUI is being designed to work across them all (i.e. we can't ignore some targets for a couple controls)
If we build a component, it also needs to also work on iOS and Android. This is why you see the RadDock design is currently not the same as the WPF RadDocking, it needs to also support mobile layouts (the same is true for the Ribbon). This is the compromise I was referring to, you're not going to be able to get such a UX dense cross-platform layout.
This was the premise behind Xamarin.Forms, before developers started asking for strict cross-platform design. Originally, devs wanted an Android button to look like an Android button and an iOS button to act like an iOS button. then there was a bug shift in 2014-2015 where companies wanted all their apps to look and act identical.
Moving Forward
That being said, that doesn't mean the developers can't figure out ways to only light up certain features on the desktop platforms like it used to be in Xamarin. This is why I recommended Feature Requests so we can consider it as we're in the preview phase.
As an example; if we are going to include a Ribbon component in UI for MAUI, the native Windows component will be rendered using the UI for WinUI 3 Ribbon WinUI RibbonView Documentation - Overview | Telerik UI for WinUI (not the WPF ribbon). So you'll have the Windows side of things handled already, but they'll still need to build the iOS/Android/Mac ribbons and consider.
For your convenience I have gone ahead and opened the relevant feature requests for you. They explicitly state the desire for desktop-like features when rendered on desktop platforms.
Hello Patrick,
I wanted to take a moment to follow up with you again to share a reply that Yoan, our PM for UI for MAUI, had for another similar inquiry => Need WPF UI concepts migration path to .NET MAUI (telerik.com)
Although it's not exactly the same Q&A you and I had, it does touch on the topic of us focusing on delivering desktop-rich experiences when the MAUI target platform is a desktop environment.
I hope this provides you with some confidence that we'll be working towards the vision that you're hoping to have as .NET MAUI evolves.
Rank 2
Iron
Iron
Iron
Hi Lance,
Thank you for the additional information.
One thing that is also very important is the ability to create, show and print reports from a MAUI application. So there should be a reprt viewer with print capabilities.
As far as Reports go, you can do this right now using the HTML5 ReportViewer. Take a look at my example for Xamarin.Forms (you can do the same thing in MAUI)
- https://github.com/LanceMcCarthy/CustomXamarinDemos/tree/main/src/XFReportViewerDemo.
This is the viewer component that we spend a significant amount of development effort on, it is used on nearly all of our UI component suites across platforms. Either inside a C# wrapper (i.e. .NET Core/MVC), or in plan HTML5/jQuery, it accomplishes everything you need from a ReportViewer.
Native MAUI ReportViewer
A native MAUI ReportViewer would be the responsibility of the Telerik Reporting team, once MAUI becomes public. This is something that will need to have a stable platform before that team considers building a native component, especially considering you can use the HTML5 ReportViewer in the meantime.
I'll personally mention this request to the Reporting team. Once MAUI is an official platform, you can open an official Feature Request to the Telerik Reporting team.
Printing
Printing is essentially just an export command that also sending the PDF document to the OS's print capability. Though, I would recommend just using your Reporting REST API directly (instead of trying to workaround WebView security to download a file). It's easier to just make a single HttpClient request and take that byte[] content to send to the native platform's printing capability. IN fact, we even have a starter helper class that you can use here.
In either case, you will need to decide on how to address printing depending on the operating system. I'd recommend looking into Maui Essentials from Microsoft, which has a ton of helper APIs for commonly needed functionality( Note: Microsoft doesn't have any documentation for MAUI Essentials yet, but you can use the Xamarin Essentials version of the docs until it gets released in several months).
Rank 2
Iron
Iron
Iron
Hi Lance,
I tried the application and I only have a blank page that looks ugly, see the screenshot. Additionaly, the buttons at the top don't work and the page selection is weird.
For printing, PDF is not always a good path, because sometimes, for documents that needs precise positioning, people don't understand that they should not let Acrobat resize the document. I have seen this problem many times.
At least, the WPF report viewer lets printing directly, without using a PDF file.
Using Telerik Reporting REST API is not an option for the intended application, because they NEED to run locally, without an Internet connection. Also take into account applications that work with data on the computer, they will need an Internet connection just for printing? Not understable for customers.
As far as that specific demo goes, I'm not sure if I have the REST service running right now. The goal was mainly to show how to use a WebView, rather than anything specific about reports themselves. The appearance itself is changeable by changing the Kendo theme used. I'll revisit the demo and see if I can fix it up for a MAUI presentation.
Regardless of HTML5 ReportViewer complications, I do understand your request for a native ReportViewer (with its specific benefits like offline support). I just wanted to properly set your expectations on how fast something like this might become available. It will need to be built, from scratch, for every platform that has never had a ReportViewer before (MacCatalyst, Android, iOS will need a new one).
We do have a native WinUI 3 ReportViewer, which is what you can expect to see rendered on the Windows platform in a MAUI application => https://docs.telerik.com/reporting/using-reports-in-applications/display-reports-in-applications/winui-3-desktop-application/overview.