This project has moved. For the latest updates, please go here.

How to remove V-VM from memory?

Nov 30, 2010 at 7:43 AM

How can I remove a view-viewmodel from memory? Currently they stay in memory as a singleton. But that's not a very good idea for large applications. Would consume a lot of memory.

Coordinator
Nov 30, 2010 at 11:47 AM

I imagine that could be true, but I haven't run into the issue yet. I've worked with some extremely large Silverlight applications and the memory footprint has never been an issue from views and view models, even with dozens of them. Typically, the memory footprint comes from the data that the view models manipulate - which is why I provide a deactivate view so lists can be cleared/etc. I haven't addressed this because I haven't run into it as an issue - in fact, I explicitly used the lifetime option because in many cases where the views are created each time, while eventually they would get cleaned up, they could end up filling a lot of memory through copies before garbage collection. In my performance runs, I always ended up with a smaller memory footprint using a single view/view model in memory and having the view model manage its resources than I did creating a new one each time. Again, not saying it couldn't happen but the framework doesn't address this because I just haven't run into it as the footprint of a view or view model is significantly small, unless you are not using virtualizing panels for long lists or containing large lists in the view model that you don't release.

Nov 30, 2010 at 12:31 PM
Edited Nov 30, 2010 at 12:32 PM

Speaking of the "lifetime option" - have you encountered scenarios where you need several instances of the same V-VM-ensemble displayed at the same time?

I'm currently working on a dashboard application where there are several basically identical views (for different model instances) which I'd like to put up on screen beside each other.

So far I don't see how this could work with Jounce's current ViewModelRouter approach.

Coordinator
Nov 30, 2010 at 12:39 PM

I'll put together and example, but basically whenever I have to have multiple view models, I'll simply export them directly without tagging and do the binding directly. I'm looking at a decent way to do it as an attributed option.

Nov 30, 2010 at 1:58 PM

Yeah, direct binding is sure to work but it kinda lacks the elegance of the attributed option.

At least one other MVVM framework that I know deals with this situation by leveraging MEF's PartCreationPolicyAttribute to create individual instances for CreationPolicy.Shared.

Nov 30, 2010 at 3:05 PM

The best way i found to do it is to use filtered catalog with PartMetaData.

I created new NonSharedViewNavigationArgs , NonSharedViewModelRouter,NonSharedViewRouter  for those view and view model.

When i need a new view/viewmodel  i create a new filteredcatalog from the maincatalog and import the view and viewmodel from him.

As UniqueId i personnaly used the ViewName:entityType:UniqueId

When i m done with my current project, I will create a sample if Jeremy is OK

 

Width
Coordinator
Nov 30, 2010 at 6:15 PM

Very interested to see that sample!

And for the record, all of these are great suggestions. If it's not in the framework, it's either (a) because I never encountered it as an issue thus didn't address it, (b) felt there are too many ways to address it to impose it as "guidance" in a framework, or (c) just didn't have time. :)

Oct 27, 2011 at 12:53 PM
shrog wrote:

The best way i found to do it is to use filtered catalog with PartMetaData.

I created new NonSharedViewNavigationArgs , NonSharedViewModelRouter,NonSharedViewRouter  for those view and view model.

When i need a new view/viewmodel  i create a new filteredcatalog from the maincatalog and import the view and viewmodel from him.

As UniqueId i personnaly used the ViewName:entityType:UniqueId

When i m done with my current project, I will create a sample if Jeremy is OK

 

Width

Hi shrog, I've a project with multiple Non-shared views/viewmodels which are opened several times and sometimes at the same time

If I understand your implementation permits to remove each instance of the memory when deactived.

Do you have a small exemple or maybe  a link to a documentation?

Thanks!

Feb 24, 2012 at 12:38 PM
jeremylikness wrote:

I imagine that could be true, but I haven't run into the issue yet. I've worked with some extremely large Silverlight applications and the memory footprint has never been an issue from views and view models, even with dozens of them. Typically, the memory footprint comes from the data that the view models manipulate - which is why I provide a deactivate view so lists can be cleared/etc. I haven't addressed this because I haven't run into it as an issue - in fact, I explicitly used the lifetime option because in many cases where the views are created each time, while eventually they would get cleaned up, they could end up filling a lot of memory through copies before garbage collection. In my performance runs, I always ended up with a smaller memory footprint using a single view/view model in memory and having the view model manage its resources than I did creating a new one each time. Again, not saying it couldn't happen but the framework doesn't address this because I just haven't run into it as the footprint of a view or view model is significantly small, unless you are not using virtualizing panels for long lists or containing large lists in the view model that you don't release.


My biggest issue with memory is due to Silverlight memory leaks. Manage the Deactivate as I wish there are certain scenarios where without destroying the View the memory is not released. Having a way to remove a View (and possibly VM) gives more absolute control.