Location Manager Pref Treatment
Volume Number: 13
Issue Number: 9
Column Tag: develop
Preferential Treatment Under Apple Location
by Erik Sea
Apple Location Manager (ALM) is a suite of system software enhancements that
shipped in January, 1997, but unless you're a PowerBook user, you may not have
seen ALM in action. Later this year, however, you'll see a completely new version that
works on any Mac OS 8 computer, be it large or small, battery-powered or tethered to
the electrical grid. With increased availability, it's become even more practical to add
ALM-savviness to those services, tools, and applications that need it, and over the next
few pages we'll discuss some ways to do just that.
At the heart of ALM is the idea that many Mac OS users repeatedly fiddle with various
control panels and change preferences. They make these changes for a number of
reasons: a mobile user who travels from place to place needs to adjust to those
different environments, while a home user might have different settings for
telecommuting versus playing games. With ALM, the chore of going through and
repetitively changing a large number of settings is reduced to a single Control Strip
menu choice, once the collection of settings has been given a name. With this named
collection of settings and actions, known as a "location" in ALM, lengthy lists of
reconfiguration steps (some users even have these taped to their monitors or stuck to
their keyboards) should become a thing of the past -- provided the software they need
to configure is ALM-savvy.
Should you make your software ALM-savvy? Well, if you have a product that has
preferences that the user can change, directly or indirectly, the answer is yes! You
might think that your software's preferences are simple -- maybe not much more
than a simple "on-off" or two that the user can change with a click, but, in the larger
context, the user might want to turn your preferences on or off at the same time as
changing something else -- batch reconfiguration is a surprisingly common activity.
Consider turning file sharing on or off: file sharing is only useful when there is a
network around, and users might forget to turn it off at 37,000 feet, but if they've
defined a location called "Air Travel" that turns it off for them (and perhaps turns off
AppleTalk and dims the screen for better power conservation), they might just get a
few precious minutes of additional battery life over just dimming the screen -- but
will they remember to do it? With ALM, they only need to remember the details when
they create their locations -- from then on, they need only use those locations.
You might also think that your users generally don't change their preferences, and it's
true that many don't. However, you may want to consider whether they would if it were
easier and could be done in concert with other changes to their environment. Some
applications nest their preferences so deep in subpanels that the utility of making the
change is offset by the cost of making it -- but what if it were easier? I'm sure you're
starting to see what I'm getting at.
There are many ways for your software to interact with ALM, including some I
probably haven't thought of. I'll present some in my allotted space, but please do get
in, explore, and create things that just make sense -- the ideas are simple, but the
uses are numerous!
Ways and Means
A developer once commented to me that ALM is one of the simplest, yet most complex
pieces of system software to come along in a while. While you may shy from such
paradoxical remarks, they correctly reflect the continuum of development options at
your disposal -- ALM-savviness can take many forms, ranging from tight integration
with your software to standalone ALM modules written by third parties for your
products.
One of the first ALM modules written outside Apple was an ALM module for Apple's
OT/PPP developed, as shareware, by Prime Computing Systems and available on the
web at http://www.primecs.com.
ALM modules are generally self-contained preference-swappers that cooperate to
varying degrees with the software that owns the preference in question. The tighter the
integration, the better the user experience, but you can certainly start out with looser
coupling and improve it as revisions to your product permit. ALM modules implement
some or all of the ALM module API, and are placed in the Location Manager Modules
folder, inside the Extensions folder. I'll discuss module development shortly.
There are other types of ALM modules, called action modules, that, rather than
swapping preferences for a piece of software, perform an activity that may or may not
be associated with a specific piece of code, but just automate the process of doing some
sequence of steps during a location switch: opening a file, for example. For more on
action modules, and the slight differences between their API and the API of standard
modules (for example, one of the "optional" calls for a standard module becomes
"required" for an action module), see the ALM SDK.
To find the latest ALM SDK, go to our web site at http://devworld.apple.com/dev/alm/,
or see the Mac OS SDK on CD. To take advantage of the newer features of ALM 2.0, be
sure you're using the SDK's interfaces and libraries -- older versions of these
components may have come with your development environment, and don't have all of
the new features. See "Whatcha Got?" for information on testing for the availability of
features.
The ALM engine -- that is, the part that provides the core services related to
switching -- has a public API that developers can use to enumerate the user's
locations, create new locations, or switch locations. We'll cover the ALM API later.
Finally, although ALM modules can provide a great deal of flexibility to a developer
who wishes to become ALM-savvy, but there are cases where a piece of software might
benefit from a deeper knowledge of what the engine is doing. There is the API, as
mentioned earlier, but you should know that it can be used in clever ways that might
be appropriate for some software that would benefit from even tighter integration
with ALM. A hypothetical example of this kind of location-awareness, going beyond
mere ALM-savviness, is discussed in the latter part of this article.
WHATCHA GOT?
As with any system software from Apple, there are means for testing what features are
present in ALM, since the features have changed from version 1.0 to 2.0.
gestaltALMVers
This selector returns the version of the ALM engine that is installed on the
machine.
gestaltALMAttr
This selector returns a bitfield representing engine functionality with the
following bit meanings:
• gestaltALMPresent is on if ALM is installed; it's possible, on some
hardware, for the selector to be defined but for this bit to be off, so
check!
• gestaltALMHasSFLocations is on if the Get, Put, and Merge location
calls are implemented.
• gestaltALMHasCFMSupport is on if the engine recognizes
CFM-based modules, otherwise only Component Manager modules are
directly supported.
• gestaltALMHasRescanNotifiers is on if notifications for changes in
the names or number of locations will be sent via callbacks and Apple
events; otherwise, only notifiers for switches are generated.
With so many options to choose from, it might take a while to figure out how your
software and ALM might collaborate. So, as you dive into the rest of this article, keep
in mind that there is often more than one path to ALM-nirvana, er, savviness, but the
sooner you start, the sooner you'll arrive. Setting aside philosophical opinion, let's
look at the path most traveled first.
Magnificent Modules
For most situations, the ALM module provides the easiest and best-encapsulated way to
get your software plugged into the ALM engine. The calls that an ALM module supports
are very general: a module (or any software it interoperates with) doesn't need to
know anything about locations or how the ALM control panel works, just how to
interact with the software it represents.
Just What Is A Module Anyway?
It is difficult for me to describe what an ALM module is or does without showing how
the user interacts with them. To define a location, the user runs the ALM control
panel, and picks "New Location" from the File menu. All location editing is done from
the main window, seen in Figure 1. In the top part of the window, we see the current
location (that is, the location a user switched to in the past or the location the user is
"in" right now) specified by a pop-up. The user can switch from this pop-up or
switch from a similar menu in the control strip.
Figure 1. Apple Location Manager main window, in expanded mode.
The disclosure triangle toggles display of the bottom half, where a second pop-up
shows the name of the location to be edited. As you can see, it's possible to edit locations
that are not the current location, which creates some special issues you might have to
deal with. More on that later.
At the left side of the window, we see a list of modules that ALM knows about -- they
are located in the Location Manager Modules folder. Each of these modules has a value
associated with the edit location, and a description of that value is displayed at the
right when the associated module is selected at the left.
Modules are ordinarily listed in alphabetical order, and the list order is the order that