Ansca Corona Cross Platform Mobile Development: The Good, the Kind of Bad, and the Not So Ugly

By Jeff Fulton

 Ansca Corona For Cross-platform development

At Producto Studios, we have just finished a large 5 month cross-platform (iPhone, iPad, Android phone, Android Tablet) project using Ansca Corona as the API and tool kit. Corona is not a drag and drop style app builder, but a robust, subscription-based API built on top of the relatively simple, yet powerful Lua scripting language.

First, lets just say that working with Corona is very straight-forward, and the Ansca Team is constantly updating the API by adding new features while the developer community  adds new code modules that make creating games and mobile apps easier than ever.  Let’s break down our experience in using Corona for a Large-scaled (over 125MB foot print) application in to the Good, the Kind of Bad, and the Not So Ugly. ( Note: These can also be applied to building any size application)

The Good.
1. The Corona API lets you build true cross-platform applications that target the major devices (iOs 4.3 and above, Android 2.1 and above, and now Kindle Fire) with a true SINGLE code base.

2. With a few lines of code in your build.settings file you can truly scale your application to any device screen. (see other sections to bad and ugly parts of this)

3. The API includes many concepts that Flash developers will be familiar with such as MovieClips and Spites. For example, using a PNG sequence from Flash to create an animated MovieClip or as a Sprite is a snap. There are also great tools such as Texture Packer (not free, but reasonably inexpensive) that will output to Corona (after dropping a swf into it) to make this even easier.  There is even a layering concept called “Groups”, and simple dynamic masking (not fully realized as of yet, but it does have its uses).

4. The API includes many Audio and Video functions and more are being added each day. Audio is completely supported with record and playback features built-in.

5. There is  physics engine (built-in) that is based on Box2d.

6. More and more interface widgets (such as the awesome newly re-designed scroll-pane) are being added (or improved upon) to each new daily build.

7. We found that letting the designers work in Flash (a tool they are comfortable with) and exporting animations was the best way for them to get assets into a Corona project.

8. You don’t need a run-time such as Air for your application to run on the platform. Each application is built with native API’s (Java for Android) and xCode for iOS.

9. Loading assets from remote servers either as files or as Server data streams (XML from a web service) is simple and straight forward.

10. The API integrates with the Flurry mobile analytic engine very simply and easily.

11. There is a new set of “project” settings that allow the user to set up and use some pre-created templates when first starting an application.

12. Can integrate with  OpenFeint, Papaya (Android), and Game Center

13. There is a nice transition manager that is not unlike Tween-lite for AS3.

14. Can integrate with Facebook

15. Has currency and in-app purchase APIs

16. Can directly use SQLLite3 in app.

17. Has access to the operating system, photo and video libraries on the device (and much much more)

The Kind Of Bad
1. Lua. Lua is not a bad scripting language, and if you master it, it can be very useful for building applications. Using it to create large applications is not for the feint of heart and even though a very experienced Lui developer can create a some-what bastardized OOP architecture with it, a large scale project would have benefited from even Javascript as an option rather than Lua.   That being said, Lua is a flexible language with a single (JSON-Like) data structure that is simple to learn but difficult to master.  Lua is a like programming in a combination of C (not C++) and BASIC.  It does give the user DIRECT control over Garbage Collection, which is and will be needed to get larger scale apps, that use a lot of texture memory (and code memory),  to work on some of the older devices.  Plus, it’s just cool to be able to see the current memory usage at any time and to clean up objects floating around in memory with a single call.

2. Video. While the video functions in the Current version of the API are sufficient, they are not any where as good as Flash. First off, the API relies on the video player of the device, and when a video is playing, complete control of the application is lost to the device’s player. When the video is complete or the user stops the video, you can create a call-back function that will run when your app returns to active duty. Video cannot use flv files so Green-screen videos such as those prevalent in Flash applications are not possible to do. This can be solved with PNG sequences, but those use A LOT of texture memory.  You also cannot record video or access the web cam of the user.

3. Up until recently the “widget” section of the API was pretty sparse or lacking in basic functions that you needed to roll yourself.  A good example is the ScrollPane widget that up until a recent “daily build” in January could only be used vertically or take up the entire screen. The new version is very useful though. The API team at Ansca is very responsive to the comments on their message boards and do everything they can to add and fix features in a timely manner.

4. YOU MUST SUBSCRIBE to get all of the features of the product. You can’t be content using the free version for development and then purchasing a subscription right before building as you will miss out on many features added in daily builds.

5. For a large scale project, the The Corona Project Manager is a must. It’s an extra $75, but it is a very useful tool for create applications. It really should be built in to Corona though.

6. The debugger is only adequate at best.

7. Assets are all png and jpg files (unlike Flash Vectors) and this creates very large foot-print apps that use a lot of texture memory. You must be aware of each byte byte you are using and dispose of it properly. If not, you run the risk of apps dying when memory runs out.   mp3 files are supported cross-platform, so music and sound effects can be small files sizes as long as you understand that mp3 files will not loop playback with out an audible silence.

The Not So Ugly
1. To build a true cross-platform and screen-size app, you must start with the largest screen-size and then create a “buffer area” that will show up on the larger devices and will be hidden on the smaller screen devices. There is more than one way to skin this cat though, as there you can dynamically detect screen size and load in various assets accordingly, but this creates a lot of extra code and extra assets in the final package.

2. Without the Project Manager (extra $75 cost), creating a cross-platform app means shoveling all files for the app into a single folder (Android will not compile with items in sub-folders).

3. The Audio API is very robust, but it has some bugs that  require the user to ensure that a sound is not playing before it is disposed from memory. In some cases, disposing a sound while playing will crash an application.

4. The debugger is only adequate at best (I know I said this before).

All in all though, Ansca Corona is a one of the best (if not the best) cross-platform mobile development tools on the market.  It is always evolving, adding new devices to publish to and becoming more awesome.   We could not have completed our project on-time without using Corona. Without it, the cost and time to develop for both Android and iOS (let alone the various screen sizes) would have nearly doubled the cost and time to market for our project.


If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.
This site is protected by Comment SPAM Wiper.