-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to unload and destroy a view. #3
Comments
Christophe suggested that in addition to support for unloading a view with the emit of the "app-unload-view" event we should add a function which can be called to unload the view as well to make it easier for an app to unload views. |
Agreed with Christophe's suggestion. Back in the dojox/mobile world, I've often found myself dynamically creating and reaping hierarchical structures - ie. only when transferring up the hierarchical view tree, as opposed from any deactivation. I'd need to control this kind of logic programmatically, so a function would be helpful. |
I will add an unloadView function was added to main.js, it will take these parameters: |
…ons on a view to alwaysAutoUnload:(the view will be unloaded after afterDeactivate every time the view is shown), neverAutoUnload(the view will never be unloaded automatically, no matter how many views are loaded), and use an autoUnloadCount(is set to a number which is used to determine how many views per constraint to leave loaded when transitioning). Fixes issue ibm-js#3
shouldn't it be promised based instead of callback? |
Yes, but I am going to have to convert all of the events that are using callbacks to be promise based, so I was thinking that I would do those all at the same time, if that is OK. I actually did not have any cases where the callback was needed, but thought it should be there just in case. |
that's indeed fine doing it later. |
The basic view unload support is in, the event is "dapp-unload-view", but it is currently only called for app.unloadApp(). I still need to add the auto unload options listed above, and the app.unloadView(...) support. |
This support will be added to the Load controller.
There will be a new event called "app-unload-view" to handle unloading and destroying a view. Calls to use the new "app-unload-view" would look like this:
I would also like to add some config options to make it easy to avoid having too many views loaded. Perhaps support for the app or a view to have these options:
"alwaysAutoUnload": which if set to true means the view will automatically be unloaded and destroyed after afterDeactivate is called for the view.
"autoUnloadCount": which is set to a number which is used to determine how many views (per constraint) to leave loaded when transitioning in the application.
"neverAutoUnload": which if set to true means this view will never be automatically unloaded and destroyed no matter how many views are loaded.
The text was updated successfully, but these errors were encountered: