unlist notification interest in mediator?

[pebanfield]

Is there a best practice way to remove a notification interest from a mediator? I'm using a flag in handleNotification at the moment... LAME! Got to be a better way than this? Thanks!

Peter

[puremvc]

Haven't really thought about it. Its sort of assumed that the mediator's interests don't vary. What is the scenario?

-=Cliff>

[pebanfield]

Hi Cliff -

In my case I've divided my application logic into two primary mediators - ApplicationMediator and CanvasMediator. The ApplicationMediator handles start up, security, configuration, etc. It also instantiates the CanvasMediator and manages loading module based views into it. At some point I intend to refactor some of this logic into additional mediators that are coupled with each module view class, but for now the views have no mediators. I suppose CanvasMediator is a sort of shell class only it also serves as a layout manager.

This particular application utilizes data feeds that are housed in an RSS based schema called Media RSS. A PlaylistProxy class manages the loading and memory cache retrieval of playlist collections from another proxy that manages multiple playlists and a few other bits of application state data.

In most cases playlists are loaded at the CanvasMediator level, but due to the flow of my application execution it is practical to handle the first loaded default playlist logic at the ApplicationMediator level. But, once the application has been initialized I no longer want to listen for playlist command events here.

One option for me is to refactor my application such that all playlist loaded events are handled at either the CanvasMediator or ApplicationMediator level, but not both. This would eliminate the need for a flag in the ApplicationMediator. At this point I can't justify doing this as it means changing a lot of code and the flag is working just fine.

In summary, I can't say that my application architecture is perfect except for the lack of the ability to remove notification interests in mediators. I'm sure I could work around this in a better way. But on the other hand it seems like the framework might be more complete with this facility?  The ability to attach and detach observers or add or remove listeners comes to mind, but perhaps the notifications in Pure MVC are not parallel concepts. Thanks.

Peter

[Joel Hooks]

Why don't you send a notification out at the time when the AppMediator no longer needs to listen for a notification that turns a boolean switch on AppMediator? Then you test against this switch in the notification handler and return out if it is appropriate to do so.

if(!listenForThisNotification)
    return;

[puremvc]

I understand the situation of not having time to refactor, but the logic sounds a little confusing to me. It doesn't sound like a compelling argument for dynamic notification interests.

Such functionality could be added by subclassing View and adding a method that a mediator could call that would allow it to have an interest removed. But one thing I can tell you before you dive into it is be careful with those observer lists, they can be tricky. I think at least 80% of the bug fixes that happened on the road to stability were related to manipulation of observer lists.

-=Cliff>

[pebanfield]

Thanks for the feedback guys. I am already using a boolean flag without problems.  In my particular case I can simply set the flag directly in my mediator without the need to send a notification, but I think this idea could be useful in certain circumstances. This just feels a little awkward since the unnecessary interest is still there.

For this reason could this possibly lead to memory issues? Perhaps in a game or some application where many notifications are sent? I suppose one solution would be design mediators with this in mind and to remove them altogether instead of unlisting specific interests. This approach would leave you with both short term and long term mediators. Still, it would be nice to have a way to remove them so I'll double back and follow up on your subclassing solution at some point. Thanks.

Peter

[puremvc]

You've hit the nail on the head. 'Short term and long term' mediators are generally the way it works. Under ordinary practice, I haven't ran into the need for a mediator to 'lose some of its interests', but there are certainly times when a mediator is no longer needed and is removed.

Usually as long as a mediator's view component is alive the same interests exist.

Now that view component may itself choose to ignore data passed to it or to behave differently based on its own encapsulated state, and with Flex States, top level properties might dissappear or reappear depending on its internal state changes. This is in line with the GoF State pattern which says that the component will appear to become a different class.

So in this case, one might argue for dynamic manipulation of mediator interests. But I would always vote for less complexity in the framework. Since the viewComponent has for all intents and purposes become a different class, I argue for a different mediator.

View component VC has States A and B. While in State A, ViewStateAMediator holds the reference to the component. On a VC state change (the mediator is listening for this), ViewStateAMediator unregisters itself and registers ViewStateBMediator passing the reference to the VC. Afterward, it nulls its own reference, and dissapears quietly having passed the torch. Of course ViewStateBMediator mirrors this so that as VC passes between states, it is always tended by the proper mediator.
   
Its like in school, when its time to learn history, we're tended by the history teacher. When its time to learn math, we're tended by the math teacher. Except on those days when the math teacher is sick and inexplicably the basketball coach is put in charge... Polyester gym shorts and polynomials don't mix folks.

[pebanfield]

Ha! Fortunately for me the PE teacher subbed History, but for an entire term - and he wore the same track suit every day! (Not so fortunate) Mr. Putnam - the Sex Ed teacher was also a PE teacher and he kept his removed cancerous testicle in formaldehyde in a jar on his desk. I'm am not making this up. They called him "one nut put". 

Yes it seems to be the natural order that simplicity in one area leads to complexity in others. I think it's good to keep it simple on the architectural framework side at the expense of complexity in the application. On the other hand - it's just one little method. Tempting no?

I'm not actually using much of the Flex framework on my current project. Just a few classes here and there, but not the UI stuff. I've implemented a classic state machine much like the one you describe that passes control around via a context class or state interface methods. The current Pure MVC sample seems to be a bit different from what I can tell - more reliant on data binding. Then there is also the official Flex states and transitions which I tried, but found too proprietary and a bit awkward. The advantage of sticking with AS3 is that I can easily work with C# examples or pair with Java developers.

One thing that I often struggle with is the decision of when to create a new state and when to simply use a state flag. It seems that there are pros and cons here - with preparing a state architecture to scale well on one side and class bloating on the other. My current MO is to let a few flags creep in until it starts to smell bad and then refactor with new states. This works OK as long a I'm not lazy and let it go too far - kind of like doing the laundry or going to the gym.

It sounds like your design doesn't give you the flexibility to slack off - which may not be a bad thing. Thanks.

Peter

[puremvc]

Unfortuately I haven't the time to do another demo of the StateMachine at the moment as I am buried in work, but I can say a few things about the it and the new changes. First, it does not rely on binding, although the StopWatch demo does use it in a contained way in the view components (as do most of the Flex/AIR demos). Second there end up being far less reliance on the entering/exiting notes, its 'changed' that triggers state specific goodness once the machine has reached the new state. And the need to stash flags or temporary data for the next state to go pick up is reduced by the ability to tunnel data to the new state via the ACTION note. And states can now re-enter themselves. Definitely worth a look if you're struggling with state, I can tell you. I've got a nice chunky app purring along like a kitten thanks to it now and can't imagine starting another project without it.

-=Cliff>

[Joel Hooks]

Unfortuately I haven't the time to do another demo of the StateMachine at the moment as I am buried in work, but I can say a few things about the it and the new changes. First, it does not rely on binding, although the StopWatch demo does use it in a contained way in the view components (as do most of the Flex/AIR demos). Second there end up being far less reliance on the entering/exiting notes, its 'changed' that triggers state specific goodness once the machine has reached the new state. And the need to stash flags or temporary data for the next state to go pick up is reduced by the ability to tunnel data to the new state via the ACTION note. And states can now re-enter themselves. Definitely worth a look if you're struggling with state, I can tell you. I've got a nice chunky app purring along like a kitten thanks to it now and can't imagine starting another project without it.

-=Cliff>

I'm working it into my next project. Really looking forward to it based on your recent enthusiasm :>

[pebanfield]

Ya me too - I'm looking forward to it. Thanks Cliff.

Peter