Hi Cliff,

"trolling over the Reeperbahn" - I can't forget it

I would love to check in all the source of the iPhone app and the HelloPipes demo. Folder structure is already prepared, please open the repo for both demos.

I will send you some screen shots of the iPhone app. From the simulator only, because I haven't got an iPhone, only a iPod touch. So I'm already a big fan of "Developing an iPhone app without an iPhone".

Best,
Jens

First of all: Thanks Brian for your great work - the Objective-C port is awesome!

Here is a another demo called "Simple RSS reader" (incl. source code): Simple RSS reader for iPhone using PureMVC Standard for Objective-C.

-Jens

Cliff, thanks for the tip!

I refactored the source using

:

junction.removePipe( PipeAwareModuleConstants.MODULE_TO_SHELL_PIPE );
junction.removePipe( PipeAwareModuleConstants.SHELL_TO_MODULE_PIPE );to remove both unneeded pipes.

Last question: When a pipe is removed as you described, is there a need to remove any PipeListener as well?

-Jens

HelloPipes is a simple application which loads and unloads a module for communicating with its shell using Pipes Utility. Module and shell are acting as a Core based on PureMVC MultiCore AS3. You will find there some tips using Modules, PureMVC MultiCore AS3 and Pipe Utility as well.

- Live Demo
- Download full source (search for "Full source" within blog post)

Any feedback are welcome!

-Jens

Cliff, thanks for the detailed information I needed!

However, I believe that removing the references to both ends of the pipe will suffice for the entire pipeline to be GC'd because there are no outside references to these objects.

Ok, that's what I did. I removed only references of both ends of each pipe:

SHELL_TO_MODULE_PIPE:
- Shell disconnects its end (TeeSplit)

:

var shellOutPipe: TeeSplit = junction.retrievePipe( PipeAwareModuleConstants.SHELL_TO_MODULE_PIPE ) as TeeSplit;
shellOutPipe.disconnect();
MODULE_TO_SHELL_PIPE:
- Module disconnects its end (Pipe)

:

var moduleOutPipe: Pipe = junction.retrievePipe( PipeAwareModuleConstants.MODULE_TO_SHELL_PIPE ) as Pipe;
moduleOutPipe.disconnect();
Cliff, thanks for sharing the powerful Pipes Utility!

-Jens

Run into the same issue.

With a basic example using PureMVC MultiCore AS3, Pipes Utility and modules posted on my blog  I tried to figure out, what a good way to disconnect pipes connecting by a shell and a module (which is loaded by shell) could be.

So before unloading the module the shell disconnect the SHELL_TO_MODULE_PIPE (TeeSplit) and the module disconnects the MODULE_TO_SHELL_PIPE (Pipe). When the module is loaded again, these pipes will be connected again. That works fine.

However, is there anything to do to remove the other (unused) fittings of pipes which are used by module and shell together before the module is unloaded?

Feel free to check out the code of the example mentioned above, because "real" code is worth a thousand words .

Any feedback are welcome!

-sectore

thedriver,

may I ask you what do the Commands execute retrieving Notifications from Proxy?

A Proxy or a RemoteProxy as a part of a Model sends a Notification to notify all interested Views when its data has been changed. That means all Mediators can listen to these if they are interested using its method called "listNotificationInterests" and can handle it using its function called "handleNotification". For this issues you don't need a Command and it might be a uncommon way to update a Mediator (View) from a Proxy (Model) using a Command (Controller).

If you want to manipulate other Proxies after receiving a result in your RemoteProxy it might be a way using a Command to map the Notification and to manipulate the others Proxies. But you could manipulate a Proxy from the RemoteProxy directly using "facade.retrieveProxy(AnotherProxy.NAME) as AnotherProxy;" as well if you have to solve this issue only once. One way to reduce the number of Commands.

For reducing the number of Notifications: If there a need to make a difference between Notifications for all faults? As you've already written you could use only a Notification called "ApplicationFacade.GET_DATA_FAILED" to handle all data errors. To show different error messages (e.g. using a PopUp) use the Notifications "body" object holding these messages.

For handling different results such as getting new user data or updating user data I would use different Notifications as well. So any interested member has the choice to listen to it or not without distinguishing the result.

@Cliff: As I see, you've already answered. Sorry, my post in English needed some time

-sectore

It might be helpful to use VOs dealing data in your app. So a Mediator can use a VO, e.g. UserVO, to populate its ViewComponent retrieving the Proxy. And the ViewComponent expects this type too.

Furthermore dealing with VOs gives you the possibility to replace your XML service with a Remote Service (e.g. AMFPHP) or anything else without changing the rest of the app. Because the getUser method in your UserProxy returns a type of UserVO and not a type of XMLList. That means the caller (a Mediator, a Command or another Proxy) will be independent of the result of your service.

Last but not least a ViewComponent can bind the VO using the [Bindable] metatag to update itself without breaking rules so long as your app is based on Flex  .

-sectore

Looking for the advice of the destroy() method using facade.removeMediator(MyMediator.NAME);?
Maybe you've founded it in the article called "10 tips for working with PureMVC" at #8:

8. Remove unused Mediators
In some cases you don’t use a Mediator and its View Components anymore. Then remove the Mediator using facade.removeMediator(MyMediator.NAME); in conjunction with a self created destroy() method to remove the ViewComponent including all listeners, timer, references, etc. for a successful garbage collection.

Anyway, an implementation like this in 2.0 would be nice. Is there a way to call such a destroy() method removing Mediator within View.as (e.g. mediatorMap[ mediatorName ].destroy() in removeMediator() ) ? So we could use facade.removeMediator(MyMediator.NAME); as before and the View.as does the job for executing Mediators destroy().

-sectore

Gradiaton,

that's a good idea - I've updated the source.
Thanks again for your feedback

-sectore

Gradiaton,

the "workflowState" is initialized executing the "ViewPrepCommand" after registering the Mediators. Please grab the latest source for this update.

-sectore

It's done

-sectore

Hey guys,

thanks for your feeback, you're absolutely right. As mentioned above, none of the Mediators should be interested in the Notification called "APP_STARTUP", because it's for registering Proxies and Mediators using the "ApplicationStartUpCommand". My reason for this was changing the workflowState within the "ApplicationProxy" at the start of the App (and my beginning with PureMVC in Juli / August last year ).

I think changing the state of the "ApplicationProxy" will be a better job for a Command than for a Mediator. I'll refactor the source and update the repository as well as the *.zip on my blog.

-sectore

French translation: "10 trucs pour développer avec PureMVC"

Thanks to Eric La Rocca for the translation into French!

-sectore

Chinese translation: "PureMVC的十个小提示".

P.S. Thanks to duzengqiang for the translation into Chinese!

-sectore