RTC Magazine

Embedded computing has its roots in industrial automation and instrumentation. The vast majority of traditional systems was headless, or communicated with operators and other users through dedicated physical means—knobs, dials, gauges, indicator lights, etc. Today’s intelligent devices, by contrast, boast greater sophistication of operator interaction with user interfaces (UIs) comparable in scope and capability to desktop applications. Leading this trend are mobile computing devices like smart phones, in-vehicle (IVI) systems and home entertainment (media players, HDTV, DVRs and STBs). However, nearly every design domain, from factory automation to medical devices to aerospace systems and from networking equipment to Point-of-Sale, demands increasingly engaging user interfaces.

With traditional design methodologies, application code “owns” the particulars of UI implementation, determining the type, orientation, placement and other attributes of objects on the display (button, widgets, etc.). This includes the flow of their use and the callback code that powers those elements. The attributes of a UI design are thereby set in the original design and are only minimally mutable downstream, by channel partners, third-parties and end users. Some UI and application frameworks support theming—customization of color schemes, menu text styles, window frames, widget sets, etc. However, the fundamental structure and flow of an application UI remains set in stone—a closed box as imagined by the original design team.

Decoupling the UI from the Application

The concept of Autonomous UI design and implementation goes beyond custom themes, icon sets and color schemes common on many mobile phones and other intelligent devices. It entails letting developers bind custom functionality to individual UI elements via runtime scripting. It supports the addition and/or removal any item from an application UI, including images, videos and widgets without changing any application code, i.e., with binary images. 

An autonomous UI further enables existing applications to integrate reaction with new device events and capabilities, like shaking and orientation by adding an accelerometer, location and movement (GPS), and definable data and network events such as calendars, stock quotes, sports scores, wireless traffic, etc. It also lets integrators, operators and end users easily add new UI personalities at runtime without changing shrink-wrap application code (Figure 1).

Autonomous UI Architecture

Breaking out application and presentation code doesn’t require radical rethinking of the core application design. Application code can still solicit input and generate output.  It is still up to the application design team to determine how much control resides inside the application itself vs. the amount exposed to subsequent modification.

But decoupling does require specific support from the underlying graphical and multimedia framework. Key enablers of an autonomous UI include providing safe binding between underlying graphical system APIs and an external, open programming environment. One very good tool for accomplishing this is the Lua scripting language (see sidebar “Lua Scripting Language” p. 26). In addition, there must be a way to expose inventories of (public) application objects that implement UI functions. The decoupling mechanism must also support a protocol between presentation code and the application for information exchange.

It is also important to provide an open high-level API for developer use. It is of course the main point of entry for developers, and also simplifies translation of information between the language bindings using the protocol. At Fluffy Spider Technologies, we chose C in building FancyPants itself, and for underlying libraries. For building Autonomous UI code, we bind to the Lua scripting language at a high level, taking advantage of Lua features and rapid prototyping capabilities.

Real-World Examples

SMS Client – On a mobile handset, the device manufacturer will typically include a short messaging system (SMS) application, sourced from the mobile OS supplier, a third-party (ISV) or created in-house. This “preload” SMS application likely includes a traditional, straightforward display of messages and addressees. A mobile network operator (MNO) or other channel partner has few options for customizing or branding this kind of application, and is often forced to pass uninspired software through to end users “as is” or invest in replacing preload applications at considerable effort and expense.