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: Reset and delete a view  (Read 11687 times)
danieleUg
Courseware Beta
Full Member
***
Posts: 28


View Profile Email
« on: November 30, 2007, 06:11:26 »

Hi all,
I just finish a big project build with Flex and PureMVC, and I'm very happy but I have to optimize a bit.

The project contains about ten views in the main ViewStack, the creationPolicy of viewStage is set to auto.
With this settings the first time that the view is showed, Flex create all needed components,
When the user change view, the old view is hidden and the new showed, but the old still live.
In some cases this is a advantage, because when the user come back to the view the state of all components are the same (ie. a list selection).
But there are cases that this is not a good thing, in my scenario after that the user use a application for some time the memory usage increase, because all views are created and there is not a garbage collection.
And I need also that each time a enter in the view all components are resetted.

I just thinking how to solve this situation and I have had this ideas:

Create a component that listen the change event of ViewStack.
When the component is showed create the mediator and the view.
When the component is hidden remove the mediator and the view from the displayList

example:
<mx:ViewStack id="vwStack" left="0" top="0" right="0" bottom="0" resizeToContent="false" creationPolicy="auto">
   <viewHelper mediatorClass="myMediatorClass">
      <myRealView />
   <viewHelper>
</mx:ViewStack>

Other little advantage of this solution is that you don't need to create all views mediators inside ApplicationMediator.

Someone have other (more elegant) solutions?

Best
  Daniele
 
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: December 03, 2007, 04:25:18 »

Daniele,

This feels too invasive from the view component's standpoint. The view component could not work correctly outside a PureMVC system.

I would suggest:

Make the ViewStack a custom component with its own Mediator. (CustomStack and CustomStackMediator)

This puts the entire responsibility into the hands of the two classes closest to the problem. And it allows you better view container refactorability, as opposed to having the ViewStack be a child of the Application and letting the ApplicationMediator handle events from it.

Have the CustomStack declare separate named events for each childs creation and destruction.
In the creationComplete of each child of the CustomStack, send the appropriate event (CustomStack.CHILD2_CREATED)

The CustomStackMediator of course, has the responsibility of listening to the CustomStack component for events. In its constructor it adds an event listener to the CustomStack, mapping CustomStack.CHILD2_CREATED to onChild2Created. In the private onChild2Created method, it creates a Child2Mediator, passing it the reference to customStack.selectedItem.

Back in the CustomStack, you also want these things to be destroyed along with their Mediators when they're hidden.

Have the child send its destruction event message in its hide event handler.
In each child, you'll have something like hide="dispatchEvent(new Event(CustomStack.CHILD2_DESTROY), true)"

In the CustomStackMediator, in the onChild2Destroy method, you can call facade.removeMediator on this mediator and set customStack.child2 = null; This assumes the child component defined in customStack has an id="child2".

That should do it, although you might research if the ViewStack has a more graceful way of removing the child that will ensure all listeners it might've placed on it are removed.

-=Cliff>

Logged
danieleUg
Courseware Beta
Full Member
***
Posts: 28


View Profile Email
« Reply #2 on: December 03, 2007, 05:24:25 »

Cliff,
thanks for your suggestion, I will make a experiment for test this solution, when will be ready I will post.


Daniele
Logged
diral
Newbie
*
Posts: 1


View Profile Email
« Reply #3 on: December 07, 2007, 10:59:24 »

I build this and its running fine. Now I have a question to the NotificationInterests of the customStack ChildMediator. I've created this Mediator within the CustomStackMediator:
:
private function onChild1Created ( event:Event = null ):void
{
      facade.registerMediator( new Child1Mediator( customStack.child1 ) );
}

In the Child1Mediator i've set some NotificationInterests, but it seems, that the Interests will be ignored.
What is my problem - is the Child1Mediator not correctly registered or is it not possible because it's initializied within the CustomStackMediator?

Can I solve this with facade.registerObserver? This produces an error message because the method is not defined. How to define this, i couldn't find any example.
« Last Edit: December 07, 2007, 11:29:06 by diral » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: December 07, 2007, 12:23:08 »

You should not have to use View.registerObserver. In order to add the method to the IView interface, it had to be public, but the registerObserver method was only intended to be called from inside the View and was not replicated on the Facade, so as not to invite confusion about what you're supposed to do with it.

Your code looks good, and the Mediator should be registered. I would place a breakpoint on the line after the register has taken place, and then run in debug mode. When the debugger stops on the breakpoint, inspect your variables.

In Flex Builder in the debugger Variables view open the menu "down triangle on right side of variables view' and check 'Show inaccessable member variables'.

If you stopped at the end of the onChild1Created method, then 'this' in the variables view will be the CustomStackMediator. Open up 'this' search for 'facade', the local reference to the facade singleton instance.

Open up 'facade' and you'll see the model, view and controller vars which are references to their singleton instances.

Open up 'view' and look at its 'mediatorMap' is the mediator there? Note the memory address of the Mediator in question.

Look at its 'observerMap'. For the notification in question, you'll see a key, the value of which is an array the observers to be notified for this Notification.

In the observer list is there an observer with a reference to this Mediator (same memory location as the one identified in the mediatorMap)?

If so, this should work, and you should take a step back and set a breakpoint just before where you think you're actually sending the notification. Does it stop there when you run in debug mode? If not then obviously, explore why.

If it does stop at the line prior to your sending the notification and you can see that the notification is being sent, then move your breakpoint over to the Child1Mediator's handleNotification method and see what's going on.

-=Cliff>
Logged
Pages: [1]
Print