Skip to content
This repository has been archived by the owner on Jul 20, 2019. It is now read-only.

Memory usage #80

Open
bregol opened this issue Jul 17, 2015 · 3 comments
Open

Memory usage #80

bregol opened this issue Jul 17, 2015 · 3 comments
Assignees
Labels

Comments

@bregol
Copy link

bregol commented Jul 17, 2015

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 Andy-Wilkinson self-assigned this Jul 24, 2015
@Andy-Wilkinson
Copy link
Member

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
Copy link
Author

bregol commented Jul 24, 2015

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
Copy link
Member

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants