I want to write a single modal which is going to use in Blazor App and Maui App.
I am little bit confused regarding Implement INotify Interface Because Blazor do not need INotify Interface to be Implemented in its modal but Maui need.
so here is my question
Does is it good practise to use Single modal in Maui and Blazor App ?
By using INotify interface for blazor is going to side effect or bad performace ?
What is good Practise to use single modal in both Blazor and DotNet Maui ?
Note : I am already aware of DotNet Maui For Blazor but it is not realated to my question.
Related
I am currently reading into building a custom UI using Wix#, but since I have more experience with (WPF) MVVM than with WinForms i was wondering if it was possible to use that instead.
Is it possible?
You can actually use WPF UI with Wix#. See example in wix# repo.
If you want to use WinForms mandatory, you can also try to utilize winforms bindings to write ui-related stuff in a wpf-style. See here about WinFroms bindings. But in my opinion, WinForms bindings is not so good and I personally prefer not to use them in simple UI.
We are considering migrating a UWP app to Xamarin Forms. We need to be able to save the state of complex objects such as an order form when the user navigates away and retrieve that state when the user navigates back. We also need to be able to cancel navigation from a viewmodel.
We use MVVM, so my questions are from that context, but we like to think of ourselves as pragmatic rather than zealous about such things.
In UWP we use the Template10 library to save state in the OnNavigatingFrom event. We retrieve the state in the OnNavigatingTo event. This works even when the app back button is clicked.
Xamarin Forms doesn't seem to have built-in events to handle navigating to and from a viewmodel.
Prism for Xamarin Forms has OnNavigatingTo but does not appear to have OnNavigatingFrom. On some pages we use OnNavigatingFrom to prompt the user to save or discard. OnNavigatingFrom can be cancelled in response to a dialog.
It also appears Prism does not handle navigation using the application back button or the hardware back button. We need to be able to handle navigation to and from viewmodels regardless of how the navigation was initiated.
I've spend a couple of weeks researching these issues and testing scenarios in Xamarin Forms. I assume I have missed something in my ignorance. I understand primitive types can be persisted to application properties, but it would be nice if we didn't have to serialize and deserialize complex hierarchical objects ourselves.
Is there a paradigm/framework in the Xamarin Forms world that will:
handle events navigating to and from a viewmodel
allow navigation from a viewmodel to be cancelled in response to a dialog
allow state to be saved navigating from a viewmodel
allow state to be retrieved navigating to a viewmodel
fire navigation events regardless of how the navigation was initiated?
I understand there are many questions in this one question, but we are not looking for individual solutions, but a paradigm or framework which gives us the tools to solve them all in Xamarin Forms, such as T10 does for UWP.
Not sure how long you spent researching Prism for Xamarin.Forms, but it provides everything you said it didn't.
You should start with this video. It's a little old, but it will get you started.
https://www.youtube.com/watch?v=DYRLcqG2BAY
As far as actually persisting the data, that's for you to decide. Prism will give you the hooks to do it.
I'm using MVVM and Unity, I've understrood how to show the shell View (MainView with its MainViewModel) but I couldn't find the right way to instantiate other windows, for example : Details Button that opens a new form and show other details.
So, I'm looking for a common way how to instantiate/Call other Views(WPF windows) with their ViewModels using MVVM and Unity.
This answer may help with understanding how to link multiple views/viewModels together. I don't typically find myself needing to open additional windows just displaying different views in the current window.
Please let us know if you're looking specifically for an MVVM solution for opening new windows.
Take a look at this answer: Handling user interactions in MVVM. You can utilize an interaction service to instantiate new WPF windows will still remaining decoupled.
You can also provide indirect communication in WPF by leveraging the Mediator pattern to publish a message from a view model that causes a new view to be instantiated. This answer Simple Mediator implementation gives a quick overview.
I recommend you read over the User Interaction Patterns guidance, as it covers many of the scenarios you will face when using MVVM.
This might be the most trivial question asked, but I raise it again. Am planning to get started with asp.net MVC on a personal project and here am struck if it supports webparts or any other alternative to it is present. I intend to have a start page similar to igoogle or pageflakes, but my initial research pointed out that as there's no ViewState nor Postback concepts in ASP.NET MVC implementing web parts is not possible.
If that is the case, are there any resources which helps in building a start page as the one i wish to using MVC.
PS: Links I found in the initial research
Quick tips on asp.net MVC -
webparts framework
Building widgets using jquery in
asp.net MVC
You should use AJAX to create widgets that can interact with the server without reloading the page.
This way, the widgets will not affect each-other.
jQuery will be useful here.
Alternatively, you could put each widget in its own <iframe>.
I want to start migrating a WebForms App to MVC. The process will be gradual, so both systems must co-exist.
The question is: Should I have two MasterPages, one for the WebForms pages and other for the MVC views? Is there a way to have only one?
In ASP.NET MVC the master page should derive from System.Web.Mvc.ViewMasterPage while in classic WebForms from System.Web.UI.MasterPage. If in MVC you use the latter you won't have access to any helpers. Although you could use ViewMasterPage in classic webforms because it derives from MasterPage (once again you won't have access to helpers in the web forms application but who cares).
So to answer your question, yes, you could have a common master page assuming it derives from ViewMasterPage.
This being said you probably won't be able to make this work as in an MVC master page you would use HTML helpers to render partial views like Html.RenderPartial which doesn't make much sense in a classic WebForms application and vice versa in a classic WebForms application you would probably be using some server side controls like <asp:xxx runat="server" /> or have a single form tag (again with runat="server") polluted with ViewState, etc... which hardly makes any sense in MVC. So my recommendation would be not to do like this.