Is it possible to write up code in Corona and convert it to Android native? Is it proprietary?
Jump to content
No. It isn't translated to java in the way you think. In most cases, Corona is creating OpenGL objects that run inside their engine from the Lua. I am fairly sure they create these on the fly. Otherwise, they would have to maintain conversion code for all the platform they support including the simulator and the ios emulator. When you build they take your lua code, the appropriate corona engine and the other bits (native plugins, native UI elements) and package it for the appropriate platform. No code conversion is taking place.
Corona is not a translator. It's a combination of things.
First, Lua is a language that you write, but binary C++ code parses the Lua and executes it. It handles memory allocation, doing math, etc. Many items call things in the standard C libraries. For instance, string.format() is using the standard C library function sprintf() to do its work. Display objects are also C++ based code that turns your Lua statements like display.newImageRect() into various OpenGL calls to create an image on screen and manipulate it.
Next there are operating system level items, like opening the camera to take a photo where we've written that code in Java for Android, Objective C for iOS and then part of that code allows Lua to be bridged to the Java/Objective C code.
When you build the app, we output an Android binary package that includes any images and audio files, the necessary Android package XML files (i.e. AndroidManifest.xml) and packages it into a .apk and code signs the file.
The Simulator does all this work for you, so you only have to worry about your Lua side code, providing artwork and learning our API calls. Hit a button, get a valid APK file.
If you need more, we do offer "native" builds, where you use a special project that we've set up that has a folder for you to put your Corona Lua code, images and audio files in. But you use Android Studio to build the project instead of the Corona simulator. This allows you to write your own Java code and bridge it to where your Lua code can call your Java routines. You can also make your own Java-based plugins that your Lua code can call as well.
My opinion only: All of it is not really Corona specific. You can search on youtube for how to build native android apps, get familiar with gradle, how jnilibs work in an android project, how to run extra scripts while building and the structure of a typical android project. Once you learn all that the structure and how the native build works will be easy to understand. All of the corona magic is inside a set of .so files the rest of the native build is standard android build stuff, a little code glue, and some scripts.
Getting away from all that is why I ended up in Corona and doing mostly Corona Simulator builds.
This tutorial is really, really old. It's not based on our current Corona Native Android Studio builds, but the old Enterprise based ANT command line builds. This is one of the reasons this tutorial is not available on our site, but someone cloned it, so you still can access it:
Most of the tutorial isn't going to be of any use to you at all, but if you scroll down to the "Do something interesting" section, that's where you can find the actual Lua, Java and bridge code between that shows how to talk to native API's from Lua. It's a very simple example. You would of course still have to copy the latest App template package from the Corona/Native folder to your working project, update the AndroidManifest.XML and such in Android Studio.
The App project should work in up-to-date Android studios.
I tried it but I get this error on Windows 10.
Greg, not really. If you want to call api calls like display.newImageRect(), you're going to need to do that in Lua with at a minimum of a main.lua and config.lua. Anything that's going to be part of the OpenGL hierarchy will have to go through the Corona C to Lua bridge and be done in the Lua side of things.
Corona Native lets you use Xcode or Android Studio to build apps without the simulator. You still have your Corona project which is going to be all of your Lua code. From there, if you want to do offline builds, you can with your 100% Corona/Lua code. Xcode/Android studio will take care of the packaging and code signing, linking in the Corona libraries etc. While there are benefits, in particular, if you don't have a good network connect, to doing native builds, the Simulator using our build dialogs really makes things simple and generally faster to do builds.
CoronaBuilder is basically a command line tool that does the building for you. Basically, you can provide all of the build dialog parameters on the command line. Again, most people don't want to mess with life on the command line, but some people need to batch build multiple Corona apps and command line builds can save them time.
Now all that said, the other thing that Corona Native lets you do is twofold: 1. It lets you use some C++, Objective C, Swift or Java code with your Corona app. Let's say you need to access some feature that Corona doesn't support (like turning on the camera flash/LED). You can use Xcode/Android Studio, have your main Corona app and write some native code and create some functions that bridge them to Lua and you can then call those native functions from Lua. 2. Likewise, you can use similar technology to create a plugin (which has the native functionality and bridge code, but in a more portable method). If your plugin is useful enough, you can submit it to the Corona Marketplace for others to use. You can also purchase self-hosted plugins which lets you build plugins for yourself and use the Simulator for building.
I guess I wasn't clear enough. Your Lua code is never converted to C code. We embed a Lua interpreter in your package and your Lua code is processed by that interpreter.
You can think of Lua as being two parts: 1. The Lua interpreter. This is the part that lets you write for loops, if-then-else statements, assign values to variables, write your own functions, create tables of data etc. and 2. The C to Lua bridge. This provides your native side with a set of functions that lets you push values from your C, Java, ObjC code to the Lua side and fetch those values from Lua so they are available to the native functions. This bridge also lets your native side code generate events that can be caught and processed on the Lua side.
Lets take a simple example. Lua knows nothing about OpenGL and Texture memory, so a function like display.newRect() was written in C++, talks to a C based OpenGL library and creates a basic rectangular texture. When you write:
local myRect = display.newRect( 100, 100, 25, 50 )
The values for x, y, width and height are pushed on to the Lua stack and it calls the C++ function for creating a new rectangle (something one of our engineers wrote in C++). That C++ function will pop the four values off of the Lua stack, call the OpenGL function to create the texture and put the rectangle on the screen and then it pushes the address to the display object back to Lua and it gets stored in your myRect variable. Obviously, there is more going on than that to create a display object (setting up remove methods, finalize methods, fill color methods, etc.)
So nothing is being converted, just being run and calling functions. Objective C is just C with Apple's library of functions and some additional Object-Oriented syntax going on (It's a hybrid of C and Smalltalk.) On the Android side, Lua knows how to bridge with Java in addition to C/C++. So display.newRect() is still done with C++ for Android, but calling native.newTextField() would be calling a Java function through the Lua bridge.
Hope this helps.
Community Forum Software by IP.Board