system can be
divided into two parts. The first defines the looks of the system. Here
one finds the "graphics part" of the GUI consisting of input components
such as buttons and other controls as well as output components such as
labels and text- or numerical output fields. The second part is related
to the "mechanism part" of the GUI, namely what happens when a button
is pressed or a slider is pushed. The "mechanism part" includes both
the possible change of appearance of a component such as a pressed
button, as well as how to call the appropriate subroutine of the
very sophisticated ways to build these two parts. Using e.g.
Interface Builder, found in the Xcode development environment for IOS,
components are chosen from a library and the placement on the screen as
well as the connections to the application program are specified
graphically. Other systems require the application programmer to
specify the explicit screen coordinates of all components, and pointers
to appropriate interrupt routines need to be given explicitly.
TouchableViews, being developed primarily for small screens and
applications with low number of GUI components uses specific
declaration of the components in the application programmers own code,
including the size and position in screen coordinates. I have not found
it necessary to automate this part of the code as the time needed to
specify a layout (typically one or two lines per GUI component) is
compared to developing the rest of the application. This does not rule
out that in the future, someone will make a graphic
tool to build this part of the code. A possible route might be to
simply post-process the output of the Interface Builder or the XML-file
produced by Android tools.
in TouchableViews is even simpler as there are only a few predefined
"landing sites" for touch events. As we will see, it is not necessary
to define the event routine in the GUI specification. Again, the code
to dispatch the event amounts to a few lines in the user program for
each component and does not add particularly to the development effort.
What is gained is a low-complexity view definition where all
components, independent of their type can share the same data structure.
views - basic principles
Our GUI is
the concept of "touchable views" :
1) A GUI
a specified rectangular part (view) of the screen with an unique
2) When a
touched, or clicked upon, an event routine is called with the
identifier as argument.
toolbox of supporting routines, this is all that is needed!
This site is © Copyright Robert Forchheimer
2011-2012, All Rights Reserved.