Out of Memory Exception & APP Crashed


#1

Hi Team,

My APP is live on play store and its doing well as well. But sadly my APP users are getting Out Of Memory Exception and APP’s are getting crashed as well. Could you please help me on this. I am attaching the stack trace log for the same.

Thanks a lot for your help.


#2

Tip2

/Boban


#3

HI Boban,

Thanks a lot for your quick advice and extremely sorry for late reply. Actually i am using only 6 screen in my APP and i have approx more tan 50 links to redirect which i am managing within this 6 screen only. But as you have mentioned i will try to reduce the number of scree further and observe if it helps me get the better results.
As per screen switching i am using below codes every time please guide me any thing is wrong in it or if you have any better idea.
Thanks a lot in advance.

image
image


#4

@bat_bot

One thing that I found the hard way (that was a few years ago, on MIT App Inventor, but likely this is also the case on Thunkable Classic) is that opening another screen does not close the calling one. In fact, if you “return” to the ‘original’ by calling “open another screen”, you are actually opening ANOTHER instance of the first screen.
And I was running out of memory from this.

So your 6 screens could feel like 60 if each of them was opened 10 times and never closed.

I solved this having only one permanently opened screen.
For instance if I was in screen B and needed to open screen C, then the logic was such that screen B would save its data, then close itself with a return code (close screen with value result:) that stated there was a request to open screen C.
Screen1 would then rely on “Screen1 other screen closed” event to get the result, and parse it properly to determine if a screen needs to be opened, and to open screen C if that was the instruction.


#5

Thanks mate,
Thats exactly what i was suspected i think you are absolutely right.Till now i was not sure but as you have experienced the same then it must be like that only. I am trying this new solution i don’t know whether it will resolve my problem or not so hope or the best. Appreciate if you can share the code you tried to get rid of this problem.

image

Thanks a ton in advance.


#6

It is actually a bit complicated. Here is what part of the page management code looks like in screen1:

image

And this is how it typically looks in the other screens:

image
image

The reason it is so complex is that I wanted the possibility for the user to get back to the previous screen as well when using the “back” function. Normally, using “back” would return to the calling screen, but in my case, the previous screen is always screen1, so I had to buffer the screen that was in use when the user decided to switch page.

The important thing to manage in this instance is to not use the "close screen’ procedure, but the “close screen with result” with the result being the name of the screen that should be opened next. That way, screen1 knows which screen it was that just closed and which one it should open next, keeping this in memory. If the user clicks ‘back’, then screen1 will know what screen to re-open.

This is a bit vintage, that is how I resolved to do things 3 years ago, with screen1 being only a splash screen and a hub for screen management, and users were expected to be able to jump from any screen to any other. Perhaps I’d do it differently now. The app I am focusing on now has the screen1 as the main processing one, and every other screen always go back to screen1 (no jumping between the “currency conversion management” and the “colour management” for instance) so I do not need to track where the user had been before.

By the way, I notice that your screen shots are showing elements in vivid yellow and deep purple, the colours I have in my blocks are more like antique gold and mauve. Do you adjust the colour of your screen shots deliberately or is there a colour control setting that I am unaware of?


#7

Oh, yeah, one last thing.

I am not sure the sequence to call the procedure that opens the screen and then close the screen is ideal.
Because the other screen is opened first. So it may be held in suspension until “LuckyScreen” itself closes, and then, when that one closes, the calling screen will resume and get to the closing statement.
You may want to test this, as I am not sure how the system handles it. Perhaps the opening request is buffered until the current block is exhausted, so that it will get to close before the other one opens. But suppose that this block has a lot of other activities in there. Would they get done? Or would they be suspended until the other one returns?
I would think the latter, which is why you might still keep a lot of data pending, and could still end up with memory overrun.

I did plenty of tests 3 years ago, with screens being opened and closed, and with the “when Other Screen Closed” and “when screen Initialize” to get a feeling as to the order things happen. That is when I decided to go with this “never open a new screen until AFTER the previous one is closed” approach, that sees screen1 as the only permanently opened screen. So, at most, I have two screen that are live, the other screens only take turns being screen #2.