Notice: The Monaca & Onsen UI Community Forum is shutting down.
For Onsen UI bug reports, feature requests and questions, please use the Onsen UI GitHub issues page. For help with Monaca, please contact Monaca Support Team.
Thank you to all our community for your contributions to the forum. We look forward to hearing from you in the new communication channels.
Memory leackage OR it's normal?
This is about Onsen UI 2.
In this example, http://codepen.io/CNaik/pen/PNjeoo , every time when new page is selected from slider menu, console message appears showing the scope is created for respective page’s controller. But destroy watcher is never called. Which I think means that the allocated memory will not get free.
If my understanding is correct, do we need to manage memory our self? OR am I doing anything wrong?
Also if available kindly share resource link mentioning memory management best practices while using Onsen UI. I tried but couldn’t found one.
Thank you for the bug report. You were correct that there was a memory leak. It is fixed now and will be available in beta 9.
The splitter is a new component and thus hasn’t been very well tested yet.
@IliaSky Thank you for a quick reply.
I downloaded latest build and updated website references to beta 9 (/*! onsenui v2.0.0-beta.9-build.2468 - 2016-03-28 */).
But now it has started throwing console errors that closeLeft() and loadContentPage() are not splitter functions.
It’s was working fine with version beta 7 ( /* v2.0.0-beta.7-build.2311 - 2016-03-14 */).
Do you think it is due to the current update OR something changed in beta8/beta9 which I am not aware about? I have checked the documentation at https://onsen.io/2/reference/ons-splitter.html but don’t see any change.
@CNaik The splitter API was changed in beta.8. Looks like the docs were not updated, we certainly need to fix the docs.
Now ons-splitter has
contentproperties that let you access to the sides and the content. Therefore, you can do
document.getElementById('mySplitter').content.load(page), for example. I think this is better than the previous API :)
@Fran-Diox Thank you for your reply.
Previous API was better as it needed to type less number of characters. :) Though I am sure, this must have better performance impact as you guys have done it.
I will again implement beta 9 and will come back in case if I face any problem.
Have set latest build (/*! onsenui v2.0.0-beta.9-build.2475 - 2016-03-28 */) in my project but still destroy event is not being called.
Is there any way I can get direct URLs to latest build so that to set them in Codepen? In which case, I will update my demo.
@CNaik It was merged yesterday so you should use
/*! onsenui v2.0.0-beta.9-build.2482- 2016-03-29 */(generated today).
I don’t think you can get a URL for the nightly builds. What you can do is clone OnsenUI repo and run
gulp serve. Then include the generated files from
builddirectory in your project using a relative path
src="../../repos/OnsenUI/build/js/.....". That way you only need to do
git pulland maybe build the css-components.
@Fran-Diox Thank you.
Have updated project with latest build (/*! onsenui v2.0.0-beta.9-build.2482 - 2016-03-29 */) but result is still the same, destroy event is not being called.
FYI, I have got this version using Get the latest build! button on https://onsen.io/download.html (the same as you have marked as nightly builds in your last post).
Direct link I was just asking to update Codepen demo so that you can quickly take a look.
As @Fran-Diox mentioned we have no way to easily give the latest versions. Generally we expect people to use the releases, not the nightly builds I guess.
For your case I just uploaded the files online and made pen based on yours, but with the new version. It’s emitting the event over there.
@IliaSky Thanks a lot.
I will further dig into it to see what’s the problem in our project.
Replacing document.getElementById(‘splitter’).content.load(contentPage) with splitter.content.load(contentPage) did the trick.
Yes. I guess @Fran-Diox mentioned the vanilla API. The angular is the same - the only difference is the one which you saw - in Angular you would never want to do
document.getElementById(‘splitter’). If you do that then you access our vanilla js api which is not what you want and also doing stuff like that is just against the angular paradigms.
Anyway I’m glad that the problem is solved. :)