PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: eltanno on March 08, 2008, 10:51:29



Title: Notification Stacking
Post by: eltanno on March 08, 2008, 10:51:29
I have seen one small bug im not sure if it is supposed to happen this way. When a notification is fired and gets consumed by say 7 listeners it will act as expected untill say listener 5 fires a second Notification. Notification 1 now stops while Notification 2 completes then the paused notification 1 starts from where it left off.

Im not sure if this is what you intend but i think it would make more sense if the notifications were kept in a stack and once  notification 1 is fully complete, then notification 2 will get fired.

Hope this makes sense,
Jim


Title: Re: Notification Stacking
Post by: puremvc on March 08, 2008, 12:50:01
Jim,

This is the expected behavior. Flash is single threaded.

-=Cliff>


Title: Re: Notification Stacking
Post by: goliatone on March 11, 2008, 05:52:33
Hi there,
I was not aware of this as a feature or that it is the expected behaviour.

Perhaps, i did missread the documentation because i dont remember any references to it.

Im in the process of learning, so ive started my first real world app. At the momment im doing the structure, and testing with mook objects and Logger. I came across some "unexpected" behaviour and this would explain it.

But i have a question about your response, thou.

This is the expected behavior. Flash is single threaded.


Does that mean that is the expected behaviour of the notification system of puremvc in Flash, and that it is different in, say, the Flex or PHP implementation, or you mean that since Flash is single threaded, thus why puremvc's notification system is too.

Also, what is the best way out of the box to ensure that  notifications cause the expected action--reaction?
With other words, i guess, what are the implications of working with a sinle thread notification system?

-------------------
sidenote:
I have to congrat. for the great work you have done!
puremvc rocks.


Title: Re: Notification Stacking
Post by: puremvc on March 11, 2008, 06:33:27
Being single threaded means all execution happens in a sequential fashion.

The Notification process is merely sequence of method calls.

The View loops through the observer list for the notification in question.As it loops it calls each observer and passes it the Notification.  The thread of execution then enters the handler on the observer, doing whatever is written there. If that handler sends a notification, then the thread of execution passes through its sendNotification method, then on to facade.sendNotification, then to the View.notify observers where the view starts looping through observers for the ne notification. When this process finishes, it returns to completing its original loop.

-=Cliff>   


Title: Re: Notification Stacking
Post by: goliatone on March 11, 2008, 07:58:57
Tnxs cliff for the fast answer.

I understand what single thread means.

I guess i did not lay down my question properly. If any given notification can be heard and handled horizontally by many different listeners, each having to react and modify the application, and at the same time ( possibly/conditionally) notifying those changes vertically, thus pausing the horizontal update and possibly "deforming" the app's state for those handling changes vertically. (sorry if it is a bit dense...)

And how does that affect commands, since commands are fired through notifications.

Does that mean that is the expected behavior of the notification system of puremvc in Flash, and that it is different in, say, the Flex or PHP implementation, or you mean that since Flash is single threaded, thus why puremvc's notification system is too.

I would still find interesting to have an answer to this.


Title: Re: Notification Stacking
Post by: puremvc on March 12, 2008, 06:03:40
If any given notification can be heard and handled horizontally by many different listeners, each having to react and modify the application, and at the same time...


That's just it, they can't do it at the same time because flash is single threaded.

Even if we employed a notification scheme that queued notifications that happen during the process on notification, we'd still be doing them sequentially just in a different order. So I've yet to see a good reason to alter causality and change the natural flow of notification.

To your other question, being an interpreted language, I'm pretty sure PHP is single threaded as well and would behave the same way. Java and C# are multithreaded and so I it is entirely possible they may act differently, but I haven't actually had time to work with those ports myself so I can't say definitively, but will post an answer here as soon as I have one.

-=Cliff>


Title: Re: Notification Stacking
Post by: goliatone on March 14, 2008, 04:59:23
tnxs Cliff for the answer,again, it was clear and concise.

I was not suggesting that pureMVC should work any other way than how it is intended to work right now.

regards,
goliatone


Title: Re: Notification Stacking
Post by: Henk on April 17, 2008, 11:14:34
If you're using Flex then there might be an easy solution for this using 'callLater'.

From the docs: 'The callLater() method queues an operation to be performed for the next screen refresh, rather than in the current update.'


Title: Re: Notification Stacking
Post by: Rhysyngsun on April 17, 2008, 11:59:48
If you're using Flex then there might be an easy solution for this using 'callLater'.

From the docs: 'The callLater() method queues an operation to be performed for the next screen refresh, rather than in the current update.'


Unfortunately, callLater is a method of UIComponent, instead of a top level function. Also, it would probably be bad practice to have a function called as a result of a UIComponent redrawing itself.


Title: Re: Notification Stacking
Post by: island on April 24, 2008, 11:07:23
I have the similar problem. I want mediators to recieve notifications in the order they were sent. I want to illustrate the issue with example of a turn-based game.
I have the GameProxy, which handles game's logic. Also there are StartRoundCommand and StartTurnCommand, registered with START_ROUND and START_TURN notifications accordingly. And there are also mediators, listening for these notifications.
When the game starts, I send START_ROUND notification, which executes StartRoundCommand, which calls startRound() method in GameProxy. In this method I sent START_TURN notification, which executes StartTurnCommand. So, mediators first recieve START_TURN notification and then START_ROUND notification. This is not what I'm expecting for. So, I have to delay GameProxy's method startRound() to achieve the correct order of notifications to be recieved by mediators. But this is very very ugly solution and I want to refactor it as soon as possible.
What will be the best solution of this problem?


Title: Re: Notification Stacking
Post by: philipSe on April 25, 2008, 03:46:43
Re game and notifications...
One thing to be aware of is that mediators can interact directly with proxies; you don't always need commands.
----Philip