Bugs

In my last post, I talked about making our bugs publicly available. It’s not ready for prime-time, but I did want to give you a preview (see screenshot).

We structured it so that you can see the recently closed bugs, the ones in our queue, and the ones in our backlog.

This way you’ll be able to see if the issues as the Corona engineering team sees them. If you’ve submitted a bug and it’s been verified as an issue, you’ll now be able to see where it sits in the engineering queue.

We’re still working some kinks out so in the mean time, let us know what you think!

Next Stable Release

We officially kicked off our bug fix cycle three weeks ago. For those of you keeping track of daily builds, we’ve been making steady progress on some of the most annoying bugs and regressions. We have closed over 70 high priority bugs, and we think we’ve made great progress in daily build quality. We really do appreciate the feedback you guys have been giving us on them.

We are still fixing bugs this week. At the end of this week, we will have a candiate for a public release. After that, we will be doing final testing to get to an official public release. We expect that to happen within 1-2 weeks.

More Stable Daily Builds and Frequent Public Releases

Some of you may be wondering what happened to the 2-on-2 schedule (2 weeks of features followed by 2 weeks of bug fixes). It’s something we’re very serious about. What we decided to do was put the feature cycle on a holding pattern, and instead, extend the bug fix cycle longer than normal. Why? Because it was important that we have a solid release out before we can make the 2-on-2 cycle a working reality. (For the math geeks, the 2-on-2 is the “inductive” step; the solid release is the base case.)

At the end of each feature/bug 1 month cycle, we will be “blessing” a daily build, meaning you should feel very confident about shipping your app with that particular build. In addition, every 3 months, we aim to deliver an official public release. In either case, you’ll be able to more comfortably take advantage of all the latest Corona features.

Roadmap?

Yes, the elusive roadmap. Next week, we’re going to put a static, preliminary version of our roadmap in our forums. It will be open to your feedback. Soon after that, we’ll be taking this one step further and provide a way for you to vote on the features you think are important. We’re still working out the details but something along the lines of subscribers being able to select the top 3 features they want the most.

* * *

I know a lot of you are passionate about Corona. Sometimes we get pretty raw feedback publicly or privately. Other folks shy away from that, but I want you to keep ‘em coming!

We’re all trying to do the same thing which is make Corona the best development platform on the planet!  Just keep in mind that sometimes it’s a game of inches

Things that immediately come to mind are things that cause your app to become “suspended” such as the user receiving a phone call, or pressing the “home” button on their device (your app is still running in the background, but in a suspended/paused state). What about when the user comes back to your app while it is suspended, or when your app exits completely?

All of those things are handled by “system” events in Corona, and that’s what I’ll be going over today.

Event Listener

Before you can start monitoring system events in your Corona app, you need to set up a listener function, and add a “system” event listener. If you’re not familiar with events in Corona, I suggest you read The Corona Event Model Explained document before continuing.

The code below—commonly placed at the end of main.lua—shows how to setup your event listener, and also add it to the global Runtime object (the only object that can listen for “system” events).

applicationStart

The above code example shows how to test for the “applicationStart” event type in your system event listener.

You app will receive an “applicationStart” event when your app launches (from a closed/cold state, not a suspended state), and after the code in main.lua has executed.

applicationExit

The “applicationExit” system event is dispatched just prior to your app quitting (e.g. not suspending, but fully closing). This can occur from the user explicitly, or if the operating system’s task manager tells the app to close for whatever reason (usually due to your app being the least recently used, in low memory situation).

Things that this event is most commonly used for is to do any last-minute data saving, closing open database connections, etc.

applicationSuspend

I touched on this briefly already, but if the user receives a phone call, or anything happens that causes the user to have to switch out of your app on their device, or if the user presses the “power” button and puts their device to sleep, your app will go into a suspended state (but will not quit).

Prior to going into this suspended state, an “applicationSuspend” event will be dispatched, which gives you a chance to do things such as pause the game (so the user will be at the pause screen when they come back, instead of on the verge of being defeated!), mark the time (for any time-tracking functionality), pause/stop any timers and/or transitions, etc.

applicationResume

Speaking of your app being suspended, you also have a chance to “do something” whenever your app comes back from the suspended state, which is where the “applicationResume” event comes in.

Putting it all together

The above is a barebones system event listener, which you can actually use as a template. Of course, what you put into the individual if/else blocks is completely up to your app.

If you pay close attention, you’ll notice almost every commercial-grade application or game makes use of one or more of the system events mentioned in this tutorial—and for good reason: they are not only absolutely necessary for some apps, but they can be leveraged to enhance the user experience tremendously for many apps.

Before releasing your app, take a moment and think to yourself, What should my app do when it goes into suspended mode? When it comes back? Before it closes? And you’ll likely find a way to make your app even better, or perhaps solve a problem you didn’t know the solution to prior to learning about system events.

Sparky the Shark features beautiful illustrations, unique musical backgrounds and incredible interactive elements that keep the reader’s attention throughout all 33 pages. It was also fun to discover the hidden animations scattered throughout the book. For those of you who remember Mr. Potato Head, you’ll also love the bonus ’Dress Up Sparky Page’ – where you can dress Sparky in silly disguises, goofy teeth, hats and boggle eyes. You’ll quickly fall in love with the unlikely shark and penguin pair, and through their adventure, learn about the importance of always being yourself.

Fun for readers of all ages, Sparky the Shark is a beautifully crafted story of self-acceptance, kindness and friendship. The digital tale is available for download at the App Store and for Android.

Some notable additions include a few useful new features such as per-file iCloud backups, audio event changes, Storyboard “debug” mode and auto-purging capabilities, as well as many notable bug fixes in regards to native video objects, in-Simulator require() calls, display.newEmbossedText() inconsistencies, and more.

To see everything that’s been pushed into the daily builds, visit the Daily Build Summary page to get a complete rundown. Remember, access to cutting edge features and the latest bug fixes through our Daily Builds program is a subscriber-only benefit—so become a subscriber if you want to get the latest build.

Per-file iCloud Backups

For iOS 5 users of your app, iCloud will automatically backup the contents of your app’s Documents folder (system.DocumentsDirectory) for those who have automatic iCloud backups turned on. As of build 2012.812, you can now control which files are not backed up, and even check existing files to see if they are set to be backed up or not. This is accomplished with two new functions: native.setSync() and native.getSync().

Turning iCloud backups on/off for a specific file (the default value is on/true):

In the example above, value will be true/false on success/failure. If a failure occurs for whatever reason, err would contain the error message.

Now, here’s how to check if a file is set to be backed up or not:

In the above case, value would return true/false depending on the “iCloudBackup” setting for that file. If an error occurs, err would contain the error message.

NOTE: These APIs are iOS-only because iCloud is an iOS-only feature. Both functions will simply return nil if called on other platforms.

Storyboard additions

Other additions to build 2012.812 include two new storyboard flags (storyboard.isDebug and storyboard.purgeOnSceneChange), as well as a new debugging function: storyboard.printMemUsage()

storyboard.isDebug

If set to true, useful Storyboard-related information will be outputted to the Terminal in certain situations—which should aid in the debugging process. For example, if you were to attempt to purge a scene that does not have a “view”, you would get the following message in the Terminal:

Or, another example is when you call storyboard.purgeAll(). You’ll see a message like this:

Enabling/disabling these debug messages is as simple as setting storyboard.isDebug to true or false. The default value is false.

See the storyboard.isDebug documentation for more information.

storyboard.purgeOnSceneChange

By default, Storyboard does not purge scenes (e.g. remove the display group associated with the scene—known as the scene’s view) whenever you call storyboard.gotoScene(). Instead, the view is hidden and remains loaded in-case you need to quickly go back to that scene at some point in the near future. When the OS receives a low-memory warning, the least recently used scene will be purged automatically to ensure your app does not crash as a result of

For most users, this is adequate because you simply don’t have to worry about loading/unloading scenes and it allows your app to perform as quickly as possible by keeping things in memory that were recently used, and auto-purging scenes that were not used recently.

However, you may fall into two other situations:

1. Your scene’s are somewhat “heavy” and you do not want to have to manually call storyboard.purgeScene() or storyboard.purgeAll() on every scene change.
2. You are developing an Android app. Because most Android devices have unreliable low-memory conditions reporting, not manually purging unused scenes could result in app crashes in situations where Android fails to report low memory conditions properly.

For developers that fall into any of the two categories above (or both!), we have added storyboard.purgeOnSceneChange which will automatically purge all scenes except for the newly active scene on every call to storyboard.gotoScene() — in other words, on every scene change.

When this setting is enabled, Storyboard behaves a little more similarly to other popular scene management libraries such as Director class. The default value of storyboard.purgeOnSceneChange is false, so you’ll have to explicitly “opt in” to enable it.

Here’s a quick example:

See the storyboard.purgeOnSceneChange documentation for more information.

storyboard.printMemUsage()

While we’re talking about debugging and memory consumption, another useful function added to the Storyboard API is storyboard.printMemUsage(), which will print Lua memory and texture memory usage information to the Terminal (similar to how the Storyboard sample app does)—but only if storyboard.isDebug is set to true (Storyboard debug mode).

To get a more up-to-date account of Lua/Texture memory usage printed to the Terminal, you can use this function in conjunction with an enterFrame listener in main.lua:

You could also call the function outside of an enterFrame listener to get the Lua/Texture memory usage information for that specific point in time. As a reminder, this function does nothing if storyboard.isDebug is set to false.

See the storyboard.printMemUsage() documentation for more information.

Bug Fixes

In addition to the new features mentioned above, there have been several bug fixes and other changes pushed in as well, to include (but is not limited to):

• event.phase (with “stopped” value) added to Audio events.
• display.newEmbossedText() bug fixes.
• Storyboard bug fixes.
• Video objects now suspend/resume automatically with the application.
• require() statements in Simulator now consistent with on-device behavior.
• event.expiration added to Facebook login events.
• system.scheduleNotification() bug fixes

The above is not a conclusive list, but covers most of the changes since the previous daily build update. Once again, for a complete listing of all daily build changes, visit the Daily Build Summary page.

Who would have known this much stuff could be added/fixed in just a weeks time! If you want to get the build that includes all of the changes that were mentioned here (and more), as well as access to future daily builds with more new features and bug fixes, subscribe now so you can get the latest build today.

My name is Scott Adelman and I am the creator of the Kids Trucks educational app series. During the day I am a School Psychologist and Counselor at two elementary schools. In the evening and on the weekends, I am a father of twin three year old boys. At night, I develop educational kids apps using Corona SDK.

Working in education and being a father has given me a lot of insight into what will work for young kids. I am well aware of what all kindergartners need to know to be ready to enter elementary school. If you are looking to design pre-k apps, a great start is to take a look at a kindergarten-readiness checklist. Also, check out great apps for kids on the market, that are doing well.  They can give you insight into what parents want their kids to learn.

Positive reinforcement is incredibly important in an educational app for kids. Parents want their children to feel successful and encouraged. In most of my apps, I provide verbal feedback or applause when the child does something correctly. I have also started using Particle Candy effects to create things kids love (fireworks, paint splatter, sparkles to name a few). Another idea I was able to easily  implement in Corona was to allow parents to record their own positive encouragement statements.  Lastly, watch out for anything overly negative when a child does something wrong. I once tried out an app for kids that just buzzed at me when I answered incorrectly. This is not encouraging for children. I suggest keeping everything positive – if the child is wrong you can say “try again.”  If they continue to get something wrong, you need to teach them what the right answer is and how to get to it.

A simple user interface is essential as well.  Kids need to be able to navigate through menus without problem. Parents expect this too. If a child has to nag mom/dad in order to get to a particular part of an app, the parents will become annoyed.  For young children that can’t read yet, a picture menu is  ideal.

Kids make excellent testers for any of the apps that you create. I always play through my apps several times and get some friends to test them out as well before even thinking about submitting them.  Oftentimes, the adult testers will find nothing wrong with the app. When I hand over the iPad to my twin boys, they are more often then not, able to crash my apps.  Things children do that most adults don’t think of include: two kids touching the app at once, tapping quickly on multiple buttons, dragging fingers on and off the buttons, and touching the screen with entire hands. Given that young kids will often touch the screen with multiple hands or a whole hand, implementing multitouch through Corona makes sense, especially if your target is 1-2 year olds. Button placement is also important. If a button is in a place where it can be easily bumped by part of a hand or a finger, it will happen.

Bright colors and fun animations are vital for young kids. Graphics is an area that young children are less harsh on than their adult counterparts. For young kids, the visuals need to appeal to their  imagination and the artwork needs to be fun. My motto is when in doubt, put an eye on it. You could put an eye on a rock, make it dance around to a silly song, and most pre-k students would enjoy it.  The issue is that you are selling your apps to parents and most will not be searching for a dancing rock app. So be sure to create something that parents will be looking for. I also would recommend that you create art and coding, while keeping in mind that it could be used for future apps as well.

Creating educational kids apps is a fun and rewarding choice. Hopefully some of these tips can help you with your creations. As always, feel free to contact me with any questions, as I am happy share my experiences with others.

Scott Adelman

scottadelman@gmail.com

Question 1

When I create functions, I sometimes get error messages saying the function name was nil. I play with the code until the error goes away. What are the rules for getting it right?

Answer

Generally Lua requires “forward references” on variables if the variables are local. This means that the variable needs to be defined before it can be used. Look at the following example.

The above works because getTax was defined first.

The above doesn’t work because getTax is unknown and returns with a “nil” error. If you always define your variables or functions first (before being called), you won’t have any problems, but sometimes you can’t avoid it. Here is how you can fix

This code works because the placeholder for getTax was defined first and then set to the value of the function. The call to getTax is enclosed in a function so it’s called after the function is defined and assigned to the variable.

One common mistake is the following:

This will fail with a “nil” error. The reason is the “local” in front of the getTax function. We already defined getTax as a local variable and when you add “local” in front of “function getTax”, we are effectively defining a new variable, leaving the original getTax variable nil. You can prove this for yourself by adding print statements in your code to display the value of variables at different points to see how they are affected placement in your code.

You can avoid the scoping issue by making all your variables global. You do this by not including local before the variable name. This is fine for a few variables but not recommend if you have a lot of variables or if performance is an issue. It’s also not recommended if you are loading modules with lots of variables.

There is a lot more to variable scoping than what I listed here, so I recommend checking out Lua 5.1 Reference Manual.

Question 2

How can I get the HTTP status code when I access a website with native.webPopup?

Answer

The HTTP Status Code is returned by web servers and used to indicate if a HTTP request was successful or not. Here are some typical status codes:

• 200 OK
• 301 Moved Permanenly
• 404 Not Found
• 500 Internal Server Error

You can find more information here.

In Corona, native.wevPopup and native.webView don’t provide this HTTP Status Code, but network.request does (in the current Daily Builds). The event.isError field from either webPopup or webView is only set when it fails to connect to the server. If you access a page and get a 404 error (page not found), isError will not be set. You should call network.request the first time you access a web page to verify that it’s available or call it when you are not getting the proper results when you access a page.

Here is how you could use this in your code.

The code calls network.request first to access the web page. If the status code is 200 (meaning OK), loadWebPage is called and the page is loaded using native.webPopup.

Note: native.webView has been implemented on iOS devices to replace native.webPopup and is the recommended API for displaying web pages. We hope to have this API available soon on Android, Mac, and Windows.

Question 3

Does Ansca see my source code when I do a build? How secure is my project when it’s sent to your server?

Answer

During the online build process, our servers never see your raw source code — or for that matter any of your project images, sounds, or other assets. The Lua script is precompiled into bytecodes (stripping out comments, debug information, etc) before it gets sent to our server. The server embeds this data into the Corona engine, but never saves or archives it. By the end of the online build process, you will have an .app bundle or .apk file just as you would get if you had used the iOS or Android SDK yourself.

Question 4

I posted a bug on the API page (comments section) but it doesn’t get fixed. Why?

Answer

The “comments” section on the API pages is not the place to post bugs or ask questions. The intent of this section is to report errors or missing information in the API documentation.

If you think you found a bug with the API, please file a bug report. The link is at the top of Forum and Documentation pages. In the bug report please include as much information as you can about the bug, including the build number, the device, the OS and if this is a new bug, which build number introduced the bug.

It’s also important to include a complete (yet small) project file demonstrating the problem. Just supplying a few lines of code and saying this shows the problem means the bug report will most likely be place at the bottom of our “to do” list. We receive lots of bug reports and it takes time for us to create sample test cases to verify the problem. Sometimes, we don’t see the problem because of a missing config.lua or build.settings file. If the bug is important to you, please help us by sending in a working sample and describe how we can reproduce the problem.

We are working on a new documentation system and it should be available online soon. This new system will not have a “comments” section so you will need to post your API-related questions on the forums or file bug reports.

Question 5

I added print statements to debug my code, but I get a lot of “nil” errors. Is there a secret to avoiding that?

Answer

Most likely you have something like this in your code:

If lineNumber is nil because of a scoping problem or it has never been set, the print statement will fail saying, “attempt to concatenate ‘lineNumber’ (a nil value)”.

You can avoid the problem by using “,” to separate your variables.

This avoids the concatenation error, but it will add extra spaces before printing the value of lineNumber that you may not want

Another way to avoid the “nil” problem is to use “tostring”.

This converts the value passed to tostring into a string – no matter what it is (even nil values). This is great for number, strings, tables, display objects, etc. It allows you to control the print formatting without print errors.

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

A well-received session is the happiest moment for a meetup organizer. It was one such moment for the Redbytes Team on Saturday, May 5, 2012. The first ever session of  “Mobile App & Game Development Using Corona-SDK (MAGD)” held in Pune, India was well received and attended by around 36 people. It was a mix of students and professionals. Though the initial registration for the event was around 90 people, only 36 attended due to other technical events happening in the city. One thing we can very confidently say about those who attended, was that they were very happy with the contents of the session. What else can we say about a session that extended two hours past the scheduled end time?

This session was conducted by Mr. Altaf Rehmani, Founder & Technical Director at Redbytes Software Pvt. Ltd. Altaf talked about a range of topics including an introduction to Corona, the benefits of the product, development success stories and a few code snippets of an application using Corona. The session also emphasized the strong Corona developer community worldwide, the meetup forums created by Ansca Mobile for user support, as well as our local community, SDK Pune Meetup. The talk was followed by a Q&A session,  however participants freely asked questions throughout the talk as well. Some of the interesting questions that arose throughout the session centered on the licensing policy of Ansca, request for discounts, IP protection, and training options available on Corona SDK at Redbytes.

After Altaf’s session, Ali (Head of the Product & Game Development Division at Redbytes) took over. He gave an overview of developing games using Corona and showed a sample game creation to the audience, which convinced many participants about the ease of using Corona.

Overall, our event was a wonderful and educational session which gave a lot of exposure not only to the team at Redbytes but also to the participants. We are looking forward to our next session, scheduled for June.

For those who missed this session or for participants who want to take the next step towards learning about Corona, we have another session planned with the Computer Society of India, CSI-Pune Chapter on May 11-May 12, 2012.

For those who don’t know what LFS is, it’s a popular Lua library that allows you to perform common filesystem activities that can’t normally be done in plain Lua. Things like getting file attributes, creating and removing directories (folders), and iterating over files in a directory are all things that can be easily done using LFS.

Now that the daily build with it has been posted, I’ll walk you through some of the more common things you might find yourself using LFS for in a real Corona app. During the course of this tutorial, it might help to have a separate tab open with the LFS Reference.

Directory Scanning

Let’s say you were creating a note-taking app that allows users to create, save, and read text-based notes that are all saved to system.DocumentsDirectory. Sure, it’s easy to keep track of what the user does inside of your app. You could simply keep your own record of the notes within a “notes” table and update it whenever something is added or removed from the app’s Documents folder.

But what if you wanted to enable file-sharing through the iTunes interface so users can import and export their notes (go here to find out how to enable iTunes file sharing)?

The problem with that is, since the user is adding (and possibly removing) files to the Documents folder of your app bundle from outside of your app, the table you’re using to keep track of available notes is going to be inaccurate.

Here’s where LuaFileSystem would come in really handy. Every time your app is launched, you can use LFS to scan the contents of system.DocumentsDirectory and import any new notes! You could do this as much as you needed to ensure you have an accurate account of exactly what is inside that folder. Of course, that’s just one example where you might use this functionality. As with everything, it all boils down to the individual needs of your app.

Here’s an example of how to iterate over the contents of the app’s Documents directory using a simple for-loop:

Adding Folders

One of the things most commonly requested with Corona’s Documents, Temporary, and Cache folders is the ability to add new directories (e.g. folders) within them for easier organization.

If your app downloads several external assets and you would like to organize different types of files into different folders (or are working with lots of files with similar or same file names), being able to add and remove folders is something that’s absolutely essential.

Thankfully, LFS makes this easy as well. First, you’ll need to change the “current directory” to where you want to place the folder using lfs.chdir(), and then you’ll use lfs.mkdir() to actually create the directory.

Timestamps

Another thing you might need your app to do periodically is check the “last modified” timestamp of certain files, especially if you’re implementing any kind of syncing functionality, or even something as simple as keeping track of when the user last loaded a specific file (but didn’t necessarily change it).

Setting a new timestamp

Let’s say we have a file called “mydata.txt” inside of system.TemporaryDirectory. The user wants to view the file, but we want to set the timestamp for when the user last read the file (not just the last time they wrote to it).

In that case, we would simply “touch” the file. In doing so, we set the “last modified” timestamp to today/now. You can also set a custom “access time” and “modification time” with two additional function arguments, or leave them blank to use the current time.

Retrieving a timestamp for an existing file

Now, later on, let’s find out when the file was last modified. You can either use the “access” or “modification” property, but if you’re going by the previous example, they would both equal the same thing.

LuaFileSystem can do more things than what I showed you here, but chances are, your uses for it in a mobile app will fall into one of the three things I mentioned here. Fortunately, just about all of the LFS functions are straight-forward and easy to use. Please see the LFS Reference page for a complete listing of available functions and syntax information for each one.

As a reminder, this feature is available to subscribers only at the moment through the daily builds.

We began recognizing exceptional Corona-made apps in 2010, and we think it’s time for us to update our guidelines for longtime fans and introduce the process for new friends. We’ve always made an effort to select great apps that deserve recognition, but have at times been flexible with some of the other elements. We realize this has caused consternation (including very recently!) and we apologize about any confusion this caused. With these updated rules in place, we’re going to be more stringent when selecting future winners.

Each Monday, we’ll continue to feature an exemplary Corona-made app as App of the Week, selected from the Corona showcase. Apps will be picked based on a number of criteria including (but not limited to): design, sound, interactivity, originality, and usability. At the end of each month, we’ll let the Corona community decide their favorite, among the App of the Week winners that month. This “People’s Choice” will be awarded App of the Month.

We want to give Corona developers every opportunity to shine, and we recognize that there are a plethora of super impressive Corona-made apps that don’t get featured as App of the Week/Month. For this reason, we’ll start to feature additional notable apps throughout each month, reach out to the Corona community for input on their favorites, highlight Corona staff picks and more – stay tuned!

There are just a few requirements for eligibility:

• Your app must have been submitted to the Corona showcase.
• Your website must include the “developed with Corona” badge. (If you don’t have a website, you can add a “Developed with Corona” note in the “About” section of your Facebook page.)
• We ask that iOS winners please provide the Corona team with a minimum of 5 promo codes (for paid apps). We’d love to show off your winning app to friends, family and the community!

Now on to the best part: perks!

• App of the Month winners will get a 6-month extension on their Corona license; App of the Week winners will enjoy a 3-month extension.
• All App of the Month winners will be featured in a video demo on CrazyMikesApps.com; iOS App of the Week winners will get a mention on CrazyMikesApps, provided that they send over 5 promo codes for reader giveaways.
• All winners can take advantage of a 12% discount on marketing campaigns with Appsfire.
• We’re continuing to expand our partnerships, to provide benefits both to winners and to the general Corona community – stay tuned!

Please note, the above rules and perks are always subject to change. We will do our very best to keep you posted on major new developments.

To summarize: if your app is in our showcase and a “built with Corona” badge is displayed on your site, your app is eligible! All winners will be picked from our showcase, regardless of when an app is added. For example, if you added your app three months ago and we just discovered its fantastic gameplay, graphics, and the like, we may pick it as App of the Week at any point.

We love seeing all the fantastic apps you create, and look forward to sharing your accomplishments with the Corona community and beyond!

Editor’s note: We are disabling comments for this post, but would love your feedback. Please shoot us an email with any questions/inquiries/feedback! Inna@anscamobile.com

Impossible until now, that is. I’m happy to announce that coming soon to a daily-build-near-you is the highly-requested LuaFileSystem (LFS) library, which will enable all the things mentioned, as well as a little more.

What this also means is that awesome libraries that depend on LuaFileSystem, such as Penlight is now available for use in Corona projects! Please keep in mind, however, that some functionality of 3rd party Lua libraries may not be present depending on other dependencies, or if they try to do things that are not permitted on your target device.

LuaFileSystem will be available starting in the next daily build (we’re working on getting it posted). Once it’s ready, using it is simply a matter of adding:

…In the Lua source file you plan on using it. From there, take a look at the LFS Reference for a listing of all the functions and syntax (a tutorial will be coming soon!).

While you’re waiting for the build to post, subscribe now so you can get it as soon as it’s available. As a reminder, access to daily builds is a benefit extended to Corona subscribers only.

Bug Fixes

Speaking of daily builds, we pushed in a number of bug fixes over the past few weeks. Listed below is just a few of the major ones, but you can see a complete listing here.

• Fixed “bad builds” issue due to problems with build.settings (you’ll now get an error).
• Windows: stderr is now logged to the Corona Simulator output console.
• Several Kindle Fire and Nook-specific bug fixes.
• Several Storyboard and Widget bug fixes.
• Added workarounds for OpenAL suspend/resume bugs having to do with multiple OpenAL apps running at once.
• Fixed crashes that occurred when touching masked objects.
• Fixed post-collision mis-reporting bugs.
• Several internal OpenGL-related issues.
• display.newText() bug fixes.
• And more!

Once again, the above list is just a short sample—there’s too many to list! To see a complete listing of all the bug fixes, additions, and other changes, see the daily build summary page.

And if you haven’t already, subscribe now to get the latest build today.