Memory usage

[bregol]

Is there a way with Okra to either mark a view/viewmodel as shared, or to dispose of view/viewmodel to keep MEF from retaining several copies. I have an app using Okra where the user goes from home page to details page several times, and each time the details page is loaded, it is a new object in memory. This is a problem when each copy takes up a bit of memory. Is there a way with Okra to either release the memory when the details page navigates back to the home page, or to share the viewmodel so all details pages recycle the same object, to prevent this?

[Andy-Wilkinson]

Thanks for getting in touch. It's always good to get feedback (positive or negative!) from users.

Regarding memory usage, the current Okra implementation is fairly simple - if a page is in the back stack, then it stays in memory (unless the application is suspended & restarted). This means that memory should be released when you navigate back from a page. In your case it sounds like this isn't happening - so I've marked this as a bug.

I will investigate what is going on here with some of my own projects - it would be helpful however if you are able to provide a bit of information regarding what you are doing in the details page/view-model in case there is something a bit more specific.

Thanks for your support, Andy

[bregol]

I was able to get it working properly... it turns out there were some event handlers (added in the code of my VM base, to impliment things like responding to changes in network state) that were the cause of the page being kept in memory. I used iNavigationAware to remove the handlers when leaving the page, and now it properly releases the memory...

I did notice, however, that the settings flyouts are a different story. The settings flyouts are hooked up in AppBootstrap using SettingsPaneManager.GetNavigateToSettingsCommand. Every time the user visits a settings flyout page (although in most cases, this isn't something most users do often), the Settings pane back stack navigates forwards to a new item, so there is not the opportunity to release the memory for that stack.

[Andy-Wilkinson]

Good to hear that you got your original issue solved - event handlers in view-models are always a bit tricky. One alternative that you might want to consider is to move the network state handling into a service, and import that into the view-model via the IoC container. A single service can then run in the background and be shared by all pages - very much depends on your use-case if this works, or you just end up with different event handlers to release.

Regarding the issues with the settings flyouts - I never really had a good model for navigation awareness for them. I'll have a look and see if I can come up with something. It may be rare that users go to the settings pane, but it's still a memory leak.

Andy