Wednesday FAQs: Upgrading the Corona SDK Simulator

12 June 2013

Wednesday FAQs: Upgrading the Corona SDK Simulator

It’s Wednesday and time for another frequently asked questions (FAQs) session. Here are some FAQs about upgrading the Corona SDK Simulator.

1. Do I have to uninstall Corona SDK when upgrading to a new version?

No, you don’t to have uninstall on Mac or Windows.

2. Do I have to deauthorize Corona SDK when upgrading to a new version?

No, you don’t have to deauthorize when installing a newer or older version. The only times you need to deauthorize is if you plan to use Corona SDK on another computer and you already have two computers authorized, if you change the email address associated with your Corona SDK license, or if you plan to reinstall the OS on your computer.

When you upgrade (or downgrade) a version of Corona SDK, the newly installed version uses the account settings already stored on your computer (either in the Windows’ registry or Mac’s plist file).

3. When do I need to contact Corona Labs’ support to deauthorize the machines on my account?

There are very few times when you need to contact Corona Labs to deauthorize the machines on your account. If you forgot to deauthorize your machine, please contact us if you have changed the email address associated with your account or if you have reinstalled the operating system on your computer. Remember: to avoid these issues, don’t forget to deauthorize your computer(s) first.

4. Can I have more than one version of Corona SDK installed?

The answer depends on the platform you’re using.

On Mac, you can have many Corona SDK builds installed at the same time. The trick is to rename the CoronaSDK folder in the Applications folder after installing a new version. On my machine, I append the build number to the end of the folder name to keep them separate. For the last public build #1137, I would rename CoronaSDK to CoronaSDK–1137.

For Windows, you can only have one version of Corona SDK installed at a time. You don’t have to uninstall when installing a newer version, but if you need to install an older build, you have to uninstall first.

5. FAQ Tip of the Week

The last public release (1137) added lots of bug fixes and some much needed features (Build 2013.1137 Release Notes). One of the features you may have missed is the ability to retrieve the app name (using system.getInfo). You may wonder what advantage there is to retrieving the app name. Here’s one example.

When debugging an app on a device, I like to enable the Runtime popup message feature (setting showRuntimeErrors = true). I want the popup for my debug builds but not when I submit it to the App Store. This involves modifying my project files and having to remember to remove the code when I’m ready to release the app.

My solution is to add some code to the config.lua file to control the state of showRuntimeErrors without having to modify my project files.

The above code sets the showRuntimeErrors key true or nil depending on the app name. If the app name contains “debug” anywhere in the name, showRuntimeErrors is set to true. If the string is not present in the name, it’s set to nil. So if my app is called BubbleJump, the debug code is enabled if I append “-debug” to the end of the app name in the Corona SDK build window. Seeing BubbleJump-debug is also a good reminder that this is not a production-ready app. I chose “-debug”, but you can choose whatever you like.

You can go one step further by adding the following code at the top of the main.lua file.

You can now use the debug variable to enable debug statements in your code. You can even use it to disable the print statement when debug is false/nil. This allows you to control the debug flag at build time instead of having to modify your project files and run the risk of releasing a version of your app with debug code enabled.

One note of caution about using debug for a variable name. If you do use debug, make sure it’s a local variable and not a global one. Lua does have an internal debug library that you will override if you define debug as a global variable. Doing so will suppress any runtime error output and print output that your code may generate. It may be better to use dbg or _debug instead.

One final note: I mention public release #1137 in this blog post. This release replaces build #1135 and fixes a potential issue with plugins.

That’s it for today’s questions. I hope you enjoyed them and even learned a few things.