Author: Jonathan Beebe

There’s often confusion as to what exactly happens when external modules are “required” into your code, which leads to further confusion and unexpected behavior when it comes to things such as Storyboard Scenes or even custom modules of your own.

Today I’m going to guide you through a series of exercises (with explanations) that should illustrate exactly how modules work in Lua, so you get a full understanding of when the code in your modules is executed, including what code is not run when you call the built-in require() function.

The Storyboard API, while very powerful and flexible, can admittedly seem very confusing to new users, and especially those who are coming from a 3rd party scene management library, such as the Director Class.

Today, I’m going to walk you through the most basic storyboard usage for those who want the Storyboard API to be as simple, and work similarly to, the Director Class. While packed full of useful advanced features, not all of these features have to be used (or even understood at first). This tutorial will show you how to get up and running with the Storyboard API as quickly and easily as possible.

Whenever your app is taking too much memory, the OS will first issue what’s called a “low memory warning” to give you a chance to do something—such as free up memory—before your app is forced to quit. If your app is forced to quit, from your user’s perspective, your app will have crashed and quit (possibly causing a great deal of frustration).

In today’s tutorial, I’ll show you how to respond to these low memory warnings, and recommend things you might do to prevent crashes from occurring (and possibly even preventing low memory warnings altogether).

NOTE: Low memory warnings are currently unreliable on the Android platform, so this tutorial will focus mostly on iOS, though the preventative measures will apply to all platforms.

The reason why this can be confusing is the fact that most storyboard scenes are represented by their own module (e.g. scene1.lua, scene2.lua), and it can be difficult to determine what the best way to share data across multiple files is, especially since scenes can be created and destroyed at any time.

In today’s tutorial, I’m going to show you a few ways that you can share data between scenes, and manage a singular overall “state” in your app despite the loading and unloading of multiple scenes—no matter how many you might be working with.

One of the most confusing aspects of Corona’s storyboard API is the purging and/or removal of scenes. What’s the difference between purging and removing? What does it mean to “purge” a scene anyway? Those are just a few of the many questions we receive often.

Today, I’m going to attempt to clear up the confusion by first giving you a high-level overview of what’s going on behind-the-scenes when purging and removal goes on, and also show you a few examples along the way.

Something that’s becoming increasingly popular is the ability to “pick up where you left off” or stop and resume with hardly any friction. More and more, apps are starting off exactly how you left them—and that doesn’t exclude mobile apps (in fact, mobile is arguably what inspired this behavior).

Having your apps start off where your user left them is also known as “state saving”, and that’s exactly what I’m going to cover in this tutorial. As with any tutorial that’s posted here, I encourage you to take what you learn and build upon or modify the code to suit the specific needs of your app.

Something that isn’t clear by studying Corona’s included SampleCode or any of the other examples and tutorials on this website is the concept of organizing projects. We’ve sort of just let you know that everything goes into your project folder and sent you off on your way—and oh, sub-folders are supported. That’s about all we’ve said on the subject up until now.

However, as your projects get bigger, that may not be quite enough. With more and more resources are being added to your project, such as audio files, images, videos, Lua modules, etc. it can add a whole new layer of complexity to the development process—complexity that isn’t at all necessary.

This tutorial is by no means the end-all to Corona SDK project organization techniques, but it will introduce you to an effective one that you can tweak at your heart’s content to suit your needs perfectly.

A little over a year ago (in June of 2011), I went over the Corona Event Model, and explained exactly what events are in Corona, when they occur, and how you can “hook” into them to take advantage of some of Corona’s best features.

However, in the previous article, I kept the subject-matter focused on the built-in events associated with specific API’s that are provided out-of-the-box in Corona. What I didn’t mention is that you can define your own custom events, and have objects listen for when those events are dispatched (which you have complete control over as well).

This tutorial will walk you through defining and dispatching custom events, so you can begin applying the knowledge to your own games and apps.

This week’s tutorial is going to be a little different. Rather than go over yet another awesome Corona feature, I’ll instead be walking you through another aspect of Corona development that’s arguably just as important (if not more important) than any one specific feature of the SDK. What you’ll be learning about today is something you’ll undoubtedly use in every single Corona project you work on, and that is of course is the Corona SDK API Reference.