REALbasic Cross-Platform Application Development

REALbasic takes a different approach and creates a user interface that is compiled into native machine code for each application. There is nothing like Java's Virtual Machine; REALbasic apps are apps just like any other. Although REALbasic uses native controls when possible, in some instances they have REALbasic-specific implementations (the ListBox is an example). In those cases, there can be some minor differences between REALbasic and a native app, but the interface is responsive and quick.

Despite these differences, REALbasic has gone to great lengths to shield the developer from most (but not all) of the differences between the underlying systems. However, there is no avoiding the fact that you will encounter meaningful differences in the way that certain things work on different platforms; it is absolutely essential that if you plan to deploy your application on multiple platforms, you test them accordingly.

Some of the differences can be subtle and can manifest in the way that text and binary data is handled, the order in which events are fired, and how users expect to interact with the application itself. This chapter will focus on the more generalized differences, particularly those that impact user interaction with your application. Throughout the rest of the book, I will provide platform-specific information when necessary.

There are also several platform-specific classes provided by REALbasic. My focus in this book is the cross-platform aspects of programming in REALbasic, so I will limit the amount of space I devote to those classes, unless you really need to use them to provide basic functionality on that platform. For example, I'm not going to provide an in-depth and comprehensive look at AppleScript and the AppleScript classes provided by REALbasic.

A Note About UNIXlike Systems

The word UNIX is trademarked, and to be called UNIX, an operating system must be certified. Both Macintosh OS X and Linux are said to be UNIXlike systems, a phrase whose intent is to avoid trademark issues. The goal of Linux developers is for Linux to be compatible with UNIX in practice, even if not certified as such. The code used to develop Linux was written from the ground up for that purpose, and it does not use any actual code from UNIX-related systems like FreeBSD. Although OS X was, in fact, based on FreeBSD (BSD refers to the Berkeley Software Distribution of UNIX, a version developed at U.C. Berkeley), it has not been certified. There apparently has been a little quibbling over the fact that OS X is billed as being built on UNIX even though it lacks certification. In any event, throughout this section I'll refer to both Linux and OS X as UNIXlike systems.

The RSS Reader Application

Throughout the rest of the book, most of the examples are going to be used to create an RSS Reader application from the ground up. RSS stands for Really Simple Syndication, or something like that, depending upon whom you ask. It is a simple XML format that websites use to syndicate their content. In the web world, syndication usually means letting another website display headlines and story summaries from your site on their site. A lot of people use RSS as a way to view a website's content in a more convenient way. Software applications developed for this purpose are called RSS Readers.

An RSS Reader works by maintaining a list of URLs for RSS files that you are subscribed to. At predetermined intervals, the reader gets a copy of the file and stores it locally on your computer. It converts the RSS format into HTML to read it.

In this chapter, I will show you the basic steps required to set up an application that will be compiled for Windows, Macintosh, and Linux computers. This is a good point to review some of the differences between the three platforms because the platforms you are building for impact a variety of things, including the name that you choose for your application.

Compiling Applications

In the Quick Start, where the HTMLViewer application was introduced, I ran the application by clicking the Run button in the IDE. This compiled the application and launched it. When you are actively developing your application, you will run it this way. When a REALbasic application is run from the IDE like this, it's in Debug mode, which allows you to use REALbasic's excellent debugging tools. However, after you are finished programming your application, you will want to compile it. The compiler takes the source programming code written by you, the programmer, and converts it into the binary format suitable for the target application.

To compile an application, there are a few things you need to do. Actually, you don't have to do anything. You could compile an empty project if you wanted to, but there are a few things you will probably want to do before you compile the application. If you are using the Professional Edition, you will need to decide which platforms to compile your application for and what you are going to call it. It is especially important to decide up front whether your application will be running on multiple platforms because that will impact how you proceed.

You probably recall that when you create a new desktop application project in REALbasic, there are a few classes that get prepopulated in the integrated development environment. These are classes that have certain special characteristics, the most important of which is that they are all instantiated automatically when the program is launched. They are as follows:

App MenuBar1 Window1

In this chapter, I will focus on App (which is a subclass of the Application class) because it represents the actually application and the App object is always available to your program. Many of the properties of the App class refer to the platform for which the application is being compiled, so to understand what those properties mean, you must first know a little bit more about the platforms on which the application will be compiled.

The operating systems that REALbasic compiles for are similar in many waysthey all have a graphical user interface and rely on a desktop metaphor to organize files and directories into documents and folders, and in most cases, the user interaction is very similar. But there are also some important differences in the user interface, the way that windows are displayed, and how files are named, and where they get stored.

Windows

The progenitor of the modern Windows operating system is DOS, an acronym for the unimaginative moniker Disk Operating System, which Microsoft developed for use in IBM's personal computers (a precursor to DOS was known as QDOS, which reportedly means Quick and Dirty Operating System). There are DOS variants, not all of which were produced by Microsoft. The Microsoft versions are called MS-DOS, to contrast with IBM's PC-DOS and other non-Microsoft variants.

Even though DOS is ancient history, the DOS legacy is still readily identifiable in the modern Windows operating systems. Whereas Macintosh and Linux operating systems have their roots in UNIX, Windows has its roots in DOS. Although DOS was not derived from UNIX, it uses some UNIXlike concepts such as the shell, which provides a command-line interface to the underlying operating system.

The file system used by DOS is FAT (or FAT16), another one of those engaging acronyms that means File Allocation Table. The most memorable feature of this file system was that filenames were limited to eight characters, followed by a period, and a three-character extension. Although it is possible to come up with a large number of unique filenames using this system, it is almost impossible to do so in a meaningful way using descriptive names.

The first version of Windows was released in 1985 and was really just an application that ran on DOS. Windows 3.1 (released in 1992) represented a much more mature operating system, one that was capable of multitasking and using virtual memory. Windows represented Microsoft's version of a graphical user interfaceone which was designed to be very similar to that of the competing Macintosh systems.

With Windows 95, Windows began to rely less on DOS for operating system services (for instance, it no longer relied on file-system services from DOS). Windows also adopted the FAT32 file system, which allowed the use of long filenames. Windows 98 followed, and the last of this line of development was Windows ME (the ME is for Millennium Edition, because it was released in 2000).

The current versions of Windows are rooted in Windows NT, which was a version of Windows developed for business users and was intended to compete in the corporate server market. It was first developed in 1993. Microsoft eventually decided to combine its operating system products into one system, so that both consumer-oriented and business-oriented systems would be built on the same underlying technology. In 2001, Windows XP represents that unified approach to operating systems. Microsoft still markets different operating systems to different end users, but all of them are built on the same basic technology. Current variants are

  • Windows XP Personal Edition

  • Windows XP Professional Edition

  • Windows Server 2003

Macintosh

Apple computer develops both the hardware and the operating system for Macintosh computers, which means that there is a tight connection between the two.

There are two lines of development worth noting. The first is that of the processors used by the Macintosh operating system, and the second is that of the operating system itself.

When Macintosh computers were first released in 1984, they used processors from Motorola's 68K line of microprocessors. In 1995, Macintosh switched to PowerPC (PPC) processors. To provide developers a relatively painless transition, applications were compiled into binary code that could run on both 68K Macs and PPC Macs. Code compiled into this format is called PEF (or CFM).

Macintosh recently announced that it was abandoning the PPC platform in favor of Intel processors, and this represents the third round of hardware changes.

In addition to changing the underlying hardware, Apple also made a revolutionary overhaul of its operating system that was released in March, 2001, called OS X. This was the replacement for System 9, the last version of the original Mac operating system.

OS X was a completely redesigned system based on the FreeBSD/Mach-O distribution of UNIX and technology originally developed by NeXT Computing. With such a major transition in operating systems, Apple found that it needed to help developers make the transition. Now, instead of compiling applications to run on two different processors, Apple needed to produce software that could run on two different operating systems.

The answer to this problem was Carbon, a C library based on the old Macintosh Toolkit that allowed developers to write applications that would run on both System 9 and OS X. In addition to Carbon, there is Cocoa, which is an Objective-C object library used to build modern OS X applications.

Linux

Linux is a UNIXlike operating system created by Linus Torvalds. Unlike Windows and Macintosh operating systems, the source code is freely available and anyone can use it. Because it behaves like UNIX, you will find there are more similarities between the way that modern Macintosh computers work and a Linux workstationat least in terms of the command-line environment, file system, and reliability.

Linux was originally developed for x386 machines (like Windows), but it is now capable of running on a variety of platforms. Linux applications compiled by REALbasic work only on x386 platforms, though. The requirements are that the Linux installation should run GTK 2.2 or greater and have CUPS installed, but REALbasic officially supports only Red Hat and SUSE distributions.

Even though Linux is not UNIX, there are compatibility layers that emulate Linux on UNIX machines. For example, I was able to get REALbasic CGI applications to run on FreeBSD. Contemporary distributions of FreeBSD include a Linux compatibility layer, but it is usually not turned on by default. There is more than one compatibility layer, and they are based on different Linux distributions, so the key is to use a compatibility layer based on a Linux distribution that REALbasic is compatible with. In this instance, I used a Red Hat-based compatibility layer. You can read more about compatibility layers on the FreeBSD website, http://freebsd.org/.

Technically speaking, Linux refers to the kernel and not all the other software that comes with it. One consequence is that there are different desktop environments, with slight differences among them. The two leading contenders are the KDE desktop environment and Gnome. REALbasic applications should work on both, but there may be differences.

While writing this book, I tested the sample applications on SUSE Linux 9.2, using the KDE desktop environment. I have made every effort to make sure the Linux information is comprehensive, but I should also say that I think it's a good idea to double-check your application on both KDE and Gnome, if possible. Also, at the time of writing this, the Linux implementation of REALbasic was trailing the Windows and Macintosh implementations, and the final version had yet to be released.

Категории