UPDATE:
More tests show it is happening when using native.showAlert
When not using this the leak is disappearing.
?
Can anyone please give me some hints how to use the native.showAlert with a 100% system memory removal of the used mem? (on device?)
- What the heck is this?
-
If state is a table you attached to composer, then you can ignore this comment.
-
If it is a table that composer made and manages, don’t do this.
composer.state.nextscene=“textscreen”
Reaching into composer.* to modify private data is a BAD BAD BAD idea.
There is no guarantee this will work for future releases and it may cause bugs and/or leaks.
- Adding your own logic onto composer is OK (be careful with the variable names you use.
- Better to use names unlike the internal naming convention like this: composer.__state == {}
- Composer source can be found here: https://github.com/coronalabs/framework-composer
- Manipulating composer’s internal variables and code is a bad idea.
-
The problem is not native.showAlert() it is more likely your wrapper code, or a side-effect of that code above.
-
That is a very inefficient way to make the language selection code. It is way too much too read and way too much to maintain. Leaks could be anywhere in there. Better to do this:
– define onComplete before this… local langs = {} – -- langs.shortcode = { title, msg, options } – langs.de = { “Mission abbrechen?”, “Möchtest Du die Mission wirklich verlassen?”, { “Nein”, “JA!” } } langs.fr = { “Voulez-vous vraiment quitter la Mission?”, “Cliquez sur OUI et quitter la mission.”, { “Non”, “OUI!” } } langs.it = { “Vuoi davvero lasciare la missione?”, “Fare clic su Sì e lasciare la missione.”, { “No”, “Sì!” } } … do the rest on your own local function showAlert( currentLanguage ) local d = lang[currentLanguage] – bad variable name, but I did it so code would fit in post if( d ) then local f = function() native.showAlert( d[1], d[2], d[3], onComplete ) end return timer.performWithDelay( 1, f ) end end … now you can use it like this: showAlert(‘fr’)
Updated prior post.
Added more comments and changed tone a bit.
Please note. I have to opt out of the rest of this discussion if it continues. I am running out of time for some of my own work.
Tip: If you don’t resolve this soon, try to find someone experienced who can download your game code and do a code-review. There are probably some more things they can help you clean up and simplify.
We have two functions for composer:
composer.setVariable() composer.getVariable()
That does what you’re trying to do by setting a .state table. While I don’t believe we use .state as a composer member it’s not safe in the long term. I know this comes from an old tutorial/recommendation in the Storyboard days, which is why we made a future-proof way to do this using those functions.
Now I’m going to disagree with @roaminggamer here. It’s possible (not probable) that Apple introduced a memory leak with their alerts. Or they changed something and our invocation of native.showAlert() may possibly be leaking with iOS 12+. Since it only happens on device, this is one area where macOS and iOS are executing different code.
This should be easy to prove. Setup a simple demo app that mimics you changing scenes, showing an alert and changing a scene from within the alert’s handler. You should either see the memory leak or not.
Rob