Which Commands exactly should tell the Facade to register my Proxies (should I go "all-in-one" in my StartShellCommand), and how should I tell my WebServiceProxy that the address is available and it can start to connect?
So, you're building a multicore app, I don't know how your cores are split up, so it is difficult to say exactly how you would get the config information to the WebServiceProxy. Is it in a separate core or the same core that is loading the configuration. If it is in the same core then you may be able to follow the approach you mentioned about making one proxy available to the other (see my comment on the next quote). And as for the 'all-in-one' startup command as opposed to separate model and view startup commands in a macrocommand, it's up to you. If you reuse your model packaged between applications then it can be nice to go with the latter approach because you can supply the model registrations in a shared command in a separate library with the model classes.
My idea would be that the preloader dispatches a READY notification, registered in the Facade so the WebServiceCommand tells the WebServiceProxy to retrieveProxy(PreloaderProxy), so it can get the address from it? Is it ok?
It's perfectly fine to load the configuration into one proxy and make that proxy available to another proxy.
From this similar post: http://forums.puremvc.org/index.php?topic=2036.msg9091#msg9091
If one proxy is dependent upon another proxy, just define the first proxy to take the second one as a required constructor argument. In the constructor of that first proxy, store the reference to the second one in a protected property.
It seems like a lot of communication between classes, but is it the way it is supposed to work?
PureMVC and OOP in general don't necessarily advocate 'more communication' just for the sake of doing it. Less is better, but never at the expense of maintaining proper roles and commensurate responsibilities for task at hand. Reusability of elements only comes when we loosely couple them to the other elements in an application.
If you consider a complexity gradient spanning a range from one huge class doing everything
to a ridiculous amount of classes for every conceivable unique computation in the app
, the sweet spot for any given use case lies somewhere in between. Your job is to find that sweet spot as often as possible, because almost all of your work in PureMVC is building use-cases traversing from the model to the view and back, sometimes going through the controller region, but not always.
Once you set up a use case (such as this process of getting the configuration loaded and available another Proxy subclass), you can consider the actors involved and decide if you could do it in fewer while retaining the best practice responsibilities of the actors involved. You rarely need to create anything more than commands, proxys, mediators, view components, and data holding classes. The paths between the model, view, and controller are clear and fixed.
For instance if you have a view component sending an event to a mediator which sends a note to a command which invokes a service, there is nothing wrong with that. But if all the command really does is make the service call with the possible data from the view component, then the mediator could just as well make the call directly on the proxy - it is a valid collaboration. So you could chop out an actor, i.e., the command, in this case.
So plumb things and if they work, you don't need to worry that they may not be optimum, just that the collaboration patterns are sound with respect to the best practices (usually easy to find in the docs and forum), you can optimize later. Perhaps another use case will come along and you'll realize that if you refactored an existing one a bit, the new one would be easier to write and you could avoid duplication in the codebase. You never know what that new use case will be, so best not to spend a lot of time early on making provisions for features that aren't spec'd. That's always a danger with developers, myself included - at the front of the line even, that once we've done enough of it we tend to work like chess playing robots with deep look ahead turned on by default.