Project: Kiosk Toolkit

Java-bean toolkit for creating kiosk applications

1. Introduction

This was the main project we did during our first internship at a company named The Allied Group in Connecticut, USA in 1998/1999.

Before I can tell you what the KioskToolkit is, I must explain what we mean by kiosk. A kiosk in this context is a PC build into a pilar or wall in a public place where people can aquire information from the PC using a touchscreen.

The KioskToolkit is a set of tools (JavaBeans) with which a low-skilled developer can develop a kiosk application by simply dragging and dropping JavaBeans here and there. Before us, the KioskToolkit already existed, but was basically a non-documented mess.

Our goals were:

Based on the reactions from colleagues and teachers, I think we achieved our goals quite nicely.

2. Educational value

3. Evaluation report

Parts of the evaluation report we send to our teacher.

4. Toolkit classes

The Kiosk Toolkit consisted of many classes, and I'm not going to explain each and every one of them. Instead, I will shortly explain some groups of classes we created or modified.

System classes

Several classes of the kiosk toolkit form the basic building blocks that comprise the foundation of every kiosk application. These classes will (and should) normally not be used by application developers, since their functionality is either both low-level and used by higher level beans instead, or used for managing the kiosk application. These classes do, however, define the structure of a kiosk application, and understanding their functions and structure will make clear how a kiosk (using the kiosk toolkit) actually works.

Visual components

The visual components are one of the most important building blocks when creating a kiosk application. They can be used to: let the user control the screen flow, let the user enter different types of information, present data in various ways, etc.

Although the purpose is trivial for most of the component, some of them have special features that may be useful for the kiosk application developer. A good knowledge of what is possible can help during the graphical/artwork design to pinpoint problems in an early stage of the application development cycle. It is also important to know what is possible, since some of the components have features that are not offered by standard components and may be left unused if the application developer is not aware of them.

Some of the toolkit's visual components:

ComponentShort description
LayerdPanelContainer with two background images. One for 'idle' state and one for 'selected' (lists) or 'pressed' (buttons). All visual components in this toolkit use this 'layered' functionality.
Components with 'layer' functionality.
List/TableMarkupConfiguration to customize lists and table columns.
NumericTextFieldTextfield for numbers.

Database connectivity beans

The database connectivity beans (DCBs) allows using JDBC to connect to databases and are designed to be used in a visual bean development environment. This allows easy manipulation of database connection information, and allows the developer to connect database data to other visual components.

Some of the designed beans offer data models that can be used by various JFC components to represent information from a database query (e.g. JTable and JList components). Displaying database query results in a table can be accomplished by simply connecting a table model to one of the included database beans.

Some of the toolkit's connectivity beans:

ComponentShort description
JDBCConnectorProvides connection with database thrue JDBC.
QueryModelsData models with data filled from database.
QueryImageDisplays image from database.

Data models

To avoid data being stored in the user-interface, all JFC components use models to hold their data. The most important models of this paragraph are the ListModel, TableModel, and the Document. The ListModel is a data model that is used to provide data for a JList. The TableModel provides data for a JTable. A Document is the model for a TextComponent (e.g. TextField or TextArea). All of the models described in this paragraph implement one of the three interfaces mentioned above. Some of the models generate data, others get their data from other models. Some are standalone other require at least one other model to work.

Some of the toolkit's models:

ModelShort description
Sorted modelsSort data from other models.
Pages modelsProvide data from other models in pages.
Multiple modelsSpread data over multiple models.
Merged modelsMerge multiple models into one.