Tutorial: Handling Callback Functions in Modules

Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

In Corona SDK, many functions are asynchronous, meaning that they return control immediately to your program while they do their work in the background. When these events complete, they notify your program that they’re finished and allow you an opportunity to respond, whether it be to a touch/tap action, completion of a downloaded file, or data returned from facebook.request().

Normally you must provide a function to handle the returned value(s), and most of these functions are driven by events. In many cases, these functions take a single parameter called event which is a table that contains information about the completed event. These are referred to as callback functions.

This is easy to implement when your function calls are in the same module where you need to access the data. However, what if you want to modularize your code and you don’t have direct access to the function that handles the the call?

One solution is to code your module in such a way that you can provide your own callback function within the internal callback function. Consider this simple module:

This module simply fetches an image using network.download() and creates a display object with it. However, this happens in a module, and it’s likely that you’ll need to know the handle of that image in the module where you called this fetching function.

Inspecting the Function

This example function uses a mostly un-modified version of the network.download() example code which we simply wrap inside a module. The function itself takes a single parameter, returnHandler, which is the function that handles the return in your local code. In a more robust project, you’d probably accept additional parameters like the image URL to fetch, but we’ll keep it simple for this tutorial.

At the top of this function, we ensure that returnHandler exists and that it’s a function. If both are true, we store it in the module table M as the callback parameter.

Further down, in the networkListener callback function for network.download(), we call the function that’s stored as callback when we want to check the result of the download back in the module where we need that information. Also, notice that in the ended phase, the actual display object is added to the event table — this stores the handle of the image for your use.

Calling the Function

To call this function from another module, consider this simple routine:

In this manner, you can provide your own function (postImageFetch in this case) and use the event table however you want.


With this simple technique, you should be able to modularize your code and still have access to the data that you need.

Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0
Rob Miracle

Rob Miracle creates mobile apps for his own enjoyment and the amusement of others. He serves the Corona Community in the forums, on the blog, and at local events.

This entry has 6 replies

  1. Kerem says:

    Great tutorial. Thank you very much!

  2. JCH_APPLE says:

    Very useful. Rob has the ability to turn complex things into simple ones, his tuto’s are really great. Thank you.

  3. Nicely explained. I think I learned this the hard way.

  4. Nicely done. Very useful informaiton

  5. mort says:


    How would one handle removing the downloaded image?

    Would one use the “downloadedImage” handle or the “myImage” handle?

    Would there be an external reference issue to worry about in this case?

    • Rob Miracle says:

      You can just do a downloadedImage:removeSelf() and then nil it.