This documentation is very incomplete ; proceed at your own risk ! Overview

A collection of thoughts outlining how the architecture of the library came to be.

Corona Design Decisions Object Class The object class assumes that the object being created will, at some point, be shown on the screen. With this in mind, the object class automatically creates a display.newGroup() object for each instantiation of the class. This serves as the "view" of the class, and provides a "canvas" on which to work. Typically other Corona display objects will be added to this group.

I tried to use the same newGroup() object as the base of Object, but I wasn't able to inherit properly and use the object as a pure Corona display object. One instance that that insert() wouldn't work if used on a object subclassed from newGroup().

The second typical paradigm is that object classes ( buttons, menus, etc ) will want to emit events to those that are interested. Any class subclassed has the ability to listen for and emit events.

This is like Flex code behind.

underscores serve to mark protected or private methods and properties. don't touch unless you know what you're doing.


don't use corona subclass directly. . maintains integrity of corona object namespaces. . allows more flexibility in object hierarchy . assumes that the object is used with Corona, and visible. . creates API to interact with display object Lua Design Decisions Don't use Lua module packager I opted not to use the module() incantation. There seems to be opinion that it isn't the best way to create packages. In addition, it's not needed at all to get the job done. ( see section Modules )

Instead, I use the style which is used in the Javascript world.

local M = {}

function M:test1() end function M:test2() end

return M It's simple, easy to understand, and there aren't any "black box" function calls to use.

have certain methodology:

init, createView, initComplete