Volume Number: 19 (2003)
Issue Number: 1
Column Tag: Mac OS X

Building the Internet-Connected Application

Integrating the Internet into your Ideas

by By Dan Wood

You may have noticed that it's almost impossible to run an application on Mac OS X without it trying to connect to the Internet to do something. The operating system checks for updates to itself. iTunes queries a database when you insert a music CD. OmniGroup's applications have a menu that says "Check for updates." The list goes on.

Taking advantage of the fact that many Mac OS X installations have a permanent (or frequent) Internet connection is something that you can have your own application do as well, even if it's not primarily categorized as an "Internet Application." The purpose of this article is to give you some motivation to do so, and some hints about making it a good experience.

So what are some of the benefits of an application that connects the Internet? Here are just a few:

• You can make sure that your users are aware of new versions of your program being available. This is a great boon for support, because you will have to deal with users of older versions of your application less frequently if they are spoon-fed the newest version.

• Individual components of your application--plug-ins, templates, etc.--can be listed and downloaded directly from the application if you maintain a repository of these items. Watson, for example, allows users to download and install additional plug-ins directly from the program, rather than having to go hunt for them all over the Internet.

• Data about the user (what version of the application and OS she is running, for example) can be collected by a server.

OK, so you think it's a good idea to have a server going for your desktop application can connect to, but what if you aren't a "server-side" kind of person? Are you going to have to learn new technologies like WebObjects or PHP? Will you need to buy an XServe and host at an expensive colocation facility?

That depends. You can actually accomplish quite a bit without any server-side programming, and very basic Web deployment capabilities. How's that? Just keep it simple, and put all of your logic on the client --the desktop program -- and only data on the server.

Imagine the following scenario: You want to have your program connect to your server and determine if a new version of the application is available, so you can inform the user that they need to fetch the newest version. One approach is to send a message to your server and include the version of the application in that message. The server would then compare that value with the known latest version, and then either send back a message saying that the application is up to date, or a message saying that the user needs to upgrade. This, of course, would require programming on the server.

What if, instead, the client application just connected to the server and asked for the latest application version number. The client would then compare its own version with the number it received, and then decide whether or not to present an alert about application update availability.

This is the fundamental difference between a "smart" and a "dumb" server. The dumb server can merely be a static file that is served by your Web-hosting site of choice. If you're a Cocoa or Carbon programmer, you don't need to write code in an unfamiliar environment and find an Internet hosting service to host that server-side program for you.

Obviously, the Dumb Server approach will only go so far; some transactions are going to require logic on the server to react to parameters sent by the user. But here are some items that can be put into a static file on the server, that your client program can react to.

• Current application version number, as discussed above. The client compares it to its own version and presents a message, accordingly.

• URL of where to fetch the new version of the application. If an update is needed, the client could download the update directly.

• Description of new features. To motivate the user into downloading the upgrade, you could provide a small list of new features.

• Data that may be needed later in the execution of the application. If your program allows the user to view a list of online downloadable modules, templates, or documents, you could provide a list of all available files along with the other information, and tuck it away until it is actually needed. Such a list could also contain version numbers, so your application could make sure it has the most up-to-date versions of the available components.

• News and status. There's an interesting way to stay connected with your user base, by providing a bit of news that might display each time the application is launched. It could be a "tip of the day" that you maintain on the server; it could be a holiday greeting, it could be links to relevant Web sites.

You could even provide different variations of the information you provide, so users running your program in "demo" mode will view one type of information, while your paid users get different data. Or your data could depend on the OS version used so Mac OS X 9 users will see one message while Mac OS X users get a different one. You could either put all variants into a single file, and let the application pick out the appropriate piece; or you could have the application access different URLs depending on that status. For example, you might serve up two files on your site, and your application would fetch the appropriate one.

• http://www.mykillerapp.com/hello_unregistered.xml

• http://www.mykillerapp.com/hello_registered.xml

If your application is to be localized into different languages, you could also localize your messages as well. The client would request a file based on the user's primary preferred language (e.g. "hello_fr" for a French version). If that file doesn't exist, the client would then try again with the secondary language. If you don't think you'll be constantly adding new languages, you might want to put a limit on the number of attempts for your client to try, and store the best available language as a preference for the next time through.

So you think you need a little bit of logic on the server? Welcome to the world of client-server programming. You will need to determine just how much logic is going to go into your server and what kind of software and hardware you will need to run it. Unless you are building an application with high bandwidth and database needs, you can probably get by with a simple setup that is hosted on a service that costs about $10 per month and provides server-side capabilities such as PHP and MySQL or Postgres. Macintouch has some useful links at the following URL: http://www.macintouch.com/dotmacalt.html. You could get more sophisticated with WebObjects or other technologies, deployed on colocated hardware, but that is way beyond the scope of this article.

A smart server has a number of advantages; it can provide whatever information is appropriate to the parameters given in a request; if it is told your operating system, language, registration status, etc., it can deliver exactly the message you wish to deliver. It can deliver personalized, targeted information, as well. For example, your client application could send a request for a "Web postcard" to be sent, and provide the recipient's name and email address; your server could build up an image and email the postcard. This wouldn't be possible without some logic on the server.

If you are building Internet connectivity into your application, you need to make sure that the program behaves nicely. If the user doesn't have network connectivity, they might just be on a PowerBook, or they may have chosen to disable net access, perhaps if they are on a dialup connection. Just fail gracefully; you will probably have the opportunity to connect to the server later. Your program shouldn't nag the user too much if a new version is available; allow the user to stop telling you about the updates, or only show the reminder every so often. And don't initiate big downloads without the user's permission. They may be on a slow connection, and prefer to download things later.

It may be useful for you to pay attention to usage patterns of your application. Either for practical purposes, or if you are just curious, it can be useful to know something about your users, such as what version of the application they are using, or what version of the OS they are on. A "smart" server could take parameters passed from the server and add those data to a database. Even if you're just using a dumb server, you could perform some analysis on your web logs.

Be careful about privacy concerns! It is possible to have your client read user information (name, email) from the system settings, get addresses and phone numbers out of the address book, upload files in the user's home directory, and all sorts of unspeakable acts. The users of your program need to trust that you aren't writing "spy-ware." You should be liberal with the privacy statements in your program, and if your program does upload any information about individual users, you should be very clear about how that information is used and stored.

In creating your interaction model between your client and your server, you need to think about the directions that your application might be going, even if you don't plan on implementing any of these features for a while. Keep in mind that there may be thousands of users hitting your server for years to come, and they may be running version 1.0 of your software.

For example, you might want to include support for paid application upgrades. If you might want to charge a certain amount for version 2.0 or 3.0 of your program, you might want to provide upgrade price data, even if it won't be needed for a while.

Consider the possibility that your server may temporarily be unavailable to your users. What are the ramifications of that? You might want to provide a "backup server" URL in your application to try if the primary server doesn't work. Even if your primary server were "smart," you could have a backup server be just a static web page indicating system status, so your user would automatically get the latest news about your server if they were to connect and your primary server was unavailable.

Another consideration is your servers changing URLs. Imagine that you expand so much that you need to move your server, currently on your home IP address, to a different domain or subdomain. If you provided for a "forwarding address" in your server response, you could easily move people to your new domain. You should consider setting up a different subdomain to handle your server-side requests (even if it's just the same as your web server domain) so you could split it into a different machine in the future.

Finally, be sure to think about version compatibility between any plug-in or document files you may serve to your users. If you provide plug-ins, but your API changes between versions of your applications, you want to make sure that your users don't download plug-ins that won't work with your current application. If you might have a paid upgrade in the future, you want to make sure that users of your earlier versions of your program can still access their version 1.0-compatible plug-ins.

Now that you have decided to include some Internet connectivity into your application, how should you go about transferring information back and forth?

Before going much further, you should consider firewall issues. Most users have no problem accessing Web sites through Port 80, so unless you have some compelling need to do otherwise, you might as well go through that port. Naturally, if you will be transmitting confidential information, you're better off using SSL.

And unless there is a need for any real-time or open-ended connectivity, HTTP is a great protocol for simple request/response transfer. Your client makes a request, possibly sending some information along as parameters, and your server responds with what is effectively a Web page. Your client could perform a POST or GET; a GET is simpler because you can build up a simple URL of the form http://www.host.com/filepath?param1=value1. (Be sure to "escape" the special characters so that your URL is formed legally!) In Cocoa, you would just use NSURLHandle to fetch the contents of that URL. (If you need to use POST, Cocoa developers will need to dip down into Core Foundation or make use of CURLHandle (MacTech, Feb. 2002), available at http://curlhandle.sourceforge.net/.

The response that your server returns should be formatted as simply as possible. You could return HTML or plain text, but that would require some parsing on your server's end. You could return any XML format of your choosing, and your client would then parse the XML stream.

One trick that makes it especially easy for Cocoa applications to get at the data returned from the server is to format the file on the server as an XML property list! Even if your server is running Linux or Windows and knows nothing of this format, there's no reason why you can't place a "plist" file on your web server and have that streamed to the client. You could maintain and edit this file on your Mac, to make sure it's a readable format, and then upload it to your server when it changes. (See Listing 1 for an hypothetical example file. Note that we are able to place arbitrary HTML within our XML by surrounding it with the <![CDATA[ ... ]]> directives.)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST
1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CurrentAppVersionNumber</key>
<string>1.0.7</string>
<key>CurrentAppFeatures</key>
<string>This update adds sound effects, and fixes a crash when searching in 
Japanese.</string>
<!-- Below is only shown to unregistered users -->
<key>Unregistered News</key>
<string><![CDATA[
<font face="Lucida Grande">Thanks for trying out Popcorn!
<p>
Be sure to try out the new <b>Garlic Butter</b> module from
the <b>Popcorn > Install More Plug-ins...</b> menu.
</font>
]]></string>
<!-- Below is only shown to REGISTERED users -->
<key>Registered News</key>
<string><![CDATA[
<font face="Lucida Grande">As a thank-you for our
registered users, we are offering free downloads of
<a href="http://www.karelia.com/peanutbutter/">PeanutButter
1.0</a> for a  limited time.  Give it a try!
</font>
]]></string>
</dict>
</plist>

The client application can convert the data stream it gets from the server into a Cocoa object (generally an NSDictionary or NSArray) by adding this category method to NSData, shown in Listing 2. (Constructing the @interface section is an exercise left to the reader.)

propertyListFromXML
Create a property list given XML data retrieved from a server.
@implementation NSData( plist )
// Return a property list from the data.  Functions similarly to
// [NSDictionary dictionaryWithContentsOfFile:path]
- (id)propertyListFromXML
{
   CFPropertyListRef pList;
   CFStringRef errorString = nil;
   pList = CFPropertyListCreateFromXMLData(
      NULL,
      (CFDataRef)self,
      kCFPropertyListImmutable,
      &errorString);
   if(errorString)
   {
      NSLog(@"Error loading from Property List: %@",
         (NSString*)errorString);
      CFRelease(errorString);
   }
   return [(id)pList autorelease];
}

That about wraps up our little discussion on Internet connectivity. There are many other avenues that could be explored by innovative developers, but with just a little bit of work, it's possible to keep your users up-to-date.

Dan Wood once took an introductory Arabic class, but nobody in the room knew what language they were being taught. He likes to buy fruits and vegetables from the farmer's market on Tuesday mornings. He missed the last two days of WWDC this year due to the birth of his son. He is the author of Watson, an application written in Cocoa. Dan thanks Chuck Pisula at Apple for his technical help with this series, and acknowledges online code fragments from John C. Randolph, Stephane Sudre, Ondra Cada, Vince DeMarco, Harry Emmanuel, and others. You can reach him at dwood@karelia.com.