Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Notifications in multicore?  (Read 10667 times)
jlahr
Jr. Member
**
Posts: 19


View Profile Email
« on: January 06, 2010, 10:55:38 »

Can notifications be sent between cores in MultiCore?

For example: LoginProxy in CoreA sends a notification LOGIN_SUCCESSFUL to a mediator in CoreB which in turn loads CoreC... etc.

Thanks.
Logged
mariusht
Full Member
***
Posts: 26


View Profile Email
« Reply #1 on: January 06, 2010, 11:30:11 »

No, Don't do that. You would send a Message if you are using Pipes utility in your app.

Mariush T.
http://mariusht.com/blog/
Logged
jlahr
Jr. Member
**
Posts: 19


View Profile Email
« Reply #2 on: January 06, 2010, 12:14:45 »

Thanks Mariush,

Is there an alternative that doesn't rely on Pipes or interfaces?

In regards to Pipes:

This is my first PureMVC project and it's been difficult enough getting multicore set up properly. Pipes sounds really cool but I'd like to avoid the added complexity until maybe the next project.

In regards to interfaces:

I see that you can write an interface in one core that can be accessed by another core. But, to me, that seems like strong coupling.

To use the above example, I feel that if LoginProxy were to interact with CoreB's mediator by calling CoreBMediator.loginSuccessfull(true) would mean that LoginProxy would have to know about CoreB's mediator or any other interested mediator elsewhere.

There must be a misunderstanding I'm having here but I keep looking at Modularity for answers and it's just hasn't clicked yet.

Thanks again!
Logged
mariusht
Full Member
***
Posts: 26


View Profile Email
« Reply #3 on: January 06, 2010, 01:30:12 »

You have to use either Pipes or Interfaces in your multicore application.

To use the above example, I feel that if LoginProxy were to interact with CoreB's mediator by calling CoreBMediator.loginSuccessfull(true) would mean that LoginProxy would have to know about CoreB's mediator or any other interested mediator elsewhere.

Proxies DO NOT interact with Mediators or Commands. Proxies send notifications. Mediators listen for these notifications.

Look at the diagram i made: http://mariusht.com/blog/2009/05/28/puremvc-actors-and-their-responsibilities/

Mariush T.
http://mariusht.com/blog/
Logged
jlahr
Jr. Member
**
Posts: 19


View Profile Email
« Reply #4 on: January 06, 2010, 02:07:08 »

Proxies send notifications. But notifications can't be broadcasts across cores...

So the Proxy sends a notification to an interested mediator in its own core which in turn controls a mediator in a different core via the second mediator's interface methods?
Logged
philipSe
Sr. Member
****
Posts: 139


View Profile Email
« Reply #5 on: January 07, 2010, 04:29:18 »

@jlahr
You might be interested in this discussion
http://forums.puremvc.org/index.php?topic=1188.0
----Philip
Logged
jlahr
Jr. Member
**
Posts: 19


View Profile Email
« Reply #6 on: January 07, 2010, 09:02:12 »

Thanks Philip.

I had a similar idea about similar to Justin's broadcast function which would pass notifications between modules.

Obviously Cliff defends the use of Pipes because when you have independent modules/teams you have less control what notification names people use.

Personally I want to avoid Pipes because I think the strict modularity it provides is overkill for the scope of the project and I don't have enough time budgeted to fully implement and understand it.

Good information though...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: January 08, 2010, 10:47:02 »

Actually, there is a loose and fast method that doesn't truly use interfaces (other than those implemented by Flex itself) or pipes.

That is to simply write your modules/cores as if they were custom view components to be inserted into the natural view hierarchy. A shell might instantiate these cores in MXML like you would any other view component.

In the Modularity Demo, there are interfaces defined for communication, but you can even toss that out the window and just have the modules send events that bubble up through the view hierarchy to a module or shell above them.

I actually have a very large project I'm working on at the moment that successfully uses this methodology.

There is one big caveat though: Reclaiming memory is virtually impossible.

If the shell creates all the child modules and binds listeners to them, then there is a lot of work to undo them. For instance, if you need to log out and then have all the modules be destroyed and replaced with fresh ones, the profiler shows you'll always be piling up instances. In the end it just isn't possible to do a complete Indiana Jones-style 'bag of sand for gold idol swaparoo'. The big ball will always roll down the tunnel and crush you to a pulp.

The workaound of course is to simply refresh the browser. I understand they're supposed to be deploying a Flash 10 version that can globally remove all listeners, which might be a fix.

The other downside to this is that it's difficult to get lateral communications between modules. If the Shell has instantiated modules A, B and C into its view hierarchy, it can listen for events and invoke methods on the children (you really should use interfaces to define those methods, but you don't have to) but it's difficult for Module A to hear something Module B has to say unless the Shell relays it. That makes the Shell have to do a lot of binding and scattered communications mediation that in the end would be as complicated as the piping you'd set up between the modules to allow them to communicate between themselves.

Also, in the app I'm working on, the child modules are all in a view stack, so that they aren't instantiated unless navigated to. This really makes it virtually impossible for one module to rely on being able to have any communication at all with another one. They are islands unto themselves.

So it works for a simple architecture where the modules don't have to cross communicate and where you don't mind if they browser has to be refreshed to reclaim memory.

Therefore the 'party line' on this has to remain Pipes or Interfaces. I can't really advocate the view component methodology yet, as I just haven't been able to overcome all the problems with it to my satisfaction. The app I'm working on is very sound, but the sheer amount of disconnect and destroy code that was necessary to get it to operate across several logins without refresh leaves me wishing I'd used pipes to start. I basically didn't want to leave a more complicated legacy than need be for the team, but in the end, pipes would've been a better answer.

-=Cliff>
Logged
Pages: [1]
Print