I have a doubt in movement of Composer.
Isn’t the part indicated by the deficit of the figure wasteful?
Why is such movement needed? Is this significant?
I have a doubt in movement of Composer.
Isn’t the part indicated by the deficit of the figure wasteful?
Why is such movement needed? Is this significant?
Not sure what you mean when you use the world ‘movement’, but it seems you’re asking why they break-down the scene transition into so many phases and sub-phases?
This is kind of a self-answering question. The more you work with composer (or any scene transition library) the more you will encounter scenarios where breaking down the steps is helpful. Regardless, this isn’t costly in terms of performance and if you don’t need the extra granularity in scene transitions you can ignore it.
I want to re-iterate, this is one of those things where only experience and need will show you why they are useful. There is no single right way to design a game or app. One will often encounter odd scenarios where having extra details helps.
PS - I’m not avoiding giving you a concrete example of usage. I use these details frequently when I want to defer creation, removal, modification of an object for visual or other reasons. It is just, this usage is so bound to my specific per-app needs, that I can neither explain (concisely) the context, nor even recall single instances that may be instantly elucidating.
To add to what Ed said…
There are things you need to do when the scene is created (not showing and may not show right away, such as pre-loading a scene). Then there are things many people want to do before the scene transitions on to the screen, such as positioning things that may have moved if you’re reloading the scene so things don’t “jump” into place. Then there are things you want to do after the scene is fully on the screen, like start things moving. Like wise there are things you will want to stop before you transition the scene away and things you may want to do after the scene is off the screen. Because of this, we have to offer all of these events and phases.
Rob
Thank you very much for your reply.
I can understand the difference between the “will” and the “did”.
It can be understood that this is convenient.
I don’t make this a problem.
But I can’t understand 2 following.
line#7 or #15
line#10~12 or line#19~20
I’m not distinguishable for a true complete process.
Is this processing right?
Do you permit this multiprocessing each time?
It should not, it should go:
scene1:create
scene1:show(will)
scene1:show(did)
Then you call composer.gotoScene(“scene2”)
scene2:create()
scene2:show(will)
scene1:hide(will)
scene2:show(did)
scene1:hide(did)
then you call composer:gotoScene(“scene1”)
scene1:show(will)
scene2:hide(will)
scene1:show(did)
scene2:hide(did)
or something like that.
There are other possibilities, that can cause weird processing, like not trapping the began and ended phase on touches triggering things multiple times.
Perhaps you should try the Composer sample app, and put in some prints and see how the scenes play out.
Rob
Hello Mr.Rob;
When I test, it won’t be a simple result.
Test composer program. (Google Drive)
I tested once again. That’s a test program only of composer and widget.
The result was also different by the difference in the versions.
Is there a problem with my test program?
Version 2014.2511 (2014.11.18)
Reload run…
Feb 15 10:04:01.449: home1:create(0)
Feb 15 10:04:01.449: home1:show:will(1)
Feb 15 10:04:01.449: home1:show:did(2)
Click [home1 -> home2] button
Feb 15 10:04:12.329: home1:hide:will(3)
Feb 15 10:04:12.330: home2:create(0)
Feb 15 10:04:12.330: home2:show:will(1)
Feb 15 10:04:12.441: home2:hide:will(3)
Feb 15 10:04:12.468: home2:hide:did(4)
Feb 15 10:04:12.529: home2:show:will(1)
Feb 15 10:04:12.568: home2:show:did(2)
Feb 15 10:04:12.596: home1:hide:did(4)
Feb 15 10:04:12.661: home2:show:did(2)
Click [home1 <- home2] button
Feb 15 10:04:18.100: home2:hide:will(3)
Feb 15 10:04:18.100: home1:show:will(1)
Feb 15 10:04:18.182: home1:hide:will(3)
Feb 15 10:04:18.205: home1:hide:did(4)
Version 2015.2545 (2015.1.24)
Reload run…
Feb 15 10:08:30.653: home1:create(0)
Feb 15 10:08:30.653: home1:show:will(1)
Feb 15 10:08:30.653: home1:show:did(2)
Click [home1 -> home2] button
Feb 15 10:09:17.350: home1:hide:will(3)
Feb 15 10:09:17.352: home2:create(0)
Feb 15 10:09:17.352: home2:show:will(1)
Feb 15 10:09:17.445: home2:hide:will(3)
Feb 15 10:09:17.471: home2:hide:did(4)
Feb 15 10:09:17.537: home2:show:will(1)
Feb 15 10:09:17.570: home2:show:did(2)
Feb 15 10:09:17.603: home1:hide:did(4)
Feb 15 10:09:17.669: home2:show:did(2)
Click [home1 <- home2] button
Feb 15 10:09:50.436: home2:hide:will(3)
Feb 15 10:09:50.437: home1:show:will(1)
Feb 15 10:09:50.560: home1:hide:will(3)
Feb 15 10:09:50.569: home1:hide:did(4)
Feb 15 10:09:50.635: home1:show:will(1)
Feb 15 10:09:50.668: home1:show:did(2)
Feb 15 10:09:50.701: home2:hide:did(4)
Feb 15 10:09:50.767: home1:show:did(2)
It appears you are not handling your touches correctly.
this:
onEvent = function(event) composer.gotoScene("home1", "slideLeft",300) end,
should be this:
onEvent = function(event) if event.phase == "ended" then composer.gotoScene("home1", "slideLeft",300) end end,
onEvent generates both a began and ended phase, like a touch handler. There are optional onPress and onRelease events that would not have to test for these phases.
Rob
Thank you Mr. Rob;
I mistook a point of a problem. I believed a problem of Composer.
My mistake. Thank you very much for your valuable time.
CyberCatfish
If you’re still reading, I should have mentioned. I discussed composer on the last 4 or so Corona Geek hangouts and made a set of examples for folks here:
https://github.com/roaminggamer/CoronaGeek/tree/master/Hangouts/Hangout%20128/composer_scene_manager
In this set of examples, you’ll find one that dumps the phases to the console, so you can see what is happening:
Cheers,
Ed
Not sure what you mean when you use the world ‘movement’, but it seems you’re asking why they break-down the scene transition into so many phases and sub-phases?
This is kind of a self-answering question. The more you work with composer (or any scene transition library) the more you will encounter scenarios where breaking down the steps is helpful. Regardless, this isn’t costly in terms of performance and if you don’t need the extra granularity in scene transitions you can ignore it.
I want to re-iterate, this is one of those things where only experience and need will show you why they are useful. There is no single right way to design a game or app. One will often encounter odd scenarios where having extra details helps.
PS - I’m not avoiding giving you a concrete example of usage. I use these details frequently when I want to defer creation, removal, modification of an object for visual or other reasons. It is just, this usage is so bound to my specific per-app needs, that I can neither explain (concisely) the context, nor even recall single instances that may be instantly elucidating.
To add to what Ed said…
There are things you need to do when the scene is created (not showing and may not show right away, such as pre-loading a scene). Then there are things many people want to do before the scene transitions on to the screen, such as positioning things that may have moved if you’re reloading the scene so things don’t “jump” into place. Then there are things you want to do after the scene is fully on the screen, like start things moving. Like wise there are things you will want to stop before you transition the scene away and things you may want to do after the scene is off the screen. Because of this, we have to offer all of these events and phases.
Rob
Thank you very much for your reply.
I can understand the difference between the “will” and the “did”.
It can be understood that this is convenient.
I don’t make this a problem.
But I can’t understand 2 following.
line#7 or #15
line#10~12 or line#19~20
I’m not distinguishable for a true complete process.
Is this processing right?
Do you permit this multiprocessing each time?
It should not, it should go:
scene1:create
scene1:show(will)
scene1:show(did)
Then you call composer.gotoScene(“scene2”)
scene2:create()
scene2:show(will)
scene1:hide(will)
scene2:show(did)
scene1:hide(did)
then you call composer:gotoScene(“scene1”)
scene1:show(will)
scene2:hide(will)
scene1:show(did)
scene2:hide(did)
or something like that.
There are other possibilities, that can cause weird processing, like not trapping the began and ended phase on touches triggering things multiple times.
Perhaps you should try the Composer sample app, and put in some prints and see how the scenes play out.
Rob
Hello Mr.Rob;
When I test, it won’t be a simple result.
Test composer program. (Google Drive)
I tested once again. That’s a test program only of composer and widget.
The result was also different by the difference in the versions.
Is there a problem with my test program?
Version 2014.2511 (2014.11.18)
Reload run…
Feb 15 10:04:01.449: home1:create(0)
Feb 15 10:04:01.449: home1:show:will(1)
Feb 15 10:04:01.449: home1:show:did(2)
Click [home1 -> home2] button
Feb 15 10:04:12.329: home1:hide:will(3)
Feb 15 10:04:12.330: home2:create(0)
Feb 15 10:04:12.330: home2:show:will(1)
Feb 15 10:04:12.441: home2:hide:will(3)
Feb 15 10:04:12.468: home2:hide:did(4)
Feb 15 10:04:12.529: home2:show:will(1)
Feb 15 10:04:12.568: home2:show:did(2)
Feb 15 10:04:12.596: home1:hide:did(4)
Feb 15 10:04:12.661: home2:show:did(2)
Click [home1 <- home2] button
Feb 15 10:04:18.100: home2:hide:will(3)
Feb 15 10:04:18.100: home1:show:will(1)
Feb 15 10:04:18.182: home1:hide:will(3)
Feb 15 10:04:18.205: home1:hide:did(4)
Version 2015.2545 (2015.1.24)
Reload run…
Feb 15 10:08:30.653: home1:create(0)
Feb 15 10:08:30.653: home1:show:will(1)
Feb 15 10:08:30.653: home1:show:did(2)
Click [home1 -> home2] button
Feb 15 10:09:17.350: home1:hide:will(3)
Feb 15 10:09:17.352: home2:create(0)
Feb 15 10:09:17.352: home2:show:will(1)
Feb 15 10:09:17.445: home2:hide:will(3)
Feb 15 10:09:17.471: home2:hide:did(4)
Feb 15 10:09:17.537: home2:show:will(1)
Feb 15 10:09:17.570: home2:show:did(2)
Feb 15 10:09:17.603: home1:hide:did(4)
Feb 15 10:09:17.669: home2:show:did(2)
Click [home1 <- home2] button
Feb 15 10:09:50.436: home2:hide:will(3)
Feb 15 10:09:50.437: home1:show:will(1)
Feb 15 10:09:50.560: home1:hide:will(3)
Feb 15 10:09:50.569: home1:hide:did(4)
Feb 15 10:09:50.635: home1:show:will(1)
Feb 15 10:09:50.668: home1:show:did(2)
Feb 15 10:09:50.701: home2:hide:did(4)
Feb 15 10:09:50.767: home1:show:did(2)
It appears you are not handling your touches correctly.
this:
onEvent = function(event) composer.gotoScene("home1", "slideLeft",300) end,
should be this:
onEvent = function(event) if event.phase == "ended" then composer.gotoScene("home1", "slideLeft",300) end end,
onEvent generates both a began and ended phase, like a touch handler. There are optional onPress and onRelease events that would not have to test for these phases.
Rob
Thank you Mr. Rob;
I mistook a point of a problem. I believed a problem of Composer.
My mistake. Thank you very much for your valuable time.
CyberCatfish
If you’re still reading, I should have mentioned. I discussed composer on the last 4 or so Corona Geek hangouts and made a set of examples for folks here:
https://github.com/roaminggamer/CoronaGeek/tree/master/Hangouts/Hangout%20128/composer_scene_manager
In this set of examples, you’ll find one that dumps the phases to the console, so you can see what is happening:
Cheers,
Ed