I have a childwindow with an associated VM that gets created each time I ask the child window to open. when the childwindow opens, it registers a listener for an MVVM Light message. After I close the window, I'm pretty sure that I'm releasing all references to it, but I don't actually call dispose because it does not implement IDisposeable.
When I instanciate another child window of the same type, and send it a different context, I know that I'm receiving the message from the previous instanciation of the VM... each time I use the window, more and more VM are listening, and the code repeats.
How can I be sure that my previous VM that registered to listen to a message, has actually been released and is no longer active. Is there a deterministic way to do this?
Whenever you register a message you should make sure that you unregister the message as well. To unregister you can use Cleanup method on classes deriving from ViewModelBase. In other cases, e.g. a view, you should implement a method hat is called when the view is unloaded - e.g by trapping and handling the unloaded event on a control or view. In this method you then call Messenger.Unregister(EventTarget).
This behaviour is a quirk in the current version of the toolkit, and Laurent is aware of it.
How have you coded the handler for the message in the VM? It sounds like you're probably pointing it to a method inside the same VM which is registering for the message. This causes the Messenger class to maintain a reference to the VM and prevent it's garbage collection (see here for discussion). There are two solutions: implement IDisposable and unregister all messages for your VM instance or simply unregister all messages from the VM instance when the child dialog closes. Personally I'd do both to ensure the entire object web is released.
You can use either the Cleanup method or manually unregister the message. For more details click here.
Related
Does anyone have and definitive information on how iOS handles a UINavigationController stack it the user is allow to keep drilling-down. Will it actually start to free up memory by saving the state of the previous controllers?
This has been asked on here before, but the answers have been contradictory, so if anyone really knows how this is handled that'd be very useful.
If not, does anyone know of a subclass that will handle this?
Basically, it depends on the implementation of your controllers.
When you keep pushing controller on to a navigation controller, eventually memory will get low. Controllers that you pushed on a navigation controller will not be released for you when memory gets low, though.
What happens is your controllers get a notification which is handled in your controllers' didReceiveMemoryWarning method. There you can release all the objects used in your controller that are not necessary anymore or can be recreated when the controller is popped back.
Memory is a critical resource in iOS, and view controllers provide built-in support for reducing their memory footprint at critical times. The UIViewController class provides some automatic handling of low-memory conditions through its didReceiveMemoryWarning method, which releases unneeded memory.
Prior to iOS 6, when a low-memory warning occurred, the UIViewController class purged its views if it knew it could reload or recreate them again later. If this happens, it also calls the viewWillUnload and viewDidUnload methods to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded from the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. On iOS 6, views are never purged and these methods are never called. If your view controller needs to perform specific tasks when memory is low, it should override the didReceiveMemoryWarning method.
I have a custom observer class derived from CBase, MConnectionMonitorObserver, and QObject(for signals) that I use to observe events from RConnectionMonitor.
When I call the RConnectionMonitor::NotifyEventL passing the observer instance, the application crashes saying that a thread has panicked.
What I'm trying to do here is to listen to the network events asynchronously without blocking the main thread.
EDIT: Should I use an active object to hold the RConnectionMonitor object?
Best regards
The problem was, as #James commented, that I was registering for events before I established the connection to the connection monitor server.
NativeApplication.nativeApplication.exit(); - this method is used for exit the application of flex/air .
application.close(); - this method also used for exit the application of flex/air -
So what is different?
He is referring to NativeApplication.exit() vs WindowedApplication.close().
WindowedApplication.close() Closes the
application's NativeWindow (the
initial native window opened by the
application). This action is
cancelable.
Calling close() on the application window will effectively shut down the application, but using the exit() method on NativeApplication is the proper way to terminate it. See the following link for more info:
http://livedocs.adobe.com/flex/3/html/help.html?content=app_launch_1.html
I am not sure I am understanding your question entirely because I am not finding an application.close() method.
Here is the documentation on NativeApplication, an AIR only class: http://livedocs.adobe.com/flex/3/langref/flash/desktop/NativeApplication.html#exit()
It defines the exit method like this:
Terminates this application.
The call to the exit() method will
return; the shutdown sequence does not
begin until the currently executing
code (such as a current event handler)
has completed. Pending asynchronous
operations are canceled and may or may
not complete.
Note that an exiting event is not
dispatched. If an exiting event is
required by application logic, call
NativeApplication.nativeApplication.dispatchEvent(),
passing in an Event object of type
exiting. Likewise, closing and close
events are not dispatched before
application windows are closed. If
windows should be notified before your
application exits, you can dispatch
closing events for each open window.
If a window close event is required,
call the window's close() method
before exiting.
Here is the documetation on Application, a Flex class: http://livedocs.adobe.com/flex/3/langref/mx/core/Application.html#methodSummary
It does not seem to have a close() method associated with it. Are you possibly confusing the application class with a window class that you need to close before calling the NativeApplication.nativeApplication.exit() ?
I would be happy to help you research this further if you can clarify the question.
One completely exits the application, the other only closes the main window. It's important to understand the difference. On a Mac, for instance, closing all of an application's windows often leaves that application running in the dock. This is rarely the case on Windows, but if you have a dock icon, you should get similar behavior, I think.
I am writing a custom Windows Workflow Foundation activity, that starts some process asynchronously, and then should wake up when an async event arrives.
All the samples I’ve found (e.g. this one by Kirk Evans) involve a custom workflow service, that does most of the work, and then posts an event to the activity-created queue. The main reason for that seems to be that the only method to post an event [that works from a non-WF thread] is WorkflowInstance.EnqueueItem, and the activities don’t have access to workflow instances, so they can't post events (from non-WF thread where I receive the result of async operation).
I don't like this design, as this splits functionality into two pieces, and requires adding a service to a host when a new activity type is added. Ugly.
So I wrote the following generic service that I call from the activity’s async event handler, and that can reused by various async activities (error handling omitted):
class WorkflowEnqueuerService : WorkflowRuntimeService
{
public void EnqueueItem(Guid workflowInstanceId, IComparable queueId, object item)
{
this.Runtime.GetWorkflow(workflowInstanceId).EnqueueItem(queueId, item, null, null);
}
}
Now in the activity code, I can obtain and store a reference to this service, start my async operation, an when it completes, use this service to post an event to my queue. The benefits of this - I keep all the activity-specific code inside activity, and I don't have to add new services for each activity types.
But seeing the official and internet samples doing it will specialized non-reusable services, I would like to check if this approach is OK, or I’m creating some problems here?
There is a potential problem here with regard to workflow persistence.
If you create long running worklfows that are persisted in a database to the runtime will be able to restart these workflows are not reloaded into memory until there is some external event that reloads them. As there they are responsible for triggering the event themselves but cannot until they are reloaded. And we have a catch 22 :-(
The proper way to do this is using an external service. And while this might feel like dividing the code into two places it really isn't. The reason is that the workflow is responsible for the big picture, IE what should be done. And the runtime service is responsible for the actual implementation or how it should be done. That way you can change the how without changing the why and when part.
A followup - regardless of all the reasons, why it "should be done" using a service, this will be directly supported by .NET 4.0, which provides a clean way for an activity to start an asynchronous work, while suspending the persistence of the activity.
See
http://msdn.microsoft.com/en-us/library/system.activities.codeactivitycontext.setupasyncoperationblock(VS.100).aspx
for details.
I am using NHibernate on a new ASP.NET project, and am running into what I believe to be strange behavior. I am attempting to manage my session by using an HttpModule to catch the EndRequest event and close the session. This is working fine, however, after the EndRequest event fires, I am getting an exception in the OnLoad event of one of my custom controls that is attempting to read a Property from my object that is lazy loaded. I get an exception stating 'failed to lazily initialize a collection, no session or session was closed'. Turning lazy load off for these properties does fix the problem, and is an acceptable solution. But this seems to be going against what I always thought to be true.
I would assume that the OnLoad event and all server side processing would be done at the point that EndRequest is fired. This is also the first time that I have used IIS 7 on a project. Is this a reason for the behavior? What is the expected behavior?
I just had a 'palm slaps forehead' moment. Despite the fact that I am in fact deploying to an IIS 7 server, I have been debugging using the VS 2008 Built in Web server (Casini). Casini passes all requests through the ASP.NET pipeline, IIS does not. This was causing a request for an image file or javascript file (or any other static resource) to close my NHibernate session before I was actually thinking it should close.
Thanks for the list of resources, I will certainly look into them.
If your object is lazy-init and no session is open, resolving the properties will fail.
Remember that lazy exceptions will most probably appear when you have some relationship with another entity that hasn't been initialized.
http://forum.springframework.org/showthread.php?t=13474
I would also recommend using something like the HTTP Module in Rhino Commons to manage your NHibernate Sessions.
You should use a shrinkwrapped package for dealing with this.
I like to use Autofac with ASP.NET/MVC integration. You simply ask the RequestContainer for an ISession whenever you need it and, because the ISession is IDisposable, the RequestContainer automatically knows to dispose of the ISession when the current request ends. Everything is taken care of for you.
use HttpModule if you need lazy loading. Inherit your class from it and then you'd have two methods you can override (can't remember their names). First one is called each time any page is requested. Open the session there and put the session in viewstate. The other method is called when page is posted back, close your session there.