The Corona Labs Site has put up a tutorial I wrote on the basics of updating mobile content at run-time:
Here is a brief summary:
We take the green tank tile sheet. And use it to place and animation on the screen:
Next we use ad XML file and the network.download() function in Corona to update the tile sheet to a new version when content has been updated:
This updates the tile sheet in the app:
All of the detail, code, and example files are on the Corona Labs Blog
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)
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
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.
I have a huge new gig that includes taking 100's of pre-existing Flash animations and using them to create a cross platform mobile application for a kids television network. The goal is to take the current Flash site (luckily in as3) and create a mobile version that will work on almost any mobile (iOS and Android only for now) device. We are using the iPad2 (1024x768) as our target platform and then creating a "bleed area" that will allow us to fit the app landscape onto every iOS and Android device we can find without doing any image swapping. We chose Corona for this development because it has the best combination of power and rapid application development. The Corona simulator and and scale = "zoomEven" build property makes this a dream to complete (so far).
Since Corona is so good at letting us target and test on 6 or 7 of the most popular devices, the cross-platform scaling issues I originally thought would take the most time upfront were handled in about 1 day. This gave me extra time ahead of schedule to test out both SpriteLoq (look for a future examination of this Corona-only targeted tool) and Texture Packer. My goal was to find a relatively simple method to create animations from all of the individual .fla and swf files and use them to populate mobile application . My goal was to then use Lua script to control them where necessary. An NDA stops me from showing the actual content that I am using for the app, but I have created a suitable (read ugly but functional) demo .fla that I can use to demonstrate a small portion of the power of Texture Packer.
I started with Texture Packer because it is cross-dev environment, so it can create data and tile sheets for use in Corona, Cocos2D, JSON (so I assume HTML5 but I have not had a chance to test it yet), Unity, CSS, AppGameKit and about 7 or 8 others. Texture packer is very powerful and can create data and tile sets from more than just swf files. You simply feed it a series of png, jpg or BMP files and it will be able to use them in the same manner as a .swf animation.
First let's take look at the .fla I used:
I created a very modest animation on the time line that simply changes the color of the Red Ball using a classic tween across 20 frames.
I then opened up Texture Packer and selected Corona TM SDK from the left-hand Data Format Drop Down and then dragged my texture_test2.swf into the Sprite area where it reads the time-line and attempts to pack my 20 frame time-line animation onto as small a space as possible.
The next step is to choose a data file name and then click the "publish" button in the center of the top button bar. This will create both a packed PNG file and a lua data file that describes the animation frames. I chose "jeff_fules.lua", but that was just me being cheeky. I should called it TexturePacker_rules.
To use the sprite, you must next fire up Corona, create a new main.lua in the same folder as the jeff_rules.lua and the jeff_rules.png.
The the main.lua file the we are about to create just be in the same folder as the jeff_rules.lua and jeff_rules.png (for it to work on all of the various build platforms).
--[[ main.lua Texture Packert test Jeff Fulton 2011 --]] require "sprite" display.setStatusBar(display.HiddenStatusBar) local sheetData = require "jeff_rules" local spriteData =sheetData.getSpriteSheetData() local spriteSheet = sprite.newSpriteSheetFromData( "jeff_rules.png", spriteData ) local spriteSet = sprite.newSpriteSet(spriteSheet, 1, 15) local jeffSprite = sprite.newSprite(spriteSet) jeffSprite.x=200 jeffSprite.y=200 jeffSprite:play() print ("jeff sprite");
Here is the small main.lua showing our sprite (you cannot see the color shift animation of course).
TexturePack makes it very easy to take Flash timeline or png series animations and turn turn them into cross-platform packed tile sheets for use in mobile and other applications.
Saving texture memory is a HUGE deal when building mobile applications and just this simple example was able to demonstrate that Texture Packer can cut the file size in less 1/2 when compared using the individual png files that are exported directly from Flash. Each of those files for my test were 1K, while the Texture Packer png file was 8K. That was a total savingis on 12K, which might seem in significant, but a 50%+ texture pack rate across 100's of animations will certainly give you a leg up when trying to target some of the older platforms (I'm looking straight at you iPhone 3).
If you are doing any type of mobile development I suggest you take a look at Texture Packer. It certainly is going to save me a lot of time and headaches on my current projects.