+ + User interfaces in the WRTKit are based on the concepts of "views" and "controls". + A control is a user interface element that the user can view or interact with, + e.g. buttons, checkboxes, textfields, etc. Views are containers for controls and + deal with the layout of controls on the screen in such a way that the user can + interact with them in an easy way. Views are conceptually similar to windows in + PC applications, but on a mobile device views typically fill the entire screen + and only one view can thus be visible at any given time. The WRTKit allows views + and controls to be interacted with in both the tab and pointer navigation modes + and the navigation mode can even be switched at runtime. +
+ + + +
+ + The WRTKit is an object oriented user interface toolkit, which means that views + and controls are implemented as JavaScript classes that are instantiated to + objects when they are needed. In order to create a view with two buttons, for + example, a developer writes JavaScript code that instantiates one view + object and two button objects, and then calls a method in the view object asking + it to add the buttons to itself. Being object oriented, the created WRTKit + objects fully maintain their own state and take care of drawing themselves + properly on the screen in all situations. So for example if one of the buttons + is focused, the button modifies its own looks so that it appears focused + on the screen. Because the objects know their own state, they can be queried for + properties as needed. E.g. a textfield can be asked what text it currently + contains, a button can be asked if it is enabled, and so on. +
+ ++ + Controls in the WRTKit have captions that can be used to show what the control + does. E.g. a textfield that is meant to be used to enter a password could have a + caption "Password". Captions are optional but should be used unless there is a + very good reason not to. The only controls that do not have captions are + buttons, since they have a text on the face of the button that accomplishes the + same thing. +
+ ++ + WRTKit user interfaces are managed by a class that is aptly named "UIManager". + Every widget that uses the WRTKit for its user interface creates a single + instance of this class and then uses that UIManager instance to command views to + be displayed. The UIManager takes care of all the heavy lifting that is necessary + to bring a new view to the screen. The UIManager also handles other user + interface duties such as management of notification popup dialogs and view + scrollbars. +
+ ++ + Controls and views can notify the outside world when some event occurrs, e.g. + when a button is pressed or someone toggles a checkbox. The WRTKit follows the + so called "observer pattern" in its implementation of event notifications. This + simply means that a control or view can be asked to call a particular JavaScript + function (which is the "observer" or "listener") when an specific type of event + occurrs. The WRTKit allows a control or view to have any number of concurrently + registered listeners and listeners can either ask to be notified of only a + particular type of event or about all events. +
+ ++ + The WRTKit library is physically a set of JavaScript, CSS and image files that + are located within a directory called "WRTKit". That directory is copied into + the root directory of widgets that wish to use the library. A widget only needs + to include a single JavaScript file ("WRTKit/WRTKit.js") from the directory in + order to include and initialize the full WRTKit for use in the widget. Once the + WRTKit has been added to the widget and initialized, the widget can start using + the JavaScript classes that the library defines. +
+ +