REALbasic 2005, Release 4
Developer: REAL Software
Price: $100 (standard edition); $400 (professional edition, introductory price)
Requirements: 600 MHz G3 with Mac OS X 10.2.8, 512 MB of RAM; executables require Mac OS 9.1 or Mac OS X
Recommended: 800 MHz G4 with Mac OS X 10.3.9, 768 MB of RAM
Trial: Fully-featured (15 days)
I have long been searching for my Holy Grail of database development. My primary job is to create software to allow users to access databases in a business environment. Usually, I create this software on my PowerBook, but when the client is using it, it generally needs to run under Windows also.
So, the Holy Grail for me is going to be an environment that allows rapid development and cross-platform builds. For over a decade, I’ve been using FileMaker Pro to accomplish these two goals, but FileMaker, even if it’s easy to use and allows powerful custom databases, has a number of limitations that have grown more and more annoying over the years. FileMaker doesn’t create compiled software, which means that to use a FileMaker database you need to either have FileMaker or a runtime version of it. Capturing events with FileMaker (such as when a user exits a field) is difficult at best. This means that many things users request either require a plug-in or some fancy programming, when, in my opinion, it should be easy. Finally, the interface of FileMaker databases has to be built from scratch. If I want the system to look like a Mac’s Aqua interface, I have to recreate the graphics for such an interface, and when the program runs on Windows, it will look exactly the same, rather than like a native Windows program.
Now, if I were building just for the Mac, I would use AppleScript Studio, part of Apple’s Xcode development environment. But since I need to create cross-platform solutions, I’ve long considered looking into REALbasic, which ostensibly gets around all of the limitations of FileMaker. This review is written from that point of view, so you’ll often find comparisons between REALbasic and FileMaker, as well as AppleScript, which is another language I’m familiar with.
What Is REALbasic?
REALbasic is a complete object-oriented programming environment available for either Mac OS X, Windows XP/2000, or Linux. In addition to being able to create software for all three of these platforms, it can also compile for Mac OS Classic.
REALbasic is an integrated development environment, which means that everything is done within the program, from laying out the interface widgets to writing the code that gets executed. It comes in two editions: Standard and Professional. Given my cross-platform requirements, the Standard edition is useless to me, as it will only compile for the platform it runs on. The software comes with a built-in single-user database engine, although the Professional edition is required to connect to a database server. That server can be any of a number of SQL servers, including MySQL, or even FileMaker Server.
The pricing for REALbasic is somewhat complex. You can buy the Professional edition for $500, although at the time I write this it’s available at an introductory price of $400. The Standard edition is available for $100. Whichever edition you purchase includes six months of updates. In general, REALbasic is updated every 90 days or so, which means that the purchase will include at least two and perhaps three updates. Once this subscription expires, you can continue to use the version you have, or renew the subscription for one year. This annual subscription seems to be half of the purchase price, so that the Standard edition subscription is $50 while the Professional edition subscription is $200.
Although these prices are comparable to the prices for FileMaker Pro and Advanced, two facts should be kept in mind: first, when building a system in FileMaker Pro, the only way it can be used over a network is if each of the client Macs has its own copy of FileMaker. Since REALbasic programs are compiled, this isn’t an issue. Second, REALbasic offers many options for the backend database server, including MySQL. Depending on how you are licensing your own software, you may be able to use the MySQL server for free, or for as little as $295 (or as much as $4,995 for higher levels of service from the publishers of MySQL). In all likelihood, the lower cost license, if a commercial license is required, will probably be sufficient. The point being that using REALbasic with MySQL will probably result in lower costs to your customers.
BASIC in REALbasic
As the name of the product suggests, REALbasic uses a dialect of the BASIC programming language, which was actually the first programming language I ever used, back in the Atari 800 days. REAL Software has extended the language to include object-oriented features. For a programmer, learning the language will only take a half hour or so, but it’s also simple enough to be a good introductory language for the beginning programmer.
In fact, sometimes I find the language a bit too geared toward the beginner. For instance, in most programming languages, the case of variable names matters. A line reading a = 7 and another reading A = 7 are completely different in, for instance, Objective-C or PHP. In REALbasic, these are the same. Case never matters in REALbasic. Not only are variable names case-insensitive, but the language keywords, such as if and dim can be written in lower case, upper case, or mixed case. I personally prefer lowercase, which is what I use, but REALbasic occasionally uses initial-caps without letting the user change it (when defining methods that return a value), leaving me with the choice of either ignoring the instances I can’t change, or of ignoring my preference to be consistent with the default.
A prime feature of object-oriented programming is the ability to define a new class that has all of the properties of another but that can be customized with new features, a process called subclassing. For instance, REALbasic comes with an EditField class that allows users to type information into a text field, among other things. However, by default, the text within an EditField object isn’t selected when the user enters the field. I can subclass EditField and change the behavior so that my subclass does select the text when the field is entered.
REALbasic doesn’t allow all of its built-in classes to be subclassed, which just defeats the purpose of subclassing, or more precisely, REALbasic blurs the difference between raw data types (such as integers and strings) and class data types (such as windows and edit fields). A string is a raw data type in REALbasic; it can often be treated as a class, but it can’t be subclassed because it isn’t a real class.
Most languages include not only variables, but also constants, named pieces of data that do not change. Unfortunately, constants can’t store just any data type. Classes seem to be off limits, and so are arrays, which means that when a constant of either type is required, a variable or property has to be used instead, which defeats the whole purpose of constants. I should note that this is a common complaint for me with regards to programming languages. I’ve recently found myself complaining of the same limitations while programming with PHP.
Even with the data types that can be stored as constants, if a string constant is very long, editing it is difficult because the text field for doing so is rather small. This is especially an issue with database development, as the code that defines the database’s table and fields should be a constant (as it won’t change during the execution of the software), but can be rather long, since the single string is defining the entire database. I did find a workaround, but it shouldn’t be necessary.
Editing a Lengthy String Constant
Regardless of these minor annoyances, REALbasic makes object-oriented programming easy to understand and easy to use.
The greatest portion of programming is spent typing text, so the code editor of a programming environment is key to how efficiently software is created within it. In this, REALbasic again makes things easy. FileMaker effectively has two code editors: one for entering calculations, which are typed directly, and another for creating scripts, where each script step isn’t typed in, but selected from a list. After one becomes proficient with FileMaker, double-clicking a script step every time gets tedious, and it’s refreshing to be able to simply type all of the code. In fact, REALbasic has spoiled me in at least one major sense: the text editor includes auto-complete, where a language keyword or variable name can be entered by typing the first few characters followed by the tab key. After using this for a while in REALbasic, I’m sorely missing the feature when creating calculations in FileMaker and Web sites with PHP in BBEdit.
There are some interface glitches within REALbasic that are annoying. For instance, you can choose from the menu to hide the toolbar (which I never used). This tool bar has a location field that displays which object of your software is being viewed. But even when the toolbar is not being viewed, sometimes the location field still shows up over the tabs of your objects. It seems that this happens after running the project, and I believe that REALbasic was written with REALbasic, which brings up the question of whether this kind of interface glitch will show up in software I create.
Tabs/Location Field Interface Glitch
When creating classes, REALbasic offers a hierarchal system for navigating all of the parts of the class, such as constants, properties, and methods (functions and procedures). Except for event handlers, anything listed is created by the user.
Event handlers are available methods of interface controls that will execute code when the event takes place. For instance, if I have an edit field in a window, an event handler exists called GotFocus. Any code within that event handler will execute whenever the user enters that field.
Most event handlers of most interface controls remain unused and empty. Generally, the only event one needs to capture for a button is the Action event (when the user clicks the button). If I remember correctly, FaceSpan, an environment that works similarly to REALbasic, offers the ability to hide event handlers that are empty. Such a feature would be nice in REALbasic. When a window includes dozens of interface controls, showing all of the event handlers, including the empty ones, makes for a cluttered window and requires a lot of scrolling.
Navigating Event Handlers
Probably the most important piece of a development environment after the program itself is the documentation, and this is REALbasic’s weakest area, especially when compared to FileMaker. FileMaker’s built-in help system is easy to use, complete, and accurate, and I use it daily to look up functions and script steps. In contrast, REALbasic’s documentation is mediocre to use, incomplete, and inaccurate in many places.
The documentation comes in two primary forms: a user’s guide, which supposedly covers how to use the program in general (i.e., how to create a subclass or edit the layout of a window), and a language guide (describing how the language works and providing a reference to the built-in objects).
The language guide is the most important part of the documentation. The user’s guide is great when you’re first learning the program, but once you know how to use the software, if you’re using it regularly, you’re not going to forget how to use the software. Remembering each and every built-in class and each and every method and property of those classes is impossible, however, which means that accessing the language guide is a regular occurrence, and it needs to be complete and accurate. However, after using the software for only a couple of months, I’ve found numerous places where the documentation is either unclear, incomplete, or inaccurate. The language guide includes non-existent methods while it’s missing methods that are available, and given that my primary use for REALbasic would be to create database applications, I found the information regarding databases to be rather sparse.
Here is where REAL Software’s Getting Started mailing list has been invaluable. A number of times more experienced users who frequent this list were able to help out where the documentation failed. Honestly, if you begin using REALbasic, I can’t recommend highly enough joining this mailing list.
REALbasic does an admirable job of guiding interface creation toward human interface guidelines. When building an interface, the final look of it will depend on the platform the software is run on. REALbasic goes toward assisting with this by allowing the ability to view menus as they will look on any of the platforms, but the final look of windows can only be checked by running the software on each platform. A nice feature would be the ability to see what windows will look like as we can with menus.
Possibly because of the cross-platform nature of the software, not all of the Aqua interface elements are available, and those that are don’t include all of the options one would have if creating software with Interface Builder. As an example, Interface Builder offers different sizes for many interface elements. Checkboxes can be either regular, small, or mini sized, and I actually prefer the small size to the default regular, but REALbasic only offers the regular size. There’s no option for an oval search field like what is shown in Safari. After some searching on the Internet, I’ve found custom classes and plug-ins that will offer these features, but these generally seem to be platform specific, and therefore not an option for software I write.
REALbasic’s target market seems to be divided between two types of users: the beginner and the professional developer. If you’re trying to learn programming on the Mac, you’ll save some money by beginning with AppleScript as the language and AppleScript Studio when you want to build software with a graphical user interface. Everything you need comes with your Mac, and the programming concepts you learn in AppleScript are easily carried over to REALbasic if you later need cross-platform compilation.
If you make your money from making software, and need a cross-platform solution for a backend database, REALbasic is a good solution. It has its own, different, imperfections when compared with FileMaker, and the documentation issue, while major, is offset by the helpful and experienced people on the mailing list. The simple ability to capture events, enabling much more powerful user experiences, makes REALbasic at least worth looking into. A major question for me that only time will answer, is how quick development will be within the software once I’m familiar and comfortable with it. My gut feeling, however, is that the learning curve will be worth it.