In this application development approach, the programmer uses an application editor to define an application by identifying and defining its objects. Objects are defined based on a set of predefined object types. These object types include:
- App – The application itself. Acts as a parent object from which other child objects “descend.”
- Applet – A set of instructions that performs an independent task. Runs asynchronously and independently from other applets.
- Audio
- Data – For storing information in memory.
- File
- Function – A set of instructions that performs a task within another applet or function.
- Timer – For performing actions based on time.
- Visual – Objects that are displayed on a computer screen, such as a button, check box, image, line, audio/video player, etc.
Each predefined object type includes predefined object attributes that hold values or instructions. The programmer may define values for various object attributes, where an attribute’s type determines what kind of value may be held by the attribute. The values of some attributes are determined automatically.
Objects and their attributes are visible to, and may be modified by, other objects and attributes.
The programmer defines relationships between various object attributes, either between the attributes of the same object or between the attributes of different objects, by having an attribute refer to another attribute. For example, instead of defining a literal numeric value for the X coordinate attribute of a button-type object, the value may be expressed as a function that refers to the X coordinate attribute value of another object.
Objects and attributes automatically receive a prefix indicating their type (e.g., .txtboxMyTextBox). Objects and attributes are organized hierarchically, where the application serves as the root object (e.g., appMyApp.txtboxMyTextBox:numHeight, although appMyApp is implied and need not be specified). Periods indicate a parent-child object relationship, while colons precede attributes.
Objects that are defined at design time are instantiated at run time. Object templates may be defined at design time from which objects are created programmatically at run time. Deinstantiating an object (by setting its :boolDestroyed attribute to ‘Yes’) causes its child and descendent objects to be deinstantiated and their memory locations to be deallocated.
An attribute’s value may be defined using literal values, references to other attribute values, with one or more commands that determine a value programmatically, or any combination of these. An attribute’s value is determined by evaluating the attribute’s contents when its object is instantiated at run time. If an attribute’s definition includes a reference to another attribute, the attribute’s value is automatically updated whenever the value of the reference attribute changes (unless the programmer specifies otherwise). Attributes may be user-modifiable (e.g., .btnMyButton:boolVisible) or not (e.g., .btnMyButton:boolOnScreen, which indicates whether .btnMyButton is currently within the device display area).
Events manifest as changes to attribute values. Thus, when .btnMyButton is tapped, both .btnMyButton:boolTapped and Device.Display:boolTapped are automatically set to ‘Yes’ and then to ‘No’. Event handlers are implemented via applet-type “watcher” attributes named :aplWatcher. The programmer chooses which watchers of which objects and attributes to employ by populating them with instructions that are executed when their associated objects or attributes change in any way. Thus, if the programmer places instructions into .btnMyButton:boolTapped:aplWatcher, these instructions are executed each time there is a change in the value of .btnMyButton:boolTapped.
Functions and applets are defined at design time as object templates and are labelled as funFunction and aplApplet. Each call to a function or applet at run time creates a separate instance of the function or applet that is deinstantiated when the execution of its instructions has concluded. A function runs in the same execution context as the caller, receives execution control from the caller and returns execution control to the caller, and may return a value to the caller as well. An applet runs independently from its caller and therefore cannot return execution control or a value to its caller. Thus, when an instruction calls a function, execution of any instruction following the calling instruction does not begin until the called function returns execution control to the caller. In contrast, when an instruction calls an applet, execution of any instruction following the calling instruction begins after the applet is called, irrespective of the execution of the applet’s instructions.
Programming instructions within an applet, function, or applet-type attribute may employ local variables that are visible to, and modifiable by, the applet/function instructions only, as well as local functions that are visible to the applet/function instructions only. Local variables and functions have a ‘Local’ prefix (e.g., Local.txtMyVar).
Hilltop 