display.newText Object needs to persist over three scenes - please verify solution

Dear Corona community,

what I’d like to do: I would like to create a “my friends” newText displayobject in sceneA and keep this object when I “slideLeft” to sceneB and also “slideLeft” further from sceneB to sceneC. When - at any time (sceneA, sceneB or sceneC) - I change to sceneD, sceneE or sceneF, the object has to disappear. The “myfriends” text should not slide with the scene (by adding it into the scenegroup) and it also should not disapear and reappear when changing scenes (by using :did-phases).

what I have done so far: Following the Goodbye Globals tutorial I have setup a “submenus.lua” file. Within the :show function of sceneA, I create the textobject and store a reference to it in this submenus.lua:

local submenus = require("submenus") title = display.newText("my friends", display.contentCenterX, screenTop + 25, native.systemFontBold, 26) title:setFillColor(0.35) submenus.menu = title

Since this object is not placed into the scenegroup, it persists on screen. I can access it in sceneB or sceneC by requiring my “submenus.lua” and changing its fillColor for example:

local submenus = require("submenus") local title = submenus.menu title:setFillColor(0.5)

In scenes where I don’t want the title, I check for the existence of “submenus.menu”. In case it is not (yet) nil, I remove it:

submenus.menu:removeSelf() submenus.menu = nil

What I dont like about this solution: I have like twenty scenes in total, and only three of them are supposed to display my “my friends” title. The solution above works, but now I have to run additional code (check for existence of submenus.menu) in each and every scene while only a few scenes actually show the title.

My question now is: Is there any better way of keeping a text-object untouched alive among three scenes, while as soon as you leave one of those scenes and go to one of the rest of the scenes, it disappears?

Hope it got clear what I want do to :slight_smile:

Thanks

Composer has a feature we call HUD mode, because it might be useful in creating a UI that’s persistently on screen and allow scenes to change underneath it.

Simply do not put the display object you want to stay on the screen in a composer group.  In your case, I would create the display.newText()s in main.lua, add them to your Goodbye Globals table so you can access them everywhere.

Now if I understand correctly, you can only change scenes by going from sceneA to sceneB to sceneC etc. and you can only go backwards the same route.  That is there is no direct path to sceneB unless you’re coming from sceneA or sceneC and the only way to get to sceneC is from sceneB and sceneD.

If this is the case, I would put code in sceneC that would show the text objects and in sceneD that hides the object.  Since you will create the text in main.lua (or sceneA), you only need to hide it when you get to sceneD. You only need to show the object when you’re going back to sceneC.  You can use the .isVisible to show/hide the object. If it’s already showing, setting the .isVisible property to true won’t cause any problem.  I wouldn’t bother deleting/recreating the object, just show/hide it.

Now if you have the ability to jump to sceneB from sceneF, then you will have to show/hide in each scene, but it’s one line of code per display object.

Rob

Rob said: Now if I understand correctly, you can only change scenes by going from sceneA to sceneB to sceneC etc. and you can only go backwards the same route.  That is there is no direct path to sceneB unless you’re coming from sceneA or sceneC and the only way to get to sceneC is from sceneB and sceneD.

==================

Thank you Rob for your help. Unfortunately I didnt make it clear enough, sorry for the misunderstanding: I can go from any scene to any other scene, otherwise I would have chosen the idea you just posted. So, if I understand you correctly, in this case I really have to either hide/unhide or remove/add it in every single scene. Ok then, I’ll do that :slight_smile:

Am I right that hide/unhide would be better performance-wise (since creating/removing might take longer), while creating/removing would - in theory - be better considering ram-usage? I have absolutely no idea how “ram-expensive” storing the title in the background and making it visible in relevant scenes would be. Is this something I should consider or could I like store hundreds of textobjects in the background and Corona would just yawn? :slight_smile:

If you’re going to be using an object frequently, it’s always better to create it once and use it many times unless the object consumes a lot of memory.

Rob

And I guess a simple textobject does not count as memory-consuming! All right, thanks for your input Rob

It’s a display object which means there is texture memory allocated and Lua memory (it is after all a table). But it’s not like you’re creating 100 of these. There will be a little memory bloat, but I doubt it will be significant.

Rob

Composer has a feature we call HUD mode, because it might be useful in creating a UI that’s persistently on screen and allow scenes to change underneath it.

Simply do not put the display object you want to stay on the screen in a composer group.  In your case, I would create the display.newText()s in main.lua, add them to your Goodbye Globals table so you can access them everywhere.

Now if I understand correctly, you can only change scenes by going from sceneA to sceneB to sceneC etc. and you can only go backwards the same route.  That is there is no direct path to sceneB unless you’re coming from sceneA or sceneC and the only way to get to sceneC is from sceneB and sceneD.

If this is the case, I would put code in sceneC that would show the text objects and in sceneD that hides the object.  Since you will create the text in main.lua (or sceneA), you only need to hide it when you get to sceneD. You only need to show the object when you’re going back to sceneC.  You can use the .isVisible to show/hide the object. If it’s already showing, setting the .isVisible property to true won’t cause any problem.  I wouldn’t bother deleting/recreating the object, just show/hide it.

Now if you have the ability to jump to sceneB from sceneF, then you will have to show/hide in each scene, but it’s one line of code per display object.

Rob

Rob said: Now if I understand correctly, you can only change scenes by going from sceneA to sceneB to sceneC etc. and you can only go backwards the same route.  That is there is no direct path to sceneB unless you’re coming from sceneA or sceneC and the only way to get to sceneC is from sceneB and sceneD.

==================

Thank you Rob for your help. Unfortunately I didnt make it clear enough, sorry for the misunderstanding: I can go from any scene to any other scene, otherwise I would have chosen the idea you just posted. So, if I understand you correctly, in this case I really have to either hide/unhide or remove/add it in every single scene. Ok then, I’ll do that :slight_smile:

Am I right that hide/unhide would be better performance-wise (since creating/removing might take longer), while creating/removing would - in theory - be better considering ram-usage? I have absolutely no idea how “ram-expensive” storing the title in the background and making it visible in relevant scenes would be. Is this something I should consider or could I like store hundreds of textobjects in the background and Corona would just yawn? :slight_smile:

If you’re going to be using an object frequently, it’s always better to create it once and use it many times unless the object consumes a lot of memory.

Rob

And I guess a simple textobject does not count as memory-consuming! All right, thanks for your input Rob

It’s a display object which means there is texture memory allocated and Lua memory (it is after all a table). But it’s not like you’re creating 100 of these. There will be a little memory bloat, but I doubt it will be significant.

Rob