Dealing with messaging center

I am getting near to having a version 1 of my app but I have just noticed a big issue when testing to do with Messaging Center. At the moment if lets say I want to add a user to a company then the CompanyPage **will navigate to the **UserListPage **after subscribing and then once the user is selected then the **UserListPage **will send the user over the messaging centre back to the **CompanyPage.

Now because the app runs under a Master/Detail Navigation I had it that in the **OnDisappearing() **method of the **UserListPage ** all of the Messaging Centre subscriptions would be unsubscribed as there was a chance that the user might suddenly go to an entirely different page that is in the page list in the Master Page.

This is fine except when selecting a user you have the option to view there page or add a new one. This takes you to another page and calls the OnDisappearing() method stops the selected user being sent back to the CompanyPage.

I'm curious how other people implement Messaging Center in their apps to make sure that
1) You unsubscribe once you are done with the event, including in a scenario where the user still has the option to go to entirely irrelevant pages
2) You still have the option to go to other pages but still keep hold of the subscription as it may still be relevant.

Answers

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited November 2018

    I'm curious how other people implement Messaging Center in their apps to make sure that

    Just one voice...
    First the pages don't handle navigation in my apps. That's not their job or responsibility. A page shouldn't know or do anything about the logic and business rules and flow of the app. OnDisappering to handle business logic such as which page to go to... urrr... no. That's a total violation of the separation of responsibilities and separation of UI from logic.

    So I guess that kind of negates your questions 1 and 2. Because MessageCenter doesn't drive navigation.

    How to handle subscribe and unsubscribe - in general terms. Exactly as you would CLR events. You subscribe when you need to know about an event. And you unsubscribe when you are done caring about such an event. How that applies to your, or any other specific situation is for you to interpret.

    I would expect something more like raise a MessageCenter message such as NewUserAuthenticated<User nuUserObject>. That's it. That's the job of that log-in page: To say someone has logged in, and nothing more. Every class in your app that cares about such a thing subscribes: Probably for the duration of your app lifespan.

    Then the Viewmodel or manager class that cares about such things, and manages the behavior of the app can do its job, taking the user to where ever they should go. Every class has one small area of responsibility. Not Login AND navigate.

  • RicardoJarreeRicardoJarree USMember ✭✭

    See this confuses me as I have read threads and guides in the past that state if you want to pass an object to a previous page/viewmodel then you should use the MessagingCenter to send that object back. Meaning that you need to subscribe before you go to the next page.

    If the company view model is responsible for adding an user to the company how do I pass the user to the company view model once the user has been selected. I use one UserListPage and all the objects that might need to select a user will call that view model with isSelecting=true in the constructor. If isSelecting=true is in the constructor then the user page will send whatever user is selected to the previous page/viewmodel and then that viewmodel can decide what to do with the user, whether it's adding it to a company/group/anything.

    The question is how to I pass the user back to the previous viewmodel/page(if not using MVVM) if I don't use MessagingCenter? I know that I could just use the CompanyService in the UserViewModel but I would end up duplicating similar code again and again.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    I have read threads and guides in the past that state if you want to pass an object to a previous page/viewmodel then you should use the MessagingCenter

    Yep. All good there. Using MessageCenter to pass information is a good practice.

    Meaning that you need to subscribe before you go to the next page.

    Getting a little bit more merky... Because what you need to do is totally dependent on your app design. But in a vague general concept:Yes. You have to subscribe to a message before it is sent if you want to hear it. Whether that is a page or a viewmodel is beside the point; they are all really just classes. So the class that is going to listen has to subscribe in order to hear the sender.

    If the company view model is responsible for adding an user to the company how do I pass the user to the company view model once the user has been selected.

    I have no insight to your app design/architecture or what classes are doing what... how you are "adding" and so on. So no way for someone on the outside to tell you what to do. I can take some guesses about how I might approach the project, but 10 developers will take 10 different but probably equally right approaches.

    I would expect that the Company object is jsut that, an object not an entire view model. And that it has an ObservableCollection<User> as a property. So to add a User you just add it to the collection. Maybe you do that from an AddNewEmployeePage. Maybe the Company instance is static and global-scope since it will be used from everywhere in your app. Or maybe you have a CoreViewModel with a Company property on it and the CoreViewModel is all the core objects that are shared across most of the app. That's fairly common and helps facilitate binding.

    (if not using MVVM)

    Oh... You keep saying ViewModel in your posts... but you're not building along MVVM pattern? Good luck with that. What would you not be building to MVVM pattern in any year after 2001? That's not me being a jerk. I'm genuinely curious why anyone working in a 2018 XAML-based eco-system like WPF or Xamarin would choose to not use the expected MVVM design the entire system was developed around.

    if I don't use MessagingCenter

    Nobody said Don't use MessageingCenter. I guess in an effort to not be construed as mean I was too subtle. Something that is rare for me. More directly put what I said was Your navigation system where one page directly calls another page is a hot mess that nobody I've ever worked for would find acceptable. Its your approach to the navigation, not the use of MessagingCenter that I was saying was a problem.

Sign In or Register to comment.