I have some Event Subscribed in SoftwareViewModel Constuctor and i am somehow thinking to MOVE that particular view and Viewmodel in seperate MODULE and make it ondemand
but in order to make event publishing and subsciption working we need to load that SoftwareViewModel when application loads i.e. in order to make subsciption of SoftwareViewMOdel working.
So how Event publishing & subsciption work in ONDEMAND Viewmodel concept.
Is it doable what i am thinking or not because behaviour of SoftwareViewModel is dependent on settings that load when we do login in application.
**//Want to make this viewmodel ON DEMAND**
public SoftwareViewModel()
{
**//Event that is going to subscribed**
SubscriptionToken subscriptionValidate = this.eventAggregator.GetEvent<PubSubEvent<IValidate>>().Subscribe(i =>
{
//CODE HERE
});
}
Regarding On Demand some explanation: On Demand i means to day that i have two tabs 1 & 2. I want my tab-2 things should load when i click on tab 2 i.e. SoftwareViewModel OnDemand.
But My Tab -1 has some settings that put effect on SoftwareViewModel i.e. tab-2.In order to do this i am using event subscription and publishing to share data bewteeen tab 1 & 2.
But i want to do everything on click of tab-2.
Question: Is it possible to make SoftwareViewModel i.e tab-2 on demand with event publsihing and sbscription beacause according to my study publishing only works when subscription registered first.
Please let me know if more description required.
答案 0 :(得分:0)
Your understanding is correct; a subscription in a typical pub/sub application will only receive events published after the subscription is established.
To make it clearer, lets start with a second use case. That tab-2
is entered first. tab-1
doesn't ever get created. How do you get the data then? Not only was tab-2
not subscribed at the right time, the event it was looking for was never published!
Moreover, in a third case, say tab-1
was actually a different process. tab-2
is probably interested in events that occurred before it's process even started!
The solution is the same for all use cases; the view (model) (tab-2
here) must be able to query for the current state of the system. "Fetch, and subscribe for the rest." The query and response could be through your pub/sub system (having built that, its a fair bit of work) or could be through some other method.
TL;DR: You can't rely on just simple pub/sub for your initial data.