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.