Programmer's Reference

Examples of applications with long-running operations

The following are some overviews of suggested implementation styles when building applications with long-running operations using IBM Smalltalk. These examples are intended to show typical ways that applications can be written using IBM Smalltalk. Of course, every application is different so developers can use any or all of these techniques, or construct new idioms that are more appropriate to their problem domain. The important point to remember is that, there are no surprises. Every aspect of the polling model is accessible to the application developer. Nothing is done "under the covers."

Example 1: a simple text editor

A simple text editing application is constructed using IBM Smalltalk. The application is responsive in all situations except while reading or writing the file that is being edited. To maintain responsiveness in this situation, file reading and writing are moved to a background process. The operations are modified to use a modal "percentage complete" dialog that is updated by the background process using asyncExecInUI:. When the file has been completely read or written, the background process uses a call to syncExecInUI: to close the dialog.

Example 2: a program development environment

A program development environment is constructed that uses a database to store source code. Saving large segments of source code is found to cause a lack of responsiveness because several database accesses are required. To maintain responsiveness, the saving operation is modified to:

Example 3: a complex drawing editor

A drawing editor is constructed that allows large, complex drawings to be built. The system is responsive in all situations except while updating a display of a large drawing. The update display (refresh) operation is modified as follows:

Notice that in this example, the same code could be used to do the actual refreshing of the drawing, regardless of whether it is being run by the UIProcess or by a background process, because the "ExecInUI" methods can always be called by both background processes and the UIProcess.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]