Volume Number: 13 (1997)
Issue Number: 4
Column Tag: Tools Of The Trade

AppMaker

By Edward Ringel

Now building graphical interfaces for almost any framework you can imagine

Flipping through one or two issues of MacTech will almost certainly reveal an advertisement for AppMaker from Bowers Development Corporation. Although this product was reviewed in MacTech/ MacTutor in 1989 (AppMaker vs. Prototyper, volume 5) we (the editors and I) felt that a revisit to this product was timely, given many changes in both the character of the product and corporate support policy.

This application interface generator is a solid tool that delivers as promised, and is in the best Macintosh tradition of easy and intuitive use, cutting edge technology, and value-rich updates. Documentation has lagged behind product development, and this will be a source of frustration to some users, particularly those new to programming in general and the Macintosh in particular. Additionally, some users, again particularly those new to programming, may be surprised at what the program does not do.

The concept behind AppMaker is quite simple. Using a drawing interface, the user designs windows, alerts, dialogs and menus selecting elements from a palette of controls, icons, pictures, etc. After the interface has been developed, the programmer generates source code and resources to implement the interface in the development system (language, IDE, plus framework) of the developer's choice. (I am going to use the term development system repeatedly throughout the article to refer to the combination of language, IDE, and framework.) We'll start our review with the contents of the distribution CD.

AppMaker as currently shipped consists of a single CD and a manual. AppMaker is a product in evolution and the CD contains several versions of the application. I reviewed and used versions 1.5.9 and 2.0b6 (Mailing #5). I subsequently reviewed 2.0fc1 (Mailing #6), primarily to update this article. (Mailing #7 will be out by the time this review appears in print.) The 1.5.x series of versions (more on why a series of versions below) is a stable, fully documented product that can be used to generate the resources and code to create applications in procedural C, procedural Pascal, Object Pascal TCL/MacApp 2.0, Object C TCL, C++ TCL 2.0 and MacApp 3.0/3.1. PowerPlant is not supported, nor is the most current version of MacApp. Fortran is available as an add-on. The 2.0fc1 application is the only current version of AppMaker 2.0 and is the first non-beta version of the 2.0 series of applications. PowerPlant, TCL 2.0, MFC, OpenDoc, Java, and procedural C (straight C and Tools Plus) systems are all supported. No Pascal system is currently supported by version 2.0. (See below for more information on future supported versions.)

Why this potentially confusing array of versions and supported development systems?

Figure 1. Schematic representation of language and system dependency among user documents, AppMaker, and code generation.

The answer lies in the differences between the 1.5.x and 2.0bx applications, which use fundamentally different document architectures and code generation schemes. When a new AppMaker project is undertaken, the user creates an AppMaker document; this document contains all the information about the interface to be generated. In the 1.5.x series of applications, the user's document is a series of resources understood by the development system; in 2.0fc1 this document is development system independent and understood by AppMaker, which permits tremendous flexibility in reuse of an application's or window's layout.

Code generation instructions are contained for the 1.5.x series of applications in a series of resource based documents and templates. This scheme has been completely revised in the 2.0 application. More information is in the code generation templates and less information about code generation is in the user's document. Also, the information now resides in the data, rather than resource fork of the template documents. The upshot of this is that in order to update code generation for the 1.5.x series applications, the application itself must be updated as well as the resource documents.

Versions older than 1.5.9 are still maintained to provide support for older development systems, THINK C 5 and 6. The 2.0 application only requires updating of the code generation scripts to handle changes in the various development systems. The 2.0 application series is superior in terms of interface generation, and it would appear that Bowers Development has made a strategic decision to support the new format vigorously and pretty much to freeze, except for maintenance updates, the 1.5.x series of applications. Depending upon your development system, you will have the opportunity to use the older and/or newer systems. I think the 2.0 application is a better, more versatile product and will direct most of my comments to this version.

When a new project is created, the first window that appears is a list of program elements, a kind of project window.

Figure 2. Tools menu and project window for AppMaker 2.0.

The majority of interface design work will take place within the menu, window, alert, and dialog subheadings, and this would be the first step in creating a new project - author the interface and the menus. While I don't want to appear that I'm giving this aspect of the development short shrift, in point of fact the use of this aspect of the program is so incredibly easy that it is almost self explanatory. Using draw type tools, one simply places design elements on windows that will be treated like an alert, a dialog, or window. Every application is expected to have a main window, and this is created for you at the time you create the new project. The 2.0 application comes with a very wide array of really neat goodies - pretty buttons, sliders, spinners, edit fields, tab panels, pop-ups, etc. - that you can put in a window or dialog (or alert). It is very easy to create a handsome, up-to-date interface.

Figure 3. Test application's main window. I built this in about 15 minutes.

The menu construction kit is also fairly straightforward, and the "what you see is what you get" view is also interactive. Menus can contain submenus. The 1.5 and 2.0 versions have a relatively similar interface here, except that the project window in 2.0 is more comprehensive and windows for different kinds of program elements can be open at once. Menu construction is more versatile in 2.0, and there are fewer goodies in the design element palette in 1.5. We will revisit these partially finished windows and menus shortly when we add some functionality to the program under development.

Real life use of the interface generator was fairly easy. When I used the 2.0 beta product, there were a variety of bugs. These problems were addressed in 2.0fc1 and the prodcut appears to be stable.

Things get even more interesting when we leave the basic design group. It is worth taking a detour from AppMaker for a bit and quickly review design structure for the major object oriented application frameworks supported. In all of these, objects communicate with each other through commands, which are simply numbers that are messaged from one object to another, either directly or by being passed up a command hierarchy. This is used in MacApp, TCL, and PowerPlant. AppMaker 2.0 has the ability to create, modify, and delete command constants in dialog windows and subsequently generate the appropriate headers. Critically, one can return to the partially constructed menus and windows and have button presses, menu selections, etc. issue commands; some of these commands can also be coded in AppMaker to open windows, open dialog windows, show alerts, etc.

Figure 4. The ability to create a custom command, not just a messaging number, is a tremendous strength of this product.

It is possible to customize the header list in generated code, jump to a code fragment, or suppress method generation from this same window. The ability to fine tune the code generation is a major plus.

It is possible to address many other aspects of application design in AppMaker. There is a window that allows construction of the application information. Document information can be defined. Adorners, views/panes, text traits and many other similar elements can be created and modified in this product. It is possible to form a wide variety of program elements as well; for example, creating classes from within AppMaker. AppMaker "understands" OOFile and NeoAccess, and it is possible to build database elements from within the program. Thus, I would envision an iterative process of program design, creating an interface, then creating commands and special classes, and then returning to the design interface, to attach commands and the like to the various design elements. This process might be repeated until you were comfortable with the interface and the functionality that could be created from AppMaker. The capabilities of the 2.0 version in this area far outstrip the 1.5.9 version.

"Power users" of AppMaker can use a companion program, AMCompiler, to customize AppMaker's code generation at the level of the language script files. This tool is used by Bowers Development to create new language templates and to update existing language templates.

Eventually, you would be ready to generate code. In the 1.5.9 version, the development system is chosen at the time of the creation of the new AppMaker project document; in 2.0, the development system is chosen at the time of code generation. As I indicated in the introduction, version 1.5.9 supports TCL 1.1 (C and Pascal) and 2.0, MacApp through 3.1, and procedural C and Pascal. The code is sparsely commented, and occasionally it was difficult to decide where to place the functionality of the program.

Basic Apple events are supported in version 1.5.9. There is relatively little in the code generated except for support of the interface. Procedural systems use a library of procedures/functions that implement the event loop and take care of basic interface support and housekeeping. The object oriented systems depend heavily (as they should) on the methods of the classes from which design objects are derived.

Version 2.0 code generation is more robust, and the code is better commented. Despite this, it is not always absolutely obvious where to insert functions, or which functions must be supplied by the programmer. TCL 2.0 and PowerPlant are both supported, and since command elements can be customized, one can achieve sophisticated code generation. For TCL, AppMaker uses the two class, two file approach to code generation similar to Symantec's Visual Architect. (Interestingly, I was told by Spec Bowers that AppMaker pioneered this strategy and it was subsequently adopted by VA.) This system isolates interface code that does not need further user intervention from the file that will be altered. For PowerPlant, the two class strategy is not used and functional code is inserted directly into a single file. Thus, beware if you regenerate your source files, even if your program is fully factored! AppMaker also generates the correct "special" resources (‘Ppob' for PowerPlant, etc.) for the system in use. Procedural C helper and high level functions are used to simplify procedural code generation and do housekeeping, main event loop, etc. There are no bells and whistles here, but the code is straightforward and gets the job done according to Apple guidelines.

Version 2.0fc1 offers support of new environments, and offers some options for cross platform development as well. It supports the creation of Java windows based on the Java AWT, but not freestanding Java apps. Non-embedding OpenDoc parts, based on the ODF system are supported. (See http://members.aol.com/bowersdev for more information on generating container parts as well as non-embedding parts.) Bowers Development indicates that OpenDoc support will be improved and broadened as a priority. Applications for Windows based on the Microsoft Foundation Classes can be created. To my knowledge, this is the only application that supports all these different development systems. The ability to create one AppMaker document and then generate five or six different kinds of code is extraordinarily appealing, particularly if you are working on a project that may ultimately be ported to Windows or be implemented in the future as an OpenDoc part.

AppMaker plans expansion of its system base. I was told that ultimately all systems supported by 1.5.9 will be ported to 2.0. This would obviously include Pascal and MacApp, the two high profile systems that are missing from current support. A Tools Plus 3.x generator is under active development, and a preliminary version makes its debut in 2.0fc1. (Given the quality of both products, this would be a powerful pair of procedural development tools.) Apparently, 2.0 system support is dictated largely by user feedback, so be assertive.

Overall, the code for all the systems is quite solid. There is no showmanship, and no shortcuts, and perhaps that is the way it should be for such a product. In version 1.5.9, it is possible to suppress individual file regeneration when editing a project. This can be helpful if you have modified an AppMaker generated source file extensively.

It is important for potential purchasers to understand that AppMaker is an interface generator; it is not an application generator. It is easy to overlook that you still must add the function to your program, and hang up on creating the interface. In the procedural language arena, there are relatively few helper functions. The user must understand how to use the Toolbox to complete the application. When generating code for object oriented frameworks, a knowledge of both the Toolbox and the class library and framework of choice are essential. There are no high level functions to print a window or create a drawing environment or connect to a network. The novice programmer who has a great idea and expects to just put a few finishing touches on the resource file and fix a couple of details in the AppMaker generated code before shipping a finished application will be quickly deflated. On the other hand, if you understand the system you are using, or are committed to learning the system, you will get an enormous advantage in terms of time and basic solid code on which to build.

Documentation for this product is less than optimal. For AppMaker 1.5, there is a spiral bound few hundred page book which is partially out of date, but it does get the sense of the product across. In particular, I was uncomfortable with how little information was provided in how to take the interface code skeleton and add functions.

Documentation for version 2.0 is, for all intents and purposes, nonexistent. There are a few sparse text files which shed little light on how to use the product. Fortunately, AppMaker is so easy to use that one can get around this problem with some time and exploreation. Bowers Development recognizes this and promises to do better.

Tutorials for both products are quite spartan as well. The learning curve of this product has a dogleg; while it is easy to use some of the product, e.g. plopping controls onto a window, getting the hang of creating commands or customizing the project window is not self-evident and takes a while longer. The lack of guidance for inserting your code into the skeleton is also very problematic for me. This is an almost perfect situation for creating an Apple Guide tutorial.

Obviously, it is appropriate that the bulk of time and energy of Bowers Development goes towards improving the product, adding new features, and squishing bugs. However, lack of finish is the major flaw of this product. The raw edges will present the greatest obstacle to the neophyte; I expect anyone who has programmed a Macintosh for a year or so will find things a bit sloppy, but will encounter no insurmountable problems. C++ programmers using a framework will probably have the fewest learning curve problems of all as the generated code will be very familiar to them.

The greatest advantage of AppMaker is the opportunity to avoid extensive reprogramming when ranging among development systems, particularly some of the newer environments such as C++, Java, and OpenDoc. There simply is no other product that can do this. Visual Architect of Symantec C++ is harder to use and doesn't have as many goodies as AppMaker, and Constructor for PowerPlant doesn't create code source files. On the other hand, they come with their respective development systems and impose no further cost. XVT DSC++ is a comprehensive, massive product that includes XVT-Architect, an interface and application generator. The package is quite expensive and has flaws, but offers the functionality of AppMaker and quite a bit more. Comparing the packages is a bit like comparing apples and oranges (or perhaps Apples and Windows), but I think AppMaker gives the buyer considerable value for money spent, and allows the construction of a more Mac-like program. (See my review of XVT in MacTech September 1996.)

In the procedural language arena, AppMaker has serious competition, particularly in the C language area. Tools Plus 3.1 is a very good library and framework; version 3.0 was recently reviewed in MacTech. It does not have an interface builder, although one is apparently on the horizon. (A Tools Plus vs. AppMaker decision might no longer be an either-or decision with the arrival of an AppMaker generator file for this product.) VIP-C offers interface construction with code generation and a unique integrated environment including a wide variety of helper functions. (See my review March 1996 MacTech, also recent review of IDE's in December 1996.) Both of these products do not have much ability to support multiple environments (although Tools Plus supports procedural Pascal). If you were certain that you would not be changing development systems in the near future, these products would warrant serious evaluation.

One free product competes directly with AppMaker. This is Gooey 1.2, available wherever fine free software is found (I got mine on Apprentice 4) and is apparently the successor to Prototyper/Marksman. Not as nice, not as up to date, not nearly as many goodies, basically unsupported, but free. It supports C and C++ code, the latter being a home brew class library that is generated on the fly. It does not support the standard frameworks.

AppMaker holds out the possibility of cross platform development in its support of the Microsoft Foundation Classes. AppMaker understands OOFILE and NeoAccess, and this, coupled with the ability to generate MFC code may dramatically shorten the development cycle for some programmers with cross platform projects.

Finally, the dependence of the product on established, supported frameworks is advantageous as well. Apple repeatedly suggests the use of supported frameworks as the best way of keeping up with technology changes, and AppMaker helps you do this.

AppMaker comes on a CD. Bowers development is committed to three updates a year, wisely timed to come out a month after the Symantec and Metrowerks updates, so that Spec and his gang can keep up. My understanding is that there have been steady, incremental improvements in technology for each update; this is substantiated in the release notes that I reviewed. There are goodies, demos, and user submissions on the CD as well. In corresponding with the company, it is clear that Bowers Development sees incremental improvement as critical to maintaining a client base, and improvements and additions will continue. On a personal note, I appreciate this and am grateful for a company whose updates do more than just meet the compiler demands of CodeWarrior n+1; this is what being a Mac developer is all about.

AppMaker 2.0 comes in both 68K and PPC flavors. The 2.0 product is about 12-20 megs depending on what you choose to copy over to your hard drive from the CD, and the PPC interface tool and the compiler each would like a 2-3 meg piece of RAM, depending upon whether or not RAM Doubler/Virtual Memory are enabled.

Technical support is offered by e-mail, fax and phone. The one question I did have was promptly (within 72 hours) and tersely answered. The CD comes with a no nonsense "treat us fairly and we'll treat you fairly" approach to tech support and licensing. The primary e-mail address is <bowersdev@aol.com>. There is a web site, http://members.aol.com/bowersdev, where updates and information can be found. Bug fixes and technology improvements that become available between CDs are posted here, and there are links to development system web sites.

This is a good product. An experienced programmer can do a lot with it. A novice programmer can learn a lot using it and get a leg up quickly. Its support of multiple environments is unsurpassed. It needs a lot of work on documentation. It should be purchased with the understanding that it does not have a wide variety of non-interface support and helper functions. However, I think this is the interface application generator of choice for anyone working with C++ frameworks and/or OpenDoc. Programmers who plan to remain with procedural C or Pascal for the foreseeable future may want to comparison shop. The product is seeded on many distribution CD's in demo form, but many of these are out-of-date. (Refer to the web site for the latest demos.) Test the features of this innovative product yourself and have some fun.