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: Notification Stacking  (Read 12360 times)
eltanno
Port to AS2
Newbie
*
Posts: 1


View Profile Email
« 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
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 08, 2008, 12:50:01 »

Jim,

This is the expected behavior. Flash is single threaded.

-=Cliff>
Logged
goliatone
Newbie
*
Posts: 4


View Profile Email
« Reply #2 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.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 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>   
Logged
goliatone
Newbie
*
Posts: 4


View Profile Email
« Reply #4 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.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 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>
Logged
goliatone
Newbie
*
Posts: 4


View Profile Email
« Reply #6 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
Logged
Henk
Newbie
*
Posts: 8


View Profile Email
« Reply #7 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.'
Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #8 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.
Logged

island
Newbie
*
Posts: 1


View Profile WWW Email
« Reply #9 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?
Logged
philipSe
Sr. Member
****
Posts: 139


View Profile Email
« Reply #10 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
Logged
Pages: [1]
Print