Proposed changes to the mobile app

[matt-goldman]

Introduction

I've been looking primarily at the mobile app for a few weeks now (unfortunately due to a family emergency and some work pressures I haven't made as much progress as I had hoped to by now). I've identified a few things that I think we could address, especially in light of the upcoming .NET 8 release.

There are (at time of writing) 25 open issues related to the mobile app. Some of these date back more than 2 years; the app was originally built using .NET 6, which was an early version that had a number of problems. The team were able to work around these and create a working build of the app.

I have begun looking into these issues, beginning with authentication on iOS (as mentioned by @joebeernink as being the most important). However, given that .NET 8 now has an RC and GA is imminent, I would like to propose some changes to the app that will enable us to leverage the full capabilities of .NET MAUI and consequently simply irradicate most of these issues, rather than invest the time and effort into fixing them.

Authentication

Only partially related to .NET 6 (MSAL wasn't available for .NET MAUI at launch). There are a couple of changes I would like to introduce to simplify the authentication logic.

1. Single redirect URL

While the Microsoft documentation and samples demonstrate using the client ID as part of the redirect URL scheme, this is not optimal for several reasons. First, it means that you need to use a different redirect URL scheme across different client app registrations. Second, it couples your app's redirect URI to an authentication provider. Say for instance, you want to add deep-linking to the app, you would need to register a different scheme.

I suggest using eco.trashmob.trashmobmobileapp://auth as the redirect URI across all app registrations. This will simplify the code and the builds, and also enables eco.trashmob.trashmobmobileapp:// to be used in the future for anything else. While this approach may not always be the best fit, it opens up possibilities for future enhancements.

2. Consider single tenant

I wasn't privy to the decision to create two B2C tenants (one for prod and one for dev) so I'm not sure what the logic was. But I think it's worth considering whether 2 are necessary. Separate app registrations should be more than adequate and reduce the overhead of maintaining two separate tenants.

UI

.NET MAUI initially released with .NET 6 and was not as mature as it is now. There is an opportunity to leverage the more stable and mature version in .NET 8 to reduce the complexity of the mobile app.

1. Switch to .NET MAUI UI

TrashMob uses Blazor MAUI hybrid for the UI which circumvents problems that were present in .NET 6. However, given that .NET 8 is imminent and most of the issues are resolved, it makes sense to reconsider this approach. Using MAUI Blazor hybrid makes a lot of sense when you have a Blazor web UI in the stack; however, in TrashMob the web UI is built in React. So not only do we not gain the benefit of sharing UI via a RCL, we also have multiple skillsets required to maintain the stack (.NET for the backend, .NET MAUI for the mobile app, Blazor also for the mobile app, React for the web UI). While the diverse skillsets have contributed to the app's development, streamlining them could simplify maintenance and enhance the app's capabilities.

2. Refactor state

The app is logically built like a Blazor app. This effectively turns .NET MAUI into a webview container. For example, UI pages and components largely handle their own logic and state, with some state containers used for shared state.

We should consider a more appropriate paradigm for the app. Specifically, we should either refactor based on the MVVM pattern, or go with a full reactive paradigm like MVU (note that we can still borrow parts of the reactive approach in MVVM). This will simplify maintenance of the code and allow new developers coming on board to easily identify where code changes need to be made.

Note that all the service layer logic can be retained (this effectively slots into the 'M' in MVVM). It can still be refactored later if necessary, but with the suggested changes we get to leverage the investment already made and reuse almost the entire logical portion of the app.

Code sharing and solution architecture

Currently there is a .NET API and a .NET UI, and they are sharing some code. But I think this can be improved.

1. Remove symlinks

Within the solution there is a Models project. This contains some entities (which are also used as DTOs). This is symlinked into the mobile app.

There is also a Shared project, which contains application logic.

By moving types used by both the UI and the API into a shared project, we can create a more cohesive and maintainable structure.

2. Consider using DTOs

At the moment, entities are shared between the UI and the API and are transmitted over the wire. I won't go into that discussion here (happy to if anyone wants) but we should consider decoupling the UI by using DTOs instead of entities. This is also what would then be moved to the shared project.

3. Consider a well-defined architecture

Looking at the whole solution, it's pretty well organized, and I think it can be enhanced by being refactored to fit a well-defined software architecture. I think any architecture is worthwhile considering (happy to get into a VSA vs CA debate 🙂) but I think the choice of architecture is far less important than the decision to pick an architecture. The benefits of adhering to a well-defined architecture far outweigh the benefits of any specific architecture itself.

---

These are just some of my observations and suggestions from looking at the code. Hopefully they are valuable and I would love to hear what others think.

[joebeernink]

Love the detail here, Matt. Thanks for putting this together.

A couple of notes for historical purposes.

1. The reason for the two AD B2C tenants was that we originally built the website using User Flows with email only sign in. When we decided to convert to IEF to include other auth providers, we spun up the dev tenant so we could work in isolation without breaking prod (which was already an active site at that point). I have no concerns about reducing the number of tenants now. Also note that the back end runs in a different AAD tenant all-together. Not a big deal, but does add to the management complexity.

2. The Models are (at least in my mind) POCO. All of the persistence logic is in a separate lib that is not included in the mobile app. That said, my concern about the DTOs is strictly a maintenance aspect... double the code to maintain... unless you have a better pattern in mind.

3. I'm not stuck on Bootstrap, but I wouldn't say a goal of this project would be to make it easier to share code between the web site and the mobile app. The audience for the mobile app is considerably smaller than for the web site, and there will always different capabilities between the website and the app. I would say code-sharing would not be a priority. However, I do see the value in having fewer stacks for developers to know, and when it comes to styling, css files, and assets, this is especially true.

For everything else, I'm totally open to whatever works and makes things as easy to maintain, and add features to, as possible.

[joebeernink]

I remembered another reason why we have 2 different tenants. Because we have a dev site and a prod site, and both support adding users, we needed to test the add / update / remove user functionality and to be able set up users in the test environment. If we delete the dev tenant, I don't know how we'll get new users into the dev database or test updates to the signup flow. Since production is an active environment with real users and metrics, we can't use it to create test events or notifications without affecting the public, so testing must be done end to end in test, including the Test AD B2C Tenant.

[xthepoet]

TL;DR @matt-goldman wow, thank you for the in-depth analysis and great advice there! I'd personally trust your expertise and think if someone with your experience and familiarity can help us migrate the application to .NET 8 and put in place your recommended architecture, it'd really set things up foundation-ally well for future add-on work.

Upgrade to .NET 8
High level advice of just re-building with the latest .NET 8 makes sense. The old version wasted SOO much time with hacky work-arounds, would be much better to have less pain moving forward with your recommended re-architecting on the new framework. Joe & and I had been debating this in the past, where we were somewhat regretful we hadn't chosen a more mature framework (but it seemed to us at the time that the effort would be too great to shift), but it sounds .NET 8 is both more mature and something you think you would be able to help us transition to.

Switch to MAUI UI
Secondly, the any other UI sounds great! The current interaction flow doesn't feel quite "right" in our current implementation, and the UI renders/behaves differently in Android vs iOS even for something as "basic" as forms. Am hoping the switch helps solve the issue (or perhaps just having an expert that knows how to make them consistent).

Auth / B2C debate
From the sounds of your description, it sounds like there's another flow you've tried before for AD to separate dev & prod flows through different application registrations. Might also help with our gitflow vs using Debug/Release as the switch between dev & prod builds (esp since the optimizations are different, so it's hard to do configuration testing via CI/CD the way it's currently set up).

Sounds fine to me personally to just set it up your proposed single-tenanted way and test it. If it doesn't work, we can always revert back to a B2C approach.

Next Steps
@matt-goldman how do you recommend taking this forward? Do you think it's clear enough for you in your mind to start actioning it or to do a POC?

[matt-goldman]

Thanks for the feedback. I think based on @joebeernink 's (very valid) reasoning about testing adding and removal of users, it makes sense to keep a separate dev tenant. In terms of moving forward, I think the key is to break this down into manageable chunks. Perhaps as a first step yeah a POC that just validates that auth works across both iOS and Android is a good start. I can get started with that. But then the rebuild is going to be a bit more tricky (for me) as I don't have the depth of understanding of the product that those of you who worked on the original do. What would really help me would be a visual, UX, or interaction design, and/or a product backlog.

But for now I'll get started on the auth POC.