Help: two "did" phases being called on scene:show after a single gotoScene

Solar2D Composer
#1

I’m trying to debug a weird issue: I have two composer scenes A and B. A has a tap listener attached to the scene view so that when the user taps the screen [lua]composer.gotoScene(“scenes. B”)[/lua] is called. I’ve checked and I know that this only gets called once. However if I’m tapping furiously at the screen the “show” function for scene B is called twice (only the “did” phase).

It’s really weird and I’m trying to track it down. So far I’ve attached a stacktrace output to every gotoScene call and print lines when scene B is entered. But I’m none the wiser. Anyone got any thoughts where to look next?

Here’s what my cleaned up console output looks like:

[lua]

Stack trace: composer.gotoScene(“scenes.A”)

stack traceback:

  … 

Scene A tap listener fired!

Stack trace composer.gotoScene(“scenes.B”)

stack traceback:

  …

event fired: show B phase “will”

event fired: show B phase “did”

X: calling composer.getScene(“B”)

event fired: show B phase “did”

X: calling composer.getScene(“B”)

[/lua]

In reality my debug statements are a lot less idealised! The rather neat “Scene A tap listener fired!” actually just prints “go go go!” in my code :stuck_out_tongue:

#2

Hmmm, by improving and adding to my debug printouts (they now read like the example), it appears that the second “did” event for the show function actually comes from a different call to composer.gotoScene. In fact it features a parameter which only gets passed into scenes. A. So it looks like that by mashing the mouse I can cause the show event targeted to scene. A  to be passed to scene. B  as well as it’s own show event.

Here’s the tidied up stack trace:

[lua]

scene. B :show event.phase==did

table: 0x7f88e548c0b0

{

  name = “show”,

  params = {

    msg = “Called from A”

  } --[[table: 0x7f88e04c31c0]],

  phase = “did”

} --[[table: 0x7f88e536edb0]]

scene. B :show event.phase==did

table: 0x7f88e07bcd50

{

  name = “show”,

  params = {

    decoded = 100 

  } --[[table: 0x7f88e57f2b00]],

  phase = "did"

} --[[table: 0x7f88e55e0700]]

[/lua]

Is this considered a bug, or does it come under a gotcha?

#3

So here’s the old problem code. The stuff in bold is what I’ve added to get rid of the issue of the wrong show event going to the wrong composer scene. 

local done

local close

close=function()

      if done then 

        return

      end

      done=true

      scene.view:removeEventListener(“tap”,close)

     

      timer.performWithDelay(500,function()

        composer.gotoScene(“scenes.B”,{params={msg=“Called from close”},

        effect=“fade”,

        time=500})

      end)

 end

 scene.view:addEventListener(“tap”,close)

So I’ve had to slow the entire transition down by a second to fix it! A single frame didn’t do it, which is a bit weird!

#4

I wonder if it’s linked to this?

http://forums.coronalabs.com/topic/48844-composer-sceneshow-did-triggers-too-soon/

#5

I’m having this issue too and I can’t figure out what’s going on. The “did” for one of my scenes gets called twice when the screen is tapped quickly.

#6

I see what you’re saying now. The “did” from the scene that was still finishing its entrance when the next goto was called gets fired in the newest scene. The simple solution I used is to just add the listener in the “did” of that first scene to make sure the transition fully completes, though this definitely seems like a bug.

#7

If you “tap” twice before the gotoScene() can do its thing, you can trigger two events.  The fix is to set a flag on the first tap so that if you reenter the tap handler and the flag is set, you ignore the subsequent taps.

Rob

#8

Hmmm, by improving and adding to my debug printouts (they now read like the example), it appears that the second “did” event for the show function actually comes from a different call to composer.gotoScene. In fact it features a parameter which only gets passed into scenes. A. So it looks like that by mashing the mouse I can cause the show event targeted to scene. A  to be passed to scene. B  as well as it’s own show event.

Here’s the tidied up stack trace:

[lua]

scene. B :show event.phase==did

table: 0x7f88e548c0b0

{

  name = “show”,

  params = {

    msg = “Called from A”

  } --[[table: 0x7f88e04c31c0]],

  phase = “did”

} --[[table: 0x7f88e536edb0]]

scene. B :show event.phase==did

table: 0x7f88e07bcd50

{

  name = “show”,

  params = {

    decoded = 100 

  } --[[table: 0x7f88e57f2b00]],

  phase = "did"

} --[[table: 0x7f88e55e0700]]

[/lua]

Is this considered a bug, or does it come under a gotcha?

#9

So here’s the old problem code. The stuff in bold is what I’ve added to get rid of the issue of the wrong show event going to the wrong composer scene. 

local done

local close

close=function()

      if done then 

        return

      end

      done=true

      scene.view:removeEventListener(“tap”,close)

     

      timer.performWithDelay(500,function()

        composer.gotoScene(“scenes.B”,{params={msg=“Called from close”},

        effect=“fade”,

        time=500})

      end)

 end

 scene.view:addEventListener(“tap”,close)

So I’ve had to slow the entire transition down by a second to fix it! A single frame didn’t do it, which is a bit weird!

#10

I wonder if it’s linked to this?

http://forums.coronalabs.com/topic/48844-composer-sceneshow-did-triggers-too-soon/

#11

I’m having this issue too and I can’t figure out what’s going on. The “did” for one of my scenes gets called twice when the screen is tapped quickly.

#12

I see what you’re saying now. The “did” from the scene that was still finishing its entrance when the next goto was called gets fired in the newest scene. The simple solution I used is to just add the listener in the “did” of that first scene to make sure the transition fully completes, though this definitely seems like a bug.

#13

If you “tap” twice before the gotoScene() can do its thing, you can trigger two events.  The fix is to set a flag on the first tap so that if you reenter the tap handler and the flag is set, you ignore the subsequent taps.

Rob