Chapter 8

Building Simple Channels

With the overview out of the way, let's get down to the specifics: how, exactly, you construct and publish your own channels. In this chapter, you'll learn about the channel publishing process, from creating the channel on your system to publishing it to testing the result in a tuner. And, as part of that process, you'll create two kinds of simple channels: HTML channels and applet channels.

Creating and Publishing Channels: The Basics

Let's start with a quick review of the basic things you should know to create and publish Castanet channels. They are the things that all channels have in common, and the procedures you'll need to follow when you create any channel, be it a simple HTML channel, an applet channel, or a sophisticated Java channel that can handle live updates and send data back to the transmitter.

The Channel Directory

Each channel you create should have its own directory on your local development system, which I'll call the channel directory from now on. That directory can contain all the parts of a channel, complete or not, including class files, HTML files, core files, revision-control directories, or anything else you need for that channel. Don't worry about keeping track of which files are for the finished channel and which are just for development; you'll decide which files are important when you actually publish the channel. Just make sure that each channel has its own directory, and you'll be fine.

In addition to the files you create in that directory, the following files and directories are created by the Castanet publish tool after you publish the file for the first time:

Castanet Publish uses each of these files to keep track of the channel itself (you could think of them as containing channel meta-information). You'll learn more about these files as you work through the chapter.

Using Castanet Publish

When you're ready to publish a channel, you use Castanet Publish to move the files to the transmitter (even if the transmitter is on the same machine as your local development directory). Because the transmitter keeps track of which files have changed and organizes the files in a special way, you must use Castanet Publish to publish the channel; you cannot simply copy it to the right place and hope it will work.

Castanet Publish is part of the Castanet Transmitter installation. You should have installed the transmitter on your local system so that you have access to the publish tool. Note that if you don't intend to run a transmitter on your local system, you don't actually have to start or run the transmitter itself.



Note

Chapter 6, "Installing and Publishing Channels," describes the Castanet Publish tool in detail. Although I provide a quick overview of its use in this section, you might want to refer to that chapter for more detailed information.


You can use Castanet Publish in two ways: as a graphical application, which allows you to step through the process of creating and publishing a channel, or as a command-line application, which allows you to automate the process after the initial properties of a channel have been set up. You can use either method for publishing your channel, although the command-line version of the publish tool does require that you already have set up the channel properties. You might want to run the graphical version of the publish tool at least once to create those properties; doing so is easier than creating them by hand.

You start the graphical version of Castanet Publish using the Start menu in Windows (Castanet Publish is located in the Castanet Transmitter group under Programs) or by using the publish command in castanet/transmitter/bin. The initial screen then appears; choose Channels to move to the main screen. (See Figure 8.1.)

Figure 8.1. The Main Castanet Publish window.

This screen shows (or will show) all the channels you're developing on your local system. To publish a channel, you need to add your channel directory to that list. Use the Add button to add your channel directory, indicating its full pathname in the Directory field. (See Figure 8.2.)

Figure 8.2. Add a new channel directory.

If your channel is new, you'll most likely want to use the Create button to convert your development directory into a channel directory. Use Add only if this channel has been published before, perhaps under a different name.



Note

Yes, this process is confusing. You would think that you'd use the Create button to actually create a directory that doesn't already exist, but in actuality you also use it to convert an existing directory into an actual channel directory. If you try to use the Add button to add a directory for a channel that has never been published before, you get a This is not a channel Directory error. Use Create instead.


Channel Properties

When you first set up a channel to be published by the Castanet Publish tool, you also need to set its properties. After the first time, if you need to change the channel properties, you can either change them inside the graphical version of the publish tool or edit the properties.txt file.



Note

In reality, you don't even need to run the graphical version of the publish tool the first time, either. You can create the properties.txt file by hand, or you can copy it from some other directory and modify it to fit the current channel. I find it easier to set properties with the publish tool, so that's how I describe it here.


To edit a channel's properties, all you have to do is double-click the name of the channel in the main Castanet Publish screen. The channel properties screen then appears.

Each channel has seven different properties panels: Transmitter, General, Update, Icons, Contacts, Description, and Parameters. I described each of these properties and their values in detail in Chapter 6, so I won't repeat that information here. Here's a quick summary:

After you choose Apply or Done in any of the properties panels, the channel properties are saved to the channel directory. Most of the properties are stored in the properties.txt file in the main channel directory, with the exception of the transmitter properties, which are stored in the properties.txt file inside the channel.dir directory, and the parameters properties, which are stored in the file parameters.txt.

Publishing and Testing the Channel

With the channel developed in its own channel directory and properties of the channel set, the final step is to actually publish the channel. To do so, you simply click the Publish button inside the graphical publish tool (you can find it on the properties panels), or you can use the command-line version of the publish tool. If the publishing process is successful, you can then use a Castanet Tuner to view that channel in a transmitter listing, or you can subscribe to and test that channel to make sure that it's working properly.

In many cases, you might not want to actually publicly publish a channel the first time you do it, particularly if you're not used to working with channels yet. In this case, publishing a not-quite-finished channel to a publicly accessible transmitter isn't the best of ideas. You can get around this problem in two ways.

The first solution is to publish the channel to a transmitter as a "hidden" channel. Hidden channels are available on a transmitter for testing (use Add Channel from the tuner with the actual name of the channel to subscribe to and test it), but they do not show up in the tuner listing for that transmitter. They therefore are effectively inaccessible to the public unless the public knows the name of that channel. To publish a hidden channel, use the Hide check box in the Description property panel. (See Figure 8.3.) You can "unhide" the channel by deselecting that check box the next time you publish the channel.

Figure 8.3. Hiding channels.

Another solution to the testing problem is to actually install and use two transmitters. The first transmitter is a private transmitter, perhaps installed on your development system itself or on another system available to your internal network (if you have one). This private transmitter acts as a "staging area" for your channels. You can publish your channels to this transmitter and then subscribe to them and test them as long as you like to verify that everything is working correctly. The transmitter that comes on the CD-ROM for this book is good for this purpose, since its limited to five users an hour.

The second transmitter is the public transmitter, the one that is accessible to other tuners anywhere on the Net. After you've tested your channel and it's ready to be viewed by the outside world, you can modify your channel properties and publish the final version of the channel to the external transmitter. You'll want to purchase an license a real transmitter from Marimba for your public channels so that a reasonable amount of users can access them (100 unique users per hour for the basic transmitter).

This mechanism of a staging area for new or untested channels and an external transmitter for finished channels also works for updates. If you're not sure an update will work, or if you want to test the effect of a change, you can publish the updates to the staging area and push the changes outside to the rest of the world only when you're done. And, of course, you're not limited to only one staging area; you could have multiple staging transmitters for local testing, beta testing, and final public versions. This process is similar to how many professional software projects and Web sites are developed; you can use this system for channels as well.

Creating HTML Channels

To take full advantage of the Castanet technology, most Castanet channels are best created as executable programs–as Java applets or applications, or presentations created with Bongo (or some combination of all three). As you learned in the preceding chapter, however, you can also create HTML Web sites that take advantage of many of the features of the Castanet channel technology. For example, HTML channels have these advantages over regular Web sites:

In this section, you'll learn how to put together an HTML channel: how to create the content, how to publish the channel on a transmitter, and how to test the result.

Create the Web Content

The first step, with an HTML channel or with any channel, is to create a channel directory for that channel and to put the actual content of the channel into that directory.

For an HTML channel, the channel directory you use is the topmost directory for your Web site–for example, the root of all your HTML files or your public_html directory if your Web site is stored in your home directory on a UNIX server. You can, in fact, develop your Web site somewhere else and then move it to a channel directory, or you can do all your development in that directory itself. Your channel directory can also double as your final Web directory; Castanet and Web servers are compatible with each other (neither mucks with the other's files), so you don't need to create separate directory structures if doing all your work in one is easier.

You'll find little difference between developing a Web site for use with a Web server or developing one for use as a channel. You can use almost any HTML content (text, images, embedded multimedia, forms, JavaScript, Java applets, and so on) to link between pages or to other URLs on the Web just fine without worrying about the differences between Web and channel distribution.



Note

Because so few differences exist between developing a Web site for use as a channel and developing a Web site for use with a Web server, I'm going to say very little about HTML or Web design here. If you're interested in looking at developing HTML channels in more detail but don't know a lot about creating Web pages, do pick up a book for that purpose–for example, Teach Yourself Web Publishing with HTML 3.2 in a Week, which I also wrote.


You also should watch out for a few differences. The biggest difference between an HTML channel and a normal Web site is that you cannot include CGI programs as part of that channel. CGI programs or scripts, by their very nature, run on a Web server. They cannot be downloaded and run as part of a channel; unlike executable Java programs, they are not designed to run on different systems, and might not even be secure.

The simplest way around this difference is just to make sure that your CGI programs are not part of your HTML channel; that is, make sure that you store your CGI programs outside the channel directory itself. This way, only the HTML files are part of the channel, and they can be downloaded and viewed as a channel. A reader using a browser to browse an HTML channel can access all the HTML content from a local disk as part of the channel, but CGI programs are sent back to the server for execution.

The second gotcha to be careful of when you're developing Web sites for channels is with automatically generated pages such as those created from databases or those that use server-side includes. As with CGI programs, both of these kinds of pages require processing on the server, so they do not work as channels. Only files that are actually stored as files on the Web server can be used in an HTML channel.

The final "gotcha" to mention is not to get too carried away. Unlike normal Web sites, which are downloaded page by page, channels are downloaded in their entirety the first time. If your Web site is especially large and you publish at all as a channel, your readers might balk when confronted with an exceptionally large channel download and not download your channel at all. It's usually a better idea to publish only a small portion of your Web site as a channel instead of the whole thing.

An Example: Lox-in-a-Box

Here's a simple example of an HTML channel (or rather, a small set of pages that you can use as an HTML channel).

The Lox-in-a-Box Web site is for a maker of smoked salmon (lox). The Web site for Lox-in-a-Box contains several pages with information about the Lox-in-a-Box company, its price lists, and a method for ordering lox over the Web (should you be inclined to do so).

Although the actual Lox-in-a-Box Web site might be quite extensive, for the purposes of this example, you can strip it down to the bare minimum files. For this example, the Lox-In-A-Box Web site contains only three files:

Figure 8.4. The Lox-in-a-Box home page.

These three files are in a directory called LoxBox, which you can use as the channel directory. I've included these files on the CD for this book; look in the Examples directory for all the examples from this book.

Create the Properties and Publish the Site

HTML channels are published like any other channels: you start Castanet Publish, add the HTML channel directory to the list of Channels Under Development, set the properties of that channel, and then choose Publish to move the channel to the transmitter.

To publish the Lox-in-a-Box channel, you start up the publish tool and add the LoxBox directory to the Channels Under Development screen.

Many of the channel properties you learned about earlier in this chapter and in Chapter 6 apply to HTML channels–for example, the transmitter properties and the channel description. The two that apply most specifically to HTML channels, however, are the General and Update properties.

For the General properties panel, you should have the Type of channel set to HTML. The field for Index Page should be set to the topmost "home page" for your channel–often a file called index.html in the channel directory. (It's called just that for the Lox-in-a-Box channel.) This page will be the first one that your readers see when they start up the channel. Ignore the class path field; the class path is not used for HTML channels. Figure 8.5 shows the settings for the HTML channel for Lox-in-a-Box.

Figure 8.5. General properties for HTML channels.

The other property panel you should check is the Update properties panel. Figure 8.6 shows this panel with the settings for the sample channel. Because HTML channels are not "real" channels per se, the values of the settings in this panel are somewhat superfluous. The only value you definitely need to set is the Inactive Channel Update Frequency; this value should be frequent enough to cover your intended changes to the site. For an HTML channel that changes fairly infrequently (for example, if the Lox-in-a-box prices change only once a week), setting this value to Weekly may be just fine. Set it to a more frequent value if you intend to change your channel more frequently.

Figure 8.6. Update settings for the HTML channel.

All the other settings in this panel refer to executable channels, not to HTML channels. To prevent the tuner from doing more work than it needs to do, you might want to set the Update Frequency of the inactive channel to "daily" or "hourly" and the Data Available Action value to "ignore."

Don't forget to set the channel descriptions and contacts. Also, make sure that your transmitter properties are set properly. Then click Publish to store the HTML files on a transmitter in channel form.

With normal Web pages, each time you make a change, that channel is automatically distributed to anyone who visits your site. In contrast, with HTML channels, when you make a change to a Web page (or to any number of pages), you must remember to use the publish tool again to update the channel. Otherwise, your readers cannot see the changes you've made. As you do with executable channels, always remember to use Castanet Publish to update the channel on the transmitter side after each change or set of changes.



Note

If you're familiar with the process of creating and publishing a Web site, you might think that using Castanet Publish is a clever way of updating a regular Web server–you just make your changes and run Publish to update the server. Unfortunately, because of the way the transmitter stores files and keeps track of the way a channel is organized, the files created by Publish on the transmitter cannot be directly served by a Web server. Publish is suitable only for publishing actual channels, not collections of files.


Test and Use the HTML Site

HTML channels, like all channels, appear in the transmitter listing from a tuner. You can browse and subscribe to them just as you do with other channels. (Figure 8.7 shows the Lox-in-a-Box channel available in a transmitter listing.) As you learned in Chapter 3, however, HTML channels behave slightly differently from "normal" channels: rather than starting up a window to run the channel, the tuner uses the default Web browser to view the HTML pages in the channel. The catch is that the Web browser must be configured to use the tuner as a proxy so that all Web connections go through the tuner. This way, the tuner can decide whether to load a page from an HTML channel or to visit a Web server over the network to retrieve that page. Configuring the Web browser in this way does not interfere with Web browsing other sites as long as the tuner is running at the time.

Figure 8.7. The Lox-In-a-Box channel.

When you first launch an HTML channel in the browser, the tuner reminds you that you need to configure your browser properly. (See Figure 8.8.) After you configure your browser (or if it's already configured), you can choose Launch to switch control of the browser and view the pages in the channel just as if they were contained on a Web site.

Figure 8.8. Browsing HTML channels.

In the case of the Lox-in-a-Box channel, each page in the channel is browsed from the local copy, although from the URL it appears to come from the Web itself. (The tuner manages whether the page is retrieved from the disk or from the network; it's transparent to the browser itself.) If the reader decides to order a product from the site, he or she can fill out the form and submit it. Because the CGI script to process the form is not part of the actual channel, the tuner knows enough to send the data from the channel back to the server for processing.

When you test an HTML channel of your own creation, you test it in the same way you would any other Web site: follow all the links both on and off the site to make sure that they all work properly. In addition, with HTML channels you should test all your forms and CGI programs to make sure that the data is sent over the network.

What about updates? If Lox-in-a-Box makes any changes to its site–for example, updates the price list or adds content to the Web page–the tuner picks up those changes when the channel is updated, just as it would for a regular channel.

Where to Go from Here

HTML channels simply provide channel-like behavior to a Web site, and as such are interesting only as an alternative way of distributing a set of Web pages. To take full advantage of the Castanet Technology for real channels, you actually should develop those channels in Java. If you've worked with applets in Web pages, then read on for an easy way to convert applets into channels.

Converting Applets to Channels

Although you can apply the Castanet technology to HTML channels, Castanet was designed to distribute executable programs written in Java. Much of the Java development that has gone on in the years since the language has become popular is in the realm of applets. Remember that applets are Java programs that runs inside Web pages. Most Java applets can be converted into Marimba channels with no modifications; you usually don't even need to recompile the Java code. As you do with the HTML channels, all you essentially need to do is set the channel's properties correctly when you publish the channel, and Castanet handles the rest.

You can also use applets as the basis for creating more sophisticated channels. For example, you can modify an existing applet to take advantage of such channel features as being able to save files to the user's local disk, to send feedback information back to the transmitter, or to handle running updates dynamically. You'll learn about each of these features in Chapters 11, "Managing Updates and User Information," and 12, "Creating Transmitter Plug-Ins."

In this section, you learn how to convert an existing applet (one that is already running successfully inside a Web browser) into a channel. You also learn a few of the differences between applets and channels; you may have to take these differences into account for your applet to work. (You'll find only a few differences; most applets should work just fine as they are.) In Chapters 10 and 11, you'll look at extending applets to take advantage of tuner and channel features.



Note

You don't necessarily need to know anything about Java to convert an applet into a channel, because most applets run just fine as channels. If you've been using precompiled applets in your own Web pages and know nothing about the Java language, you should still be able to follow along in most of this section. You should have a basic understanding of how the <APPLET> tag works, however.


Setting Up the Applet

As with HTML channels, the first step in converting an applet into a channel is to create a channel directory that holds the applet and its supporting files. That includes the applet class itself, any other class files the applet uses, and any other images, sounds, or other media. In fact, you need everything you needed to include the applet in the Web page, minus the HTML file that contained it (and having the HTML file along for the ride doesn't hurt).

If the applet source isn't compiled, go ahead and compile it with your favorite Java compiler. Then fire up your Castanet Publish; all you have left to do is set the properties and publish the channel.

Add your applet channel directory to the list of channels under development just as you did for the HTML channel. Double-click that channel directory to set the channel's properties.

As I noted with HTML channels, I won't go over most of the properties you need to set because most of them are common to every channel you publish. You should look at the General, Update, and Parameters property pages, however. In this section, I cover General and Update properties; see the next section, "Applet Parameters," for more details about the latter.

For the General properties panel, make sure that the Type of the channel is set to Applet. Figure 8.9 shows the general properties for applets.

Figure 8.9. General properties for applets.

The most important fields in this page are Code, Width, and Height. The value of the Code field should be the name of the main applet class. This is the same value that you use inside the <APPLET> tag for the value of the CODE attribute; however, here you indicate that value minus the .class extension. So, for example, if your applet class is called IconAnimator.class, the value of the Code field is IconAnimator.

The Width and Height fields set the width and height of the window in which the applet is displayed. These values are the same as the values of WIDTH and HEIGHT inside the <APPLET> tag. By default, the width and height of the applet are both 400 pixels. Make sure that you include the right width and height in these fields; otherwise, your applet may appear in a window that is too large or too small.

What about the other two fields, Code base and Classpath? The value of Code base is the location of your class files relative to the channel directory, used in the same way the CODEBASE attribute for the <APPLET> tag is used. If your class files are in the channel directory itself, you can leave Code base field blank. If, however, they're stored in a subdirectory–for example, one called classes–enter classes as the value of Code base.



Note

In applets used in Web pages, you commonly see values of the CODEBASE attribute that point to someone else's Web site. For example, the value of Code base might be something like http://www.mycooljavasite.com/applets/. You cannot do this for channels; all the class files must be located in your local channel directory for them to be published as channels.


Classpath is essentially identical to codebase for applets. This field indicates other directories in which to look for Java classes that might be used.

Figure 8.9 shows the sample settings for an applet called IconAnimator. These settings are equivalent to an <APPLET> tag that looks like this:

<APPLET CODE="IconAnimator.class" CODEBASE="classes" WIDTH=120 HEIGHT=120>

...

</APPLET>

You have slightly more control over the Update properties for applets than you do for HTML channels. (See Figure 8.10.) Applets can be active or inactive, so you can update them at different frequencies for each. Set both the Update Frequency menus to have values based on how often you intend to change the applet's code, its properties, or its parameters.

Figure 8.10. Update properties for applets.

For the Data Available action in the Inactive Applet Channels section, you have two choices: ignore or start. For active channels, you also have two choices: ignore or restart. For start or restart, the applet will do just that: launch if its not currently running or restart if it is.

The notify and install options are for channels that can handly dynamic updates. You can convert an applet into a real channel that can handle these kinds of updates; you'll learn about this in Chapter 11, "Managing Updates and User Information."

Applet Parameters

Most applets are written so that they can take different parameters, or options, which determine how the applet behaves when it is run. For example, a scrolling-text applet (one that produces a sort of marquee or LED screen) might have a parameter for the text to print, the color to print it in, and the speed with which to display it. This way, applets can be written generically so that they can be reused over and over again for different purposes.

These parameters to an applet are usually indicated as <PARAM> HTML tags inside the Web page that contains the applet. Because applets running as channels don't have a Web page, you need to specify the parameters to an applet in a different way.

Applet channel parameters are stored in a separate file called parameters.txt in the channel directory. As you do with the properties.txt files, you can either create this file by hand with a text editor, or you can use Castanet Publish to create it. To enter applet parameters, switch to the Parameters property panel in the publish tool. (See Figure 8.11.)

Figure 8.11. Applet channel parameters.

The parameters for an applet channel are key-value pairs that correspond to the NAME and VALUE attributes in the <PARAM> tag. Each key and value is separated by an equal sign, and each pair is on its own line. Say that you have a set of parameters that looks like this as <PARAM> tags:

<PARAM NAME=name VALUE="Laura">

<PARAM NAME=age VALUE="29">

<PARAM NAME=value VALUE="priceless">

These same parameters look like this as an applet channel:

name=Laura

age=29

value=priceless

Note that changing the parameters to an applet is considered an update to that applet. If you change the parameters, therefore, don't forget to publish the changes so that tuners can pick them up.

Publishing and Testing

Nothing else is special about applet channels. After you set the properties, you can publish the channel.

Applet channels, when they're run from a tuner, run in their own windows that are the size of the width and height that you give them inside General Properties. (That width and height is fixed just as it is with applets in Web pages.) Applet status and error messages that usually appear in the browser's status line or Java console appear in the tuner's Java console. (You can see the console by choosing Tuner | Show Console.) As with applets in Web pages, iconifying the applet window stops the applet's execution; opening the window again restarts it.

An Example: Scrolling Headlines

Although the process for converting an applet into a channel is rather straightforward, let's work through a simple example.

The applet to use for this example is a small, scrolling-text applet written by Matt Howitt. You can see it in action at http://www.fas.harvard.edu/~mhowitt/fun/index.html. Using applet parameters, you can configure not only the text string that scrolls by, but also the font, size, and style, the foreground and background colors, the direction (up and down as well as left to right and vice versa), and the speed. This applet makes a good basis for an updateable headlines applet, but for this example, you can simply convert it as is.

Download the source and class files for this applet into a directory called Scroller on your local system. (I've also included this applet as one of the examples on the CD; you can find it in the Examples directory.) You actually don't need the source file at all because this applet works as a channel without any modifications. You can bring it along because you'll need it later in the book. The class file is called ScrollingText.class.

Inside Castanet Publish, add the Scroller directory to the list of channels under development and double-click that name to bring up the channel properties. For the general properties, call the channel Headline Scroller and enter ScrollingText into the Code field as the name of the class file. For the size, use a width of 500 and a height of 50. See Figure 8.12 for these values.

Figure 8.12. Scrolling headlines general properties.

For the Update properties, you can assume that new headlines will occur fairly frequently, so set both the active and inactive updates to occur once per hour. An applet can't do much with actual actions, so set both to ignore any new data. Starting or restarting the applet displays the new headline.

Finally, you need to set the parameters. The original ScrollingText applet has several parameters. For this example, you can set several parameters: make the background color white (bgcolor=White), the foreground (text) color blue (fgcolor=blue), the font size 24 points (fontSize=24), and the direction of the scroll right to left (direction=RightLeft). Also add the text to scroll: text=New and Improved Headlines Scroller! Now with Argon!. Figure 8.13 shows the parameters as entered into the Parameters properties.

Figure 8.13. Scrolling headlines parameters.

After a quick check back to set the transmitter properties and to fill in the channel description and contact fields, you're effectively done. Click Publish, wait for the tool to generate and publish all the files, and then pull up your tuner. The headlines scroller shows up happily in the tuner listing, and subscribing to it launches the scroller in its own window. (See Figure 8.14.)

Figure 8.14. The Headlines scroller running.

On the transmitter side, you can change the headline or any of the other parameters for the scrolling headlines applet any time you want to, as long as you remember to publish the channel each time.

If you want to try out the ScrollingText applet, Table 8.1 shows a list of the parameters you can use with it.

Table 8.1. Scrolling text applet parameters.
Parameter Name Possible Values What It Means
text Any string The text to be displayed (default is none).
font Font name The font the text will be displayed in (default is Arial).
fontsize An integer The size the text will be displayed in (default is 36).
fontstyle Plain, Bold, The style the text
Italic, BoldItalic will be displayed in (Default is bold).
bgcolor Yellow, Blue, Black, The background color Red, White, Green, (default is white). Pink, Orange, or an RGB value (0,0,0)
fgcolor Yellow, Blue, Black, The color of the text Red, White, Green, (default is blue). Pink, Orange, or an RGB value (0,0,0)
delay an integer The amount of time, in milliseconds, the applet waits in between redraws (default is 50).
dist An integer The number of the text moves in between redraws (default is 5). This value and delay determine how fast the scrolling happens.
direction LeftRight, RightLeft, The direction the TopBottom, BottomTop text scrolls in (default is RightLeft).
valign Top, Center, Bottom The vertical alignment of the text. Ignored if direction is BottomTop or TopBottom (default is Center).
align Left, Center, Right The horizontal alignment of the text. Ignored if direction is LeftRight or RightLeft (default is Center).

Gotchas for Converting Applets to Channels

In most cases, you can convert applets to channels without any modifications. Castanet runs the applet inside a "shell" (the marimba.channel.AppletViewer class) that fools the applet into believing that it's running happily inside a browser. Some slight differences between applets and applet channels may require you to modify your program, however. Or you may have to handle behavior differently depending on whether the applet is running as an applet or as a channel. For example:

Note that showDocument() works just fine; it launches the user's default browser and displays the page there.

For applet channels, the base URL of the applet channel is tuner://host:port/channelname rather than http://host:port/directory/. Files local to that URL (extra media or text files) are loaded from the channel's directory rather than downloaded from a remote server.

If you're making live connections back to the server from which the applet channel came, you should extract the host and the port from the base URL and use HTTP rather than tuner as the protocol.

Note also that applet channels have the same security restrictions that regular applets do. You can modify an applet that, when it runs as a channel, can write state files to the channel's data directory. You'll learn more about how to do so in Chapter 11, "Managing Updates and User Information."

Summary

Congratulations! After only eight chapters, you've created some real channels that you can publish on transmitters and subscribe to on tuners. With HTML channels, you can publish a Web site as a channel so that your readers can download it all at once or read it without a live network connection. With applet channels, you can convert work that you've already done with Java and applets into channels. Later in this book, you'll use applets as the basis for real channels with real channel capabilities.