Build-A-Board Run-Time Targets Notes

Build-A-Board Run-Time Targets Notes

Each Run-Time Target is built with target specific code, shared core application code, and abstracted API interface code. Because of compile, system, and code differences it is important to understand that each Run-Time Target should be considered its own Program, and as such, could be different than other Run-Time targets (due to completely different code/design/implementation). The following chapter covers areas that affect the Run-Time targets - sometimes on a particular platform, sometimes across a feature and its implementation, and sometimes on an aspect affecting one particular option or feature.

While at first glance, an on-screen keyboard seems like a relatively easy program to develop, the nature of low-level development, platform differences, and the various areas that require in-depth programming practices to create a seamless user-interface requires a great deal of effort. Most programs can be modular, and focus on low-level specific functions, or high-level, and focus on user interface aspects. Due to the nature of the on-screen keyboard, not only is a high-level user interface required, but so is a low-level interface into the system. For speed and responsiveness, access to video calls at a system level is required, along with typically system or low-level calls to operate and work with interprocess communication and virtual keyboard input. As such, code must be written at a system level, and the effort to create an environment that compiles at a native level across multiple platforms is not trivial or easy. So while an on-screen keyboard is something you might be able to do in a few hours with a high-level tool such as Visual Basic, you will find that animal won't even get in the door to run in Linux or Mac OS X (unless you have the means to recreate that whole high-level environment). Alternatives such as Java or Qt provide cross-platform environments for certain aspects, but can't provide the power and flexibility of operating without this abstraction layer between the code and the system, and also add a requirement that may be a show-stopper in embedded, secure, or other less-than-full-featured environments.

The various constraints and goals of creating a native, system level tool that can not only provide keyboard and system actions, along with a flexible user-interface that is responsive and an effective tool has resulted in each Run-Time target being its own Program, while operating on a shared Data format (KBF File). Because it is not always the same code operating on the data, and the scope and complexity of entire Build-A-Board concept, there may be issues or unintended consequences that may result when certain combinations of features, program/data interaction, and user actions occur.

One concept in programming is "Design for Test" so that every possible input and output can be tested & verified. While that sounds good on paper, it is a virtual impossibility when applied to the scope of Build-A-Board (unless access to virtually unlimited resources is made available). Due to the facts that the user can create an unlimited combination of layouts, labels, and actions; for each platform, a wide range of processes and services can interact with the system; each user can perform different actions and sequences of interaction to generate results; therefore, it is probable that some user, on some platform, with some feature may experience a result that isn't expected, or isn't correct.

In conclusion, one of the engineering constraints was not having unlimited resources to verify every combination of features for every situation for every platform for every possible situation. Therefore, we strongly recommend customers continue with on-going support, for updates, fixes, and access to technical support staff.