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

Show Posts

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / Re: Unable to get instance of a facade in multicore on: August 05, 2008, 01:52:23
Got it wrong again. It is not the definition for instanceMap. It took awhile but the same bug showed up using an Object type for instanceMap. Something is going on with dynamic loading of modules and it is proving very difficult to track down.
2  Announcements and General Discussion / General Discussion / Re: Unable to get instance of a facade in multicore on: August 05, 2008, 11:29:45
Think I found the problem. In org.puremvc.as3.multicore.patterns.facade.Facade instanceMap is defined as a static var of type Array. instanceMap is actually used as an associative array instead of an Array. Changing the definition to Object from Array fixes the problem.

Thanks Cliff for you help in working through this.
3  Announcements and General Discussion / General Discussion / Re: Unable to get instance of a facade in multicore on: July 31, 2008, 06:43:46
I will try to create some code that reproduces the problem. It will be interesting to see if the problem occurs in simpler code or if it is a issue with the complexity of our application.
4  Announcements and General Discussion / General Discussion / Re: Unable to get instance of a facade in multicore on: July 30, 2008, 09:14:20
Thanks for the suggestion Cliff. I've now tried several different methods of calling the code that gets the instance of the facade. None of them were successful. With rapid changing between modules I can always make it fail after a number of swaps. What is happening is the instanceMap[key] statement does return an object, but that object is of type Facade instead of an instance of my subtype. The cast then fails.

Finally found a work-around for this issue. In the getInstance method of my subtype I added an optional parameter named "force" and default it to false. When getting the instance of a facade during the initialization of a module I set force to true.

In the getInstance method when force is true, I retrieve the object at instanceMap[key] and cast it to IFacade. If I got an object, I call removeCore(key) on that object and then assign instanceMap[key] to a new instance of my subclass. Using this approach I have not been able to create the break when switching between modules.

The code I'm using is careful to call removeCore on the facade when the module is going out of memory so I'm at a lose to explain why instanceMap[key] finds anything when the module starts up the next time.

5  Announcements and General Discussion / General Discussion / Re: Unable to get instance of a facade in multicore on: July 29, 2008, 02:13:58
More information on this problem.

Tracing through the static getInstance method in the facade class, I found that the provided key returns an object from the instanceMap, but that object is of type Facade and not classes type. The cast on the return statement fails causing the problem.

The getInstance code will work correctly for six or seven cycles between modules and then it fails.
6  Announcements and General Discussion / General Discussion / Unable to get instance of a facade in multicore on: July 29, 2008, 01:43:42
I am using the Multicore version of PureMVC in a good sized Flex project. The application is broken into a number of dynamically loaded modules and each has its own facade. Users select a module by clicking on items in a menu bar.

Most of time things work as expected, but if you click quickly between items in the menu bar or if you switch quickly back and forth between modules, you can cause a problem with the facade get instance code. Symptom of the problem is facade winds up being null in the newly loaded module.

I first thought the problem was related to switching modules before a module had fully loaded and added code to my load routine to ensure that one module is "ready" before I permit a switch to a new module. When switching I call remove core to clear out the PureMVC core for the module going out of scope (and out of memory).

Carefully controlling the swap between modules has reduced the times when we see the problem, but it has not gone away. Modules contain the code creationComplete="moduleInit();" and in the moduleInit() function you find:

public function moduleInit():void
{   
  //Create an instance of MyTeamFacade
 facade = teamFacade.getInstance(getModuleKey());
 facade.startup(this);             
}

The error that occurs points to the facade.startup(this); statement because facade is null.

Anyone have any suggestions on how to figure out what's going on here?


7  Announcements and General Discussion / General Discussion / Re: Notification firing multiple times in multicore version on: May 09, 2008, 11:30:21
On the good news side, more tracing and debug indicates the sendNotification is being called multiple times in this situation. For each of the notifications triggered, there is a sendNotification occurring. So this does not appear to be a PureMVC issue, but instead something that is going on in Flex.

I'll just have to keep digging until I understand it.
8  Announcements and General Discussion / General Discussion / Re: Notification firing multiple times in multicore version on: May 09, 2008, 11:01:47
I did as suggested and displayed the notifications inside of the facade. I am seeing the notifications notifyObservers trace message fire once for each time that the module is loaded.

First time the module is loaded:
:
toolbarMediator toolbarAction: createactivity
notifyObservers: startup
notifyObservers: openfileupload
notifyObservers: uploadurireceived
notifyObservers: GetFileExtensions finished
notifyObservers: categoryavailable
notifyObservers: ListCategory finished
notifyObservers: GetActivityContactCandidates finished

2nd time the module is called:
:
toolbarMediator toolbarAction: createactivity
notifyObservers: uploadurireceived
notifyObservers: startup
notifyObservers: openfileupload
notifyObservers: GetActivityContactCandidates finished
notifyObservers: GetActivityContactCandidates finished
notifyObservers: categoryavailable
notifyObservers: ListCategory finished
notifyObservers: categoryavailable
notifyObservers: ListCategory finished
notifyObservers: GetFileExtensions finished
notifyObservers: GetFileExtensions finished
notifyObservers: closefileupload

3rd time the module is loaded:
:
toolbarMediator toolbarAction: createactivity
notifyObservers: uploadurireceived
notifyObservers: startup
notifyObservers: openfileupload
notifyObservers: GetActivityContactCandidates finished
notifyObservers: GetActivityContactCandidates finished
notifyObservers: GetActivityContactCandidates finished
notifyObservers: categoryavailable
notifyObservers: ListCategory finished
notifyObservers: categoryavailable
notifyObservers: ListCategory finished
notifyObservers: categoryavailable
notifyObservers: ListCategory finished
notifyObservers: GetFileExtensions finished
notifyObservers: GetFileExtensions finished
notifyObservers: GetFileExtensions finished

I was under the assumption that calling removeCore would clean up PureMVC, but that may not be happening.
9  Announcements and General Discussion / General Discussion / Notification firing multiple times in multicore version on: May 09, 2008, 08:47:45
This issue is going to take some explanation.

First I have an application that uses dynamically loaded modules. To support this the main application mxml file contains a load module method that calls the currently loaded module and tells it it is going away, tells the main application's facade to remove core for the facade of the loaded module, sets the module loader's url to an empty string, finally sets the module loader's url to the new swf file. This appears to be working correctly and modules load as expected.

In the module where I'm having the problem, the your going away method does a remove core for the module's facade in an attempt to clear all of the facade related data.

With the above as background here's what is happening:

The loaded module (new doc panel) accepts data from the user then calls a proxy to post that data to a remote server. When the remote service call completes a notification is sent from the proxy. This works as expected.

User enters the module first time, files in the fields, and the new doc is sent to the server. Debug trace shows the proxy call is made and the completion notification received as expected.

The user then clicks in the menu to access the same module again. The app module load method follows the process described above and reloads the module. User enters new data for the second document and the proxy is called. Debug trace shows that the proxy is called once as expected, but the completion notification is received twice.

The user repeats the process, select the module from the menu, module loads again, user completes fields. Trace shows the proxy is called once as expected, but the completion notification is received three times.

Using debug and stepping through the code I can see that a new facade instance is being created for the module each time that it is being loaded. The question is where is the notification being stored so that it is firing multiple times? As it fires once for each time the module has been loaded I have no idea what is happening. Based on debug tracing I can only find the module in memory once. Is there something going on with PureMVC that is causing this?

Any ideas or help will be greatly appreciated.
10  Announcements and General Discussion / General Discussion / Re: Testing practices for Pure MVC on: May 09, 2008, 08:10:35
One approach that is working for us is to create unit tests using FlexUnit and use them to test all methods and classes that do not directly alter view components. Commands and proxies for the most part can be tested and some code in mediators.

To pull this off, I created a special extension of Facade that stores notifications in an ArrayCollection instead of immediately sending them. Then I added additional methods to check to see if a notification had been sent (added to the internal array collection), actually send the notification, and retrieve the notification. Using this version of facade, I'm able to create test data for the body of a notification that will normally trigger a command. Send that notification and verify that the facade has it, then really send the notification. The command as it processes sends additional notifications. The command sent notifications are stored in the facade and not immediately sent. Code in my unit test checks whether the correct notifications were sent and if the body of those notifications is as expected. Once they have been checked, I can tell the special facade to really send them and again check to see if the correct follow on notifications are sent.

This approach is working well checking the flow of notifications and command executions. Overriding sendNotification to save the notification is easy--just store the notification in an array collection. Checking for stored notifications requires that you loop through all entries in the array collection checking for the notification name. Really sending a perviously stored notification just requires doing a super.SendNotificaiton call.

Give this approach a try and see if it will work for you.
Pages: [1]