Just wanted to post and say that I have started using the new 1.2 version of Director and thanks for fixing the issues that I reported in other threads. The new class works much better than the previous with regards to memory and stability.
Also thanks for putting in the proper support for calling CleanUp methods. [import]uid: 12529 topic_id: 6676 reply_id: 306676[/import]
Thanks MPotter!
Your help was really important to make version 1.2! [import]uid: 8556 topic_id: 6676 reply_id: 23279[/import]
Hmm, well, it works fine in the Simulator now, but I just build my app for the first time on Android and it has all sorts of problems. It often hangs when making the Director scene transitions. I’ll try building on iOS to see if it is any different. At this point I don’t know if it’s a Director problem or a Corona problem. [import]uid: 12529 topic_id: 6676 reply_id: 23295[/import]
Looks like I really need to find a completely different solution for my screen transitions.
In my app I have a main screen that is fairly graphics heavy. I was using the Director class to transition to side screens of various stats (simple screens with just text). The app was hanging when I would exit my simple screen to go back to the main screen.
If I remove the main background image of the main screen (which uses the most resources), then I don’t have any problems with the app hanging. But simply adding this:
[lua]local back = ui.newImage( “background.jpg”)
group:insert(back)[/lua]
to the new() routine of my main screen starts causing the hang.
Did somebody mention JPG problems on Android somewhere? Maybe I’ll change this to a PNG file to see if it’s any different.
But even with this fixed, it just takes too long for Director to recreate the main screen every time I transition from the simple stats screen. So I think I need to change to a method that doesn’t keep destroying and recreating the screen resources all the time.
[import]uid: 12529 topic_id: 6676 reply_id: 23299[/import]
Well, it’s not the JPG files. In fact even if I just switch between two simple screens with text I can eventually get my DroidX to hang.
Removing the collectgarbage calls in Director seems to help, but only seems to delay the inevitable.
Is *anybody* actually using Director in a REAL Android app? I really don’t see anything that Director is doing wrong, so maybe this is yet another issue with Corona on Android somehow.
Going to try iOS now [import]uid: 12529 topic_id: 6676 reply_id: 23317[/import]
Crashes on iPhone as well. Again, removing the collectgarbage calls in Director helps, but it will still eventually hang or exit the app. I’ll try the actual Director demo app now.
Edited: Director demo app seems to work. Switching between simple text screens seems to work. But my main app screen that loads images and stuff doesn’t work. So maybe the problem is still on my end. I’ll continue to look.
[import]uid: 12529 topic_id: 6676 reply_id: 23325[/import]
Sorry to report that the problem IS with something that you changed in v1.2. If I use my modified 1.1 Director code, then I don’t get the hang/crash on the actual phone. But using 1.2 I do.
I’ve been spending the afternoon trying to track down the problem. I have 4 changes that seem to help:
This means the user cannot interrupt a transition in progress. I do not believe this is good behavior. If the user taps the screen before the previous transition is complete, you shouldn’t just ignore them. You should cancel the previous effect and execute the new transition. So instead of your code:
[lua] if isChangingScene then
return true
else
isChangingScene = true
end[/lua]
I have this:
[lua] if (directorTimer) then
– ensure that we don’t change again until previous transition is finished
timer.cancel( directorTimer);
fxEnded();
end[/lua]
where “directorTimer” is the result of any previous timer.performWithDelay call.
Also set
[lua]directorTimer = nil[/lua] near the end of the fxEnded() routine.
Next, you check to see if the current scene is the same or not. I ran into trouble with this. It was still preventing me from interrupting current transitions. I think it is because of where “currScene” is set vs the old code that had “lastScene”. So I changed your code
[lua] if currScene then
if string.lower(currScene) == string.lower(nextLoadScene) then
return true
end
end[/lua]
back to this
[lua] if lastScene then
if string.lower(lastScene) == string.lower(nextLoadScene) then
return true
end
end[/lua]
and near the bottom of this routine before the return, I added:
[lua] lastScene = nextLoadScene[/lua]
The new unloadScene() routine seems to be causing problems. The more extra display objects you have on the screen, the more noticeable the issue is. With the above two changes, you can tap between two scenes really quickly to debug and uncover additional issues. Without the above changes you are forcing the user to wait until transitions are complete, which hides these additional timing issues that cause the actual phone devices to crash/exit (because of timing differences with the simulator).
If I comment out the call to
[lua]unloadScene( currScene)[/lua]
in fxEnded() then it removes a lot of the crash issues.
If I remove any of these 4 changes, then I get crashes on the actual phone. I think (1) and (2) just make it easier to reproduce the real problem by allowing fast transition interruptions. But the root cause is somewhere in how resources are being freed and garbage is being collected. I just can’t track down the actual cause.
In general I think it is a bad idea to force a call to collectgarbage yourself. This should be left up to the operating system. But it’s also possible that collectgarbage is just showing the problem because something has been freed that shouldn’t be.
I will let you look at your own code more to try and figure it out. I need to get on with my own app development and for now I’m just going to use the above changes since they seem to work. Good luck with this, and be sure to test on real hardware. There definitely is some differences between the simulator and actual hardware in these issues. [import]uid: 12529 topic_id: 6676 reply_id: 23342[/import]