It looks like they could be replaced by setVariable/getVariable.
http://docs.coronalabs.com/daily/api/library/composer/setVariable.html
Thanks for the link, Max.
Kerem, they show composer.setVariable() and composer.getVariable() – maybe those take the place of params.
Says you can set a variable and then retrieve it from any other scene.
Jay
It looks like composer will also support params.
If the params option was specified when calling composer.gotoScene(), composer.showOverlay(), or composer.loadScene(), the same value will be passed to event.params so it can be accessed by [createScene][api.event.scene.createScene], [enterScene][api.event.scene.enterScene], and [willEnterScene][api.event.scene.willEnterScene] event listeners for the scene that is being loaded.
If the params option was omitted when calling said functions, the value of event.params will be nil.
http://docs.coronalabs.com/daily/api/event/scene/show/params.html
Great. Thanks for digging that up. I had seen the set & getVariable but params is whats in my code so less rework I suppose. Time will tell…
Brent, releasing incompatible stuff to the public without prior warning and documentation is not really a best practice and is a sure way to get customers “speculating” and feeling frustrated. I have also purchased JA’s video course and feel for him Can we get some much needed bug fixes now?
Well… I know why I am still using the last G1 daily build for my old and some new(!) projects.
Using anything but the latest build gets all your bug reports rejected summarily. I know why I am not submitting any bugs reports anymore 
We respectfully asked that you not speculate on this and wait until we could provide you with the answers to your questions. Here is what I can tell you:
Composer is a -new- library that will live alongside Storyboard. Think of it as “Storyboard 2.0”, but because we are changing and improving things within it, we decided to provide a different migration path for you. With Widgets 2.0 and Graphics 2.0, we had to make breaking changes because of their close relation to the core API. Composer is somewhat different and it can live alongside other Corona libraries. Once we release it officially, your existing Storyboard code will continue to work, and developers can move to Composer if it makes sense for them. Internally, we intend to move to Composer in our samples, guides, new tutorials, etc.
Composer is a good thing. It’s giving us a chance to re-factor some outdated Storyboard code to make it more sustainable going forward. This will also allow us to more easily address bugs and add new features going forward.
This thread has gotten contentious to the point that we’re going to lock it. Please respect our request and refrain from speculating on this until it’s announced.
@atanas, regarding your point about bug reports: this is not our policy and we feel a need to clarify so. In fact, nothing has changed in regard to our bug submission policy, except that now we are requesting full and complete examples along with bug reports which show the bug occurring. Previously, users would too often submit a “main.lua” file with no supporting files, but the issue was caused by something in their “config.lua” or “build.settings” file. Determining this was not an efficient process, so we are now reasonably requesting that users submit zipped mini-projects along with bug reports so that we may easier determine the cause.
We have not been “rejecting bugs” that are not tested with the latest Daily Build. If you supply a build number, we will test with that build in addition to the latest Daily Build to check if the bug has already been fixed. In some cases, if you supply a bug report with an old, outdated build, or one that’s older than our public release build, we’ll ask that you test your code with the latest public build.
Regards,
Rob & Brent
any dev’s seen this before?
Which sample app are you talking about? And which build do you use?
Latest build - 2146 - open simulator > create new project > app >
local composer = require( "composer" ) local scene = composer.newScene() function scene:create( event ) local sceneGroup = self.view end function scene:show( event ) local sceneGroup = self.view local phase = event.phase if phase == "will" then -- Called when the scene is still off screen and is about to move on screen elseif phase == "did" then -- Called when the scene is now on screen -- -- INSERT code here to make the scene come alive -- e.g. start timers, begin animation, play audio, etc. end end function scene:hide(event) local sceneGroup=self.view local phase=event.phase if event.phase == "will" then -- Called when the scene is on screen and is about to move off screen -- -- INSERT code here to pause the scene -- e.g. stop timers, stop animation, unload sounds, etc.) elseif phase == "did" then -- Called when the scene is now off screen end end function scene:destroy( event ) local sceneGroup = self.view -- Called prior to the removal of scene's "view" (sceneGroup) -- -- INSERT code here to cleanup the scene -- e.g. remove display objects, remove touch listeners, save state, etc. end scene:addEventListener( "create", scene ) scene:addEventListener( "show", scene ) scene:addEventListener( "hide", scene ) scene:addEventListener( "destroy", scene )Hm, interesting discovery 
Indeed, and I cannot find any support or information regarding it… Corona staff? anyone?
There will be information on this coming soon.
Rob
Ahh! Okay, thank you!
Seems like an improved storyBoard variant. Interesting news. Yet more code migration ahead of us it seems… Great job discovering this and letting the cat out the bag.
EDIT : I take it back… Not interesting news. Scary news… Just for fun I tried bunch of storyBoard API calls… see what I got :
WARNING: composer.purgeScene() is deprecated. This now calls through to composer.removeScene( true ) instead.
WARNING: composer.getCurrentSceneName() is deprecated. This now calls through to composer.getSceneName( “current” ) instead.
WARNING: composer.printMemUsage() has been removed.
WARNING: composer.purgeAll() is deprecated. This now calls through to composer.removeHidden( true ) instead.
On a positive note, seems like the deprecated API is now internally routing to the new equivalent code. This will certainly help ease the transition so thanks for that!
On a negative note, really Corona Labs? Just as we all got comfortable with the storyBoard and learned all the API now go do it all over again. What was it? Did you run out of urgent bugs to fix? I think not… I really wish you wouldn’t try to fix what isn’t broken while there are still major issues here and there. Cough, widgets!
I can’t wait to read Walter’s BAM! post for Composer on the Blog soon. I think I will start framing those things.
Kerem,
It’s way too premature to be trying to figure it out. Please wait until we provide more details before you form conclusions. Until then, enjoy your weekend.
Brent
Sure. Have a good weekend too.
“It’s way too premature to be trying to figure it out.”
Not if you make tutorial videos for a living.
That light at the end of the tunnel? It’s an oncoming train. <-- how I’m feeling.
Jay
Jay I feel for you. All these changes are devastating to your existing library of material. Look at it on the bright side… So many new things that so many folks need to learn. Maybe there is a silver lining somewhere in there for you. Just wondering when it will all stabilize though.