November 91 - AppMaker v1.2
AppMaker v1.2
Matt Stibbe
The development process known as stepwise refinement-which most developers seem
to employ, either formally or informally-assumes that development will use repeated
"try, test, improve" steps. Applied to the implementation of a user interface, this has
given rise to the idea of prototyping. If the user interface is thought of as the shell
around a program's actual function, prototyping is the process of building that shell,
before the center even exists.
Of course, in a typical Macintosh application, the distinction between form and
substance is blurred. On the one hand, the user interface thought police at Apple
constrain our interfaces so they conform to a laid-down standard, and on the other
hand, the Mac-a winged horse for a programmer-allows any number of innovations
and graphical tricks.
Implementing a user interface that conforms to standards, but has room for
innovation, is complicated in some respects by the otherwise helpful requirements of
MacApp programming. Anyone who has wrestled with the Rez/Derez/ViewEdit
combination to change the size of one button will know what I mean.
AppMaker, from Bowers Development, is an attempt to resolve these problems. It is
billed as a program for creating Macintosh applications. In reality, it is a tool for
prototyping them.
AppMaker allows you to design, test, and refine a user interface consisting of menus,
dialogs, windows, and controls. When the design is complete, it can generate source
code for the application in one of a number of programming languages. It also supports
MacApp; a special, modified version of the program (that comes with the standard
version) is designed for prototyping MacApp code.
In this review, I'll confine myself to evaluating AppMaker's performance with
MacApp. Apart from the MacApp-specific features listed in the Using AppMaker with
MacApp section below, AppMaker works in the same way for MacApp, the Think Class
Library, or conventional, procedural C or Pascal.
Operation
AppMaker has editors for windows, dialogs, alerts and menus. As far as the user is
concerned, alerts, dialogs and windows are treated the same way. Under MacApp, the
main difference is the root level view type. There are browsers for each type, and
when a new project is opened, all the standard windows and menus are present.
For example, a MacApp application has a clipboard window already defined. As with
ResEdit or ViewEdit, it requires a menu command to create a new window of any kind.
The new window appears on the screen, and can be resized.
Where appropriate, the user can select the type of window; for example, a modeless
dialog, or a document window with a go-away box and zoom box. Once a window is on
the screen, a menu of control items appears, including static and editable text, radio
buttons and check boxes, scrollers, and so on. These correspond to MacApp view
descendants (such as TPopup). As with ViewEdit, it is possible to define the
characteristics of these objects-for example, changing the id (AppMaker generates a
new one for each) or the class of the object, to make a custom descendant of a standard
object.
You can group items together, with the conventional bounding box and tag. This is more
than decorative: objects grouped this way can be moved about together, by dragging the
box which surrounds them; radio buttons confine the mutual exclusivity to their
siblings in a given box.
Scrollers are another useful feature. The scrollable area can be resized, and either
horizontal or vertical scroll bars deleted or retained. It is possible to create custom
controls, such as sliding volume controls or multi-state buttons. Several examples of
this are provided with AppMaker. It is simply a matter of importing PICT resources
that correspond to the various stages or elements of the controls.
All items, from window contents to a whole menu, can be copied and pasted easily.
Being able to open multiple project documents at once allows standard user interface
features to be easily copied between projects.
Menus are created using a facsimile of the menu bar in a special window. You can also
use the menus you define as pop-up menus in windows or as sub-menus. You can
define custom graphic menus such as those used in MacPaint, though they do not tear
off. Editing a menu is very simple. Each menu item, command-key equivalent, and
MacApp command number is an editable text field, and can be changed simply by
retyping the contents.
A number of standard menus that are defined at run time, such as the Apple menu and
fonts, are available as are the usual File and Edit menus.
Using AppMaker with MacApp
The main attraction of AppMaker is that it is very quick to produce a standalone
program that looks-and in part behaves-like the real thing. Because it comes with a
wide variety of language and class library support built in, it is useful to those who
are fluent in different languages. Most MacApp programmers know C++ and Object
Pascal; many use MPW for large projects, and Think products for smaller, more
urgent work. This also means that the investment in AppMaker is not wasted if you
change or upgrade your programming environment.
It is possible to reconfigure the code generated by AppMaker using resource templates.
This allows the core code that AppMaker uses to be changed and upgraded, for example,
to match a much-altered MacApp library that has been developed by a large software
house. This flexibility is shown in the number of systems that AppMaker supports. It
has some major advantages over ViewEdit in terms of ease of use and flexibility,
although in practice both would be used, each for different purposes.
AppMaker's interface to MacApp's way of doing things has been well thought out; for
example, in constructing view hierarchies and scrollers, or the way that it includes
the menu command IDs and then provides a slightly amended MABuild script so there
is no need to PostRez the menu definitions. The ability to group items logically
together not only helps improve the appearance of the interface, but also makes it
work much better.
All in all, it is a well-put-together application that does everything a user might
reasonably ask of it.
Weaknesses
That is not to say AppMaker is without faults. It lacks ViewEdit's fine control over the
appearance of individual dialog items-for instance, their color, font and style; and it
does not provide such explicit control over the arrangement of views and subviews.
In normal circumstances, this does not affect its prototyping capabilities at all, and
during full scale development the two programs would be used in tandem. Its main
rival, Prototyper, has a "Quicklook" feature which allows the interface to be tested
without quitting the program. Given that it may take several minutes to generate the
source code and several more to compile it, even on a small project, the ability to test
the user interface immediately and interactively within the program is one feature
that is sorely lacking in AppMaker.
Prototyper also offers some useful facilities for linking buttons, menus and windows
together. For example, a button can be programmed to enable or disable others,
another may open a dialog box and so on. In AppMaker, this logic has to be provided by
the user's own source code. For creating real applications, Prototyper's link facilities
are not very useful as they only provide a limited set of operations, but for
prototyping-the creation of testable interface without any code being written-they
are very helpful.
Generated Code
The code AppMaker produces seems robust and well structured. It follows Apple's
naming conventions, segmentation rules, and takes its guide from Apple's sample
programs. Comments are terse, so the student should not expect a running
commentary. It separates code and resources-in MacApp, this means it generates a .r
file-and this saves having to DeRez resource files, as one has to do with a file created
by ViewEdit.
It offers little control over the style of the source code it generates. You can change the
style of code by editing the source code templates, but it would have been better to
provide routines to set indents and so forth (Prototyper does this). It makes use of a
library of core routines which provide common functions. Although the source code
for this library is provided, it requires extra learning if the code is to be used in a
long term development rather than as a quick prototype.
DOCUMENTATION
The manual is thorough and concise. It was crammed with version notes, addenda and
notes for using the program with MacApp. This information is important and loose
notes are better than nothing; however, it gives a sloppy impression. As the manual is
comb bound and obviously typeset using regular DTP and laser printer output, it left
me wondering why Bowers Development couldn't include these notes directly in the
manual.
However, this is a minor niggle. Anyone who has used ResEdit, ViewEdit, another
prototyper, or even HyperCard, will find this program easy to use with little help
from the manual. It has a thorough tutorial section that walks through a sample
AppMaker project, a simple application with a few menus, windows and so on. It also
contains a detailed description of the AppMaker library that must be included with any
application using AppMaker to generate some of its code.
Conclusions
The actual operation of the program is fast, but its code generation seemed very slow.
In some ways, it forces a style on the user, and it still requires some work in order to
generate a truly original and graphical interface. There were no noticeable bugs or
unwarranted features.
Prototyping and user interface testing are two good things; they help the developer and
the end-user, respectively. AppMaker is not going to create finished applications for
you. And there is no way that someone is going to learn how to develop good efficient
MacApp code simply by using it, and "filling in the blanks." This is like saying that
painting by numbers will make you a great master.
Instead, AppMaker is perfect for building bits of user interfaces that work and thus
can be tested, experimenting with new ways of presenting a program, or building an
experimental skeleton for a new program. As a bonus, it provides a quicker way of
cobbling together MacApp view resources, and a way of knocking up "quick and dirty
programs that need a graphical interface, but little application-specific code.
So who should buy it? This program is for anyone who regularly has to design user
interfaces for MacApp-based applications, or who has to prototype a large MacApp
program rapidly. For these people, it will be a godsend.
Version tested
I tested version 1.2 on a Mac IIcx under System 7, with MPW 3.2, MacApp 2, and
C++. According to the Bowers, there is a new version (1.5) due soon that will
support MacApp 3, System 7 source code generation and the new Think Class Library.
Apparently, those who buy the current version from August 1991 onwards will be
upgraded free of charge when the new version is released. Bowers claims
compatibility with Mac Plus, SE, SE/30 or II series computers using System 5 or
later.
Market data
AppMaker is published by Bowers Development. List price is $295. Bowers
Development can be reached at (508) 369-8175 or AppleLink D1721. No license
fees are required for applications using code generated by AppMaker.