Maui Application Architecture - Intra-view communication/Shared ViewModels

[shadowfoxish]

I'm heavily reworking a production application for doing warehouse activities from Xamarin.Forms to .NET Maui and some of the previous practices I implemented in XF no longer work or just feel kudgey and hackish with Shell. So I wanted to get some ideas from others. Sample apps I've found in various places demonstrate a lot of great features of the framework, but are contrived or missing key architectural concepts.

For tl;dr, my question is generally, what is the best way to pass data to and back from different pages which work together and essentially share a view model or sub-viewmodels between pages, while still keeping some semblance of DI/IoC, and maintaining references for databinding purposes? In XF, I just managed this through object references, and created views myself with viewmodel arguments I curated and hosted in the calling-view's model. With Shell navigation, I'm exploring IQueryAttributable to pass objects around, but it seems like I'm misusing it. Not that it doesn't work, just that it feels wrong. Maybe there is a better way. Maybe this is pretty good. What do you think?

The flow works like this, the user chooses the "Thing" activity. From there choose a specific Thing, and now they get to a listing page of Things. Perhaps these are work items they need to do some individual tasks to complete the Thing. When the user chooses to start doing Function 1 for example, I create a new sub view model inside the current view model, and pass that to the new page and show it. The new page binds to it, user updates it, and that page completes and returns back. In OnAppearing in the Thing Detail page now, I detect that the sub-view model related to Function 1 isn't null, so I knew I was coming back from the Function 1 task, and could do whatever necessary updates to the view model required.

My app is being built on and for Android devices with barcode scanning capability. Because of the barcode scanning need, the forms generally have to be pretty small and purpose-oriented. So the control flows linearly. For example; "I expect this kind of scan, followed by a numeric input, and then this next kind of scan". A person is not simply tabbing through the screen filling things out in whatever order they want and pressing a done button (although, they certainly could do this). Really, I am trying walk multiple people through a fairly complex sequence of actions they need to take in the real world, and track in the App. (Imagine a warehouse process for putting an item into inventory... "Scan item, how many? Take item, place item on cart. Scan cart. Cart full? Take cart, scan cart, go to shelf, put item on shelf, scan shelf, how many?" There may be 2-3 people involved with this operation, each person has a specific responsibility, like an assembly line). After scans there is usually some sort of server request or in-memory lookup operation happening. Same goes for OnAppearing on many pages, where I need to fetch the current data from the database.

Originally, in Xamarin Forms, I was using the NavigationStack to deal with this. Pushing pages on and Popping off was easy enough, so I designed pages to be fairly simplistic and utilize the stack to get around. Generally, I'd have a landing page with a single entry text box, when a value in there was submitted, I did a server call, then created an instance of a new page, and a view model, and then pushed that page onto the Nav Stack. If that page had to return data to me later, I would have remembered the new view model somehow and checked it when the originating view was shown again.

[mphill]

Personally I’d avoid the string based routing AppShell. Why give up compile time type checking? We started to use it and dropped it, it felt unnatural. It’s also riddled with issues that have been open for years.

You can use Shell.Current to access navigation and push/pop on the MainPage from the stack just like with NavigationPages. In fact you’ll find the NavigationPage you’re used to is there, AppShell is a wrapper. That way you can pass on object into the page/vm just like you did originally.

For Inter viewmodel communication you’re likely going to want to use the weak reference manager. Check out the MVVM Community Toolkit.

If you’re considering a large refactor though I’d look at React Native or even flutter. MAUI isn’t production grade and likely won’t be for a while.

Expo for React Native is insanely productive and has all the barcode scanning built in as well as incredible documentation and guidance on navigation. TypeScript is also insanely productive. All platforms have issues even native, but MAUI in its current state is in a league of its own. I haven’t been able to do release builds on a Mac for over two months.

Maybe spend the weekend and setup Expo + NativeBase. See if it might be a good fit. At a minimum you see what hot reload looks like that works.

Good luck.

[shadowfoxish]

Thanks for taking the time to respond. I appreciate it.

I really like the flyout approach for the app, but yeah, I chose to avoid the string based parameter passing. I think it could work if I refactor the app to have more of an internally consistent data layer that sits at a level below all the viewmodel logic, and the viewmodels would just pull information from that by key, rather than getting instances of business objects themselves and passing them around.

To that end, I've (almost) completed switching to AppShell navigation using the ApplyQueryAttributes style, and using the object dictionary to move data between screens. Its been goodbad. Its good in that I've been able to reduce a lot of boiler plate code, and there's a better separation of my viewmodels now not needing to have an "Appearing" method called by the views. The URI routing also makes supporting multiple tasks at once possible. Its bad because I lost some type safety, passing objects around rather than concretions, but there are ways to ease that pain.

Spicy opinions here, not meant as a personal attack
I'm not interested in React. We're using it elsewhere in the organization and in my opinion, its more of an intellectual curiosity than a "make a production software app with this". State management and redraw performance tuning, coupled with the asynchronous/functional nature of it just makes everyone who touches it have to be a PhD computer scientist or whatever. Package management is awful. Its too hard to hire people for and heaven help you if you want to upgrade everything to latest and greatest after a year. What I will say about Microsoft is, they do definitely try to keep backwards compatibility and not just arbitrarily change APIs on you. I chose to change some stuff around with my App using Maui so the pain of that refactor is on me. I guess, my main problem with React and sort of JS based applications is I don't have the resources/time to hire or learn all the ins and outs of that stack to do what honestly Microsoft makes "push button". Webpack, electron, nodejs, all the app packagers... its hell of an ecosystem. Javascript just needs to go die in a fire. What a mess.

[plppp2001]

Which tool did you use to create that MAUI architecture diagram?

[shadowfoxish]

Visio

[plppp2001]

Thanks. Looks good.