Questions about proxies

[Davan]

Hello, im starting to use pureMVC, and i come with two questions about the usage of the proxies:

1. In the "Best practices" document, it says that we should use the ApplicationFacade class to declare all the constants for the notifications names, or use an external class, but i've seen that the notifications names that are going to be send by the proxies are defined within themselves(the proxies), so, should we declare the names on ApplicationFacade/External classes, proxies or a mixture between both?

2. I'm working on a video game, and i have some data, like score, shipSpeed, lives, etc. I have a VO called GameDataVO, that holds this data and provides public setters and getters for maniputing it. I did a proxy that provides the same setters and getters, and i want to send notifications from the proxy whenever the data changes. Now, my question is, should i send a diferent notification for each property changed? i mean, something like SCORE_CHANGED, LIVES_CHANGED, SHIP_SPEED_CHANGED and pass as the body each piece of data? or should i send a general notification GAME_DATA_CHANGED, a VO with the data as a body, and use the type property to specify the type of data changed? or there is another better way?

Thanks in advance

David

[jpwrunyan]

1. In the "Best practices" document, it says that we should use the ApplicationFacade class to declare all the constants for the notifications names, or use an external class, but i've seen that the notifications names that are going to be send by the proxies are defined within themselves(the proxies), so, should we declare the names on ApplicationFacade/External classes, proxies or a mixture between both?

Yeah, I had the same issue you did.  All I can say is that, for me, the natural progression from the best practices document to real life application is to start declaring your Proxy notifications on the Proxies themselves.  It is just more convenient, especially to keep the model tier portable.  There are drawbacks to this approach as well (versus using, say, a common ApplicationConstants class), but in some real world situations, it is just naturally easier for the Proxies to contain their own notification constants than to try to organize them in a common location.  I believe that is why many people (including myself) do it that way.  These are not the only two options, by the way (just the two easiest!).

The short answer is: do it the way that feels best for you, whether you choose A, B, or X(!).  The deciding factors are often how many proxies you have, how many notifications they send, and when do they send them.

2. I'm working on a video game, and i have some data, like score, shipSpeed, lives, etc. I have a VO called GameDataVO, that holds this data and provides public setters and getters for maniputing it. I did a proxy that provides the same setters and getters, and i want to send notifications from the proxy whenever the data changes. Now, my question is, should i send a diferent notification for each property changed? i mean, something like SCORE_CHANGED, LIVES_CHANGED, SHIP_SPEED_CHANGED and pass as the body each piece of data? or should i send a general notification GAME_DATA_CHANGED, a VO with the data as a body, and use the type property to specify the type of data changed? or there is another better way?

It sounds to me like the second option, one notification with different types, is preferable.  But I would like to first check whether this is a question between having 5 different notifications vs 5 of the same notification with different types--all being fired simultaneously.  Because if that is the case, then I would look for a way to bundle all the changes so there is less processing.  But if, as I assume, it's just that one property or the other occasionally changes and it's a question of whether to have 5 different notification names vs one notification name with a variable type, I would, like I said, go for the second option.  Just seems more logical.

[puremvc]

i've seen that the notifications names that are going to be send by the proxies are defined within themselves(the proxies),

This is a good practice if you expect to reuse your Proxy in another application. AIR (or Apollo as it was first called) was a brand spanking new concept when PureMVC began and the best practices doc was put out. Its evolution has brought forward a clear mandate to make a more portable model, since it heightens the possibility that you will reuse your model tier. A web app will often have a companion desktop app with different use cases being executed against the same model. So with that in mind, having a Proxy define its own notification constants makes more sense because the Proxy doesn't depend on any other classes in the application to do its work.

should i send a diferent notification for each property changed? i mean, something like SCORE_CHANGED, LIVES_CHANGED, SHIP_SPEED_CHANGED and pass as the body each piece of data? or should i send a general notification GAME_DATA_CHANGED, a VO with the data as a body, and use the type property to specify the type of data changed?

I would opt for the former (SCORE_CHANGED, LIVES_CHANGED, SHIP_SPEED_CHANGED).

The reason is that different mediators may be interested in the various notes. If you make a general note (GAME_DATA_CHANGED) and subscribe everything to it then you end up over-notifying, which in a game where every machine cycle counts is just bad juju. For instance if you have a ScoreDisplayediator it probably doesn't care that the ship speed changed, but every time the speed changes, you'll end up notifying it anyway, and it'll end up evaluating the note and determining that it doesn't care about it.

On the other hand, it doesn't hurt at all for more than one actor to be subscribed to the same note. For instance both a ScoreDisplayMediator and a LevelChangeCommand might respond to SCORE_CHANGED.  The mediator just passes on the score to its display component while the command evaluates the score and determines whether to bump you to the next level (assuming levels are based on score alone).

-=Cliff>