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
|
|
|
Show Posts
|
Pages: [1] 2
|
1
|
PureMVC Manifold / Demos and Utils / Re: Simple RSS reader - demo for using PureMVC Objective-C on iPhone / iPhone touch
|
on: February 08, 2009, 11:03:02
|
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
|
|
|
3
|
PureMVC Manifold / MultiCore Version / Re: Pipes Utility - Disconnecting Pipes
|
on: June 22, 2008, 09:09:37
|
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
|
|
|
5
|
PureMVC Manifold / MultiCore Version / Re: Pipes Utility - Disconnecting Pipes
|
on: June 22, 2008, 01:21:39
|
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
|
|
|
7
|
Announcements and General Discussion / Architecture / Re: Remote proxy result/fault notifications and related commands
|
on: March 22, 2008, 06:49:59
|
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
|
|
|
8
|
Announcements and General Discussion / Architecture / Re: VOs and data object in Proxy
|
on: March 09, 2008, 02:23:55
|
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
|
|
|
9
|
Announcements and General Discussion / Architecture / Re: destroy/cleanup mediator before removal
|
on: January 19, 2008, 01:01:36
|
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
|
|
|
13
|
Announcements and General Discussion / Public Demos, Tools and Applications / Re: Login Sample using Flex, WebORB and PureMVC
|
on: January 05, 2008, 09:17:48
|
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
|
|
|
|
|
|