What is a string?

---

I am very new to the iPhone SDK. And I hear the word strings alot, but I have no idea what they are. Could some one explain to me what strings are?
Thanks!

Do we see another flashlight app on the horizon?  The best part is that some helpful members actually made an effort to answer the question.  Amazing.

I guess that you have to start somewhere, but…

As we’ve been pondering these imponderables, this “report” from Retrevo caught my attention.  From a business manager’s perspective, the money quote is:

… they [iPhone owners] use their smart phones more for activities like watching videos, checking sports scores, and texting and they even watch more adult material on their iPhones than BlackBerry owners.

That certainly sounds productive!  (I’m listening to Mötley Crüe on my iPod Touch as I write this.)

A cynic reading the Retrevo post might jump to the conclusion that iPhone owners are shallow, arrogant narcissists.  In fact, the post concludes with the following:

… sure paints a picture of a group of smartphone owners that “think different,” and another more down-to-earth, mainstream group of BlackBerry owners.

I was particularly struck by the final chart presented in the post.  Respondents were apparently asked to rank themselves with respect to several “coolness” characteristics.  I think that the self assessment is very telling:

… iPhone owners rated themselves higher as Intellectuals, Extroverts, and Media Buffs than BlackBerry owners

Source: Retrevo Blog: iPhone vs. BlackBerry Owners: Your Phone Tells All

With that in mind, I’m finally ready to get around to making a point.  The carefully crafted iPhone user experience is unparalleled for media consumption and gaming.  It’s in a class by itself.  The thing is, though, that Apple puts up a whole fortress of barriers to developers that want to build real solutions to business problems and make their software available on a range of mobile terminals.  Sure, you can hammer on your app to fit it into the Apple template (and you might even be able to get it approved), but why bother when you have so many more degrees of freedom and device choices with Android / Linux (unfortunately, I don’t know as much about developing for BlackBerry OS 5.0).  Until recently, the answer boiled down to 40M+ iPhones / iPod Touches, against pretty weak alternative hardware.  Perhaps this is starting to change.

 [myLbl setFont:[UIFont fontWithName:@"Helvetica-BoldOblique" size:20]];

and

UIFont *font = [UIFont fontWithName:@"Zapfino" size:titleSz];

   NSArray *names = [UIFont familyNames];
   NSArray *fontFaces;
   NSLog(@"FONT NAMES");
   for (NSString *name in names)
   {
      NSLog(@"Font Family:  %@",name);
      fontFaces = [UIFont fontNamesForFamilyName:name];
      for (NSString *fname in fontFaces)
      {
         NSLog(@"              %@",fname);
      }
   }

FONT NAMES
  Font Family:  Courier
                Courier
                Courier-BoldOblique
                Courier-Oblique
                Courier-Bold
  Font Family:  AppleGothic
                AppleGothic
  Font Family:  Arial
                ArialMT
                Arial-BoldMT
                Arial-BoldItalicMT
                Arial-ItalicMT
  Font Family:  STHeiti TC
                STHeitiTC-Light
                STHeitiTC-Medium
  Font Family:  Hiragino Kaku Gothic ProN
                HiraKakuProN-W6
                HiraKakuProN-W3
  Font Family:  Courier New
                CourierNewPS-BoldMT
                CourierNewPS-ItalicMT
                CourierNewPS-BoldItalicMT
                CourierNewPSMT
  Font Family:  Zapfino
                Zapfino
  Font Family:  Arial Unicode MS
                ArialUnicodeMS
  Font Family:  STHeiti SC
                STHeitiSC-Medium
                STHeitiSC-Light
  Font Family:  American Typewriter
                AmericanTypewriter
                AmericanTypewriter-Bold
  Font Family:  Helvetica
                Helvetica-Oblique
                Helvetica-BoldOblique
                Helvetica
                Helvetica-Bold
  Font Family:  Marker Felt
                MarkerFelt-Thin
  Font Family:  Helvetica Neue
                HelveticaNeue
                HelveticaNeue-Bold
  Font Family:  DB LCD Temp
                DBLCDTempBlack
  Font Family:  Verdana
                Verdana-Bold
                Verdana-BoldItalic
                Verdana
                Verdana-Italic
  Font Family:  Times New Roman
                TimesNewRomanPSMT
                TimesNewRomanPS-BoldMT
                TimesNewRomanPS-BoldItalicMT
                TimesNewRomanPS-ItalicMT
  Font Family:  Georgia
                Georgia-Bold
                Georgia
                Georgia-BoldItalic
                Georgia-Italic
  Font Family:  STHeiti J
                STHeitiJ-Medium
                STHeitiJ-Light
  Font Family:  Arial Rounded MT Bold
                ArialRoundedMTBold
  Font Family:  Trebuchet MS
                TrebuchetMS-Italic
                TrebuchetMS
                Trebuchet-BoldItalic
                TrebuchetMS-Bold
  Font Family:  STHeiti K
                STHeitiK-Medium
                STHeitiK-Light
  

Happy Fonting!

The cause is the following code in SoundEngineEffect::PlaybackProc()

  if (THIS->HasAttackBuffer())
  {
    ALint numBuffersProcessed = 0;
    while (numBuffersProcessed < 1)
    {
       alGetSourcei(THIS->GetEffectID(), AL_BUFFERS_PROCESSED, &numBuffersProcessed);
         AssertNoOALError("Error getting processed buffer number", end)
    }

While the attack buffer is playing, you’re in a tight polling loop waiting for it to complete.  This is no problem if the preamble is really short, but for OpenGL games, it’s going to cause problems for any sound longer than a fraction of a frame.

The fix, fortunately, is simple.  Sleep this thread for a few milliseconds each iteration of the polling loop in order to give the rest of your application a chance to run.

The modified code is:

  if (THIS->HasAttackBuffer())
  {
    ALint numBuffersProcessed = 0;
    while (numBuffersProcessed < 1)
    {
       alGetSourcei(THIS->GetEffectID(), AL_BUFFERS_PROCESSED, &numBuffersProcessed);
         AssertNoOALError("Error getting processed buffer number", end)
       usleep(5000);  // Sleep for 5 mS each polling loop
    }

This little change makes all the difference for this bit of code and makes it suitable for long (> 1second) preambles.

I’ve found SoundEngine to work pretty well, although I have had to make a number of modifications to it for my specific application.  However, I think I’m at the point where I need to write my own OpenAL sound processing class library.  I’d be interested to hear from some of you to see what you’re using for game sound.

My hesitation has been based on the fear of losing potential customers who haven’t upgraded to the newest version of the OS.  Fortunately, a number of apparently independent sources are suggesting that uptake of the new OS is much faster than I might have expected.  With this latest news, it’s starting to look like we’ll cut over completely to 3.0 much sooner than I’d originally planned.

Here’s some of what I’m looking at:

Paul, over at Tapbots is reporting (dated 2009.06.23) that:

“It’s pretty clear that at least our customers are upgrading to 3.0 at an incredibly fast pace.”

“… running at an overall 75% upgrade rate which is pretty insane considering the number of devices and the fact that its only been 5 days.”

“The iPhone upgrade rate is a bit higher then the overall rate, currently sitting at 79%.”

“… the iPod Touch has just passed 50%.”

The post also has some nice graphs of what they’re seeing.  They promise to update the post as new information comes in.  I’ll be checking back periodically.

In a similar vein, AdMob just published a report (Their graphs are dated 2009.06.20, so this covers just a few days after the iPhone OS 3.0 software was generally available) that also suggests strong, albeit somewhat lower uptake rates for the iPhone:

…44% of iPhone ad requests coming from the 3.0 OS

AdMob’s data suggests that just 1% of requests coming from iPod touches are originating with devices running 3.0.

For as long as they continue to be available, here are the charts from AdMob:

and

Of course, it’s always possible that we’re seeing sample bias in these two reports.  Perhaps customers of Tapbots and users of apps that present AdMob ads are not representative of the total population.  However, I’m inclined to believe the trend, if not the specific figures.  The 3.0 upgrades are too compelling (and free for iPhone users) to ignore.  I predict that we’ll see 80% adoption across the board by the end of July.

It will be fascinating to see how these numbers change over the next couple of weeks, but I’m now thinking that we’ll jump to 3.0 even sooner than I’d planned.  These trends suggest that we’ll be able to continue to address the mainstream iPhone market, while allowing our development team to be more focused on building good new stuff, rather than testing on permutations of OS versions.

What kind of conclusions are you reaching about this?  Please let us know.

 
——–
Technorati Tags:  iPhone, iPod Touch, Apple, mobile, iPhone OS 3.0

Unfortunately, it didn’t work.  I ended up writing a bunch of needlessly complex code that sort of emulated the behavior that I wanted.  I almost decided to abandon the functionality because I couldn’t get it to work reliably in all situations.  I knew that there had to be a better way to solve this problem.

Some of the challenges include:

• First, touchesBegan:withEvent: gets called every time a finger touches the screen.  Thus, if the second finger touches just a tiny bit later than the first, touchesBegan:withEvent: actually gets called with two separate single touchesBegan events.  It’s easy enough to have a test to see whether the app is already processing a touch, but there are potential reliability issues with this because I have to guarantee that the touch state will always be cleaned up, or I might not be able recognize a legitimate touchesBegan:withEvent: call.
   
• Second, when the set of touches is presented to touchesMoved:withEvent:, a given set may contain a touch point from either finger, or both fingers.  If I get touches for both fingers, the order is predictable (first finger’s touch in element 0, second finger’s touch in element 1), within the scope of a single touch sequence (down, move, up).  However, if I only get one touch point, it could be from either finger, so I thought that my code had to try to sort out whether it could process the point, or not, by filtering for an “acceptable” delta (I saw this technique in some sample code).  I could use a heuristic technique to do this, but it’s really just a best guess.  Of course, this filtering can make for confusing gameplay, because the user thinks that they’re moving their the puck sprite, but if the “master” finger isn’t moving as fast as the “secondary” finger, the sprite may not behave as they are expecting.
   
• Finally, each time the player lifts either, or both, finger(s), touchesEnded:withEvent: gets called, and I had to figure out which finger had actually lifted so that I could take the appropriate action.

After stewing about the problem overnight, I dug into Apple’s documentation and found the answer.  Unfortunately, the code samples that I referenced when I wrote iPuck completely ignore this method.  In the discussion below, I’m focusing on two fingered multi-touches, because that’s the simplest scenario.  Everything that I say, however, extends completely to n finger touches.

Most of the sample code running around handled single touches in a fashion something like this:

NOTE: THIS ONLY WORKS RELIABLY IF YOUR VIEW DOES NOT HAVE MULTITOUCH ENABLED

- (void)touchesBegan:(NSSet*)touches withEvent:(UIEvent*)event {
    // get the first touch
    UITouch *touch = [touches anyObject];
    if ([touch view] == myView) {
        CGPoint touchPt = [[touches anyObject] locationInView:myView];
        // do something with the point …
    }
}

- (void)touchesMoved: (NSSet*)touches withEvent: (UIEvent*)event {
    // drag the sprite object along.
    CGPoint pt = [[touches anyObject] locationInView:myView];
    // do something with the new pt.
}

- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event {
    // If the touch was in myView, handle it.
    UITouch *touch = [touches anyObject];
    if ([touch view] == myView) {
        // clean up
    }
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
    // If the touch was in the myView, handle it.
    UITouch *touch = [touches anyObject];
    if ([touch view] == myView) {
        // clean up
    }
}

My first effort, as described above, was to simply convert the set of touches into an array and try to figure out what I was getting.

…
    NSArray *touchArr = [touches allObjects];
    NSInteger touchCnt = [touchArr count];
    UITouch *newTouch;
    CGPoint pt;
    if (touchCnt >= 1) {
        newTouch = [touchArr objectAtIndex:0];
        pt1 = [newTouch locationInView:myView];
        // do something with pt1
    }
…

Sadly, this didn’t work very well, so I went to Apple’s excellent documentation.  The answer to my problem is right there, in the UITouch Class Reference document:

A UITouch object is persistent throughout a multi-touch sequence.

That’s it!

I quickly changed my code to keep track of the specific UITouch objects.  We can organize these touch objects in a number of ways, including static module variables, an array of UITouch*‘s or an NSMutableDictionary (indexed by the touch objects’ IDs), depending on the specific requirement of the situation.

This allows me to do things like

…
static UITouch *g_firstTouch = nil;
…

- (void)touchesBegan:(NSSet*)touches withEvent:(UIEvent*)event {
    // get the first touch
    NSArray *touchArr = [touches allObjects];
    NSInteger touchCnt = [touchArr count];
    UITouch *aTouch = [touchArr objectAtIndex:0];
…
        if (([aTouch view] == myView) && (g_firstTouch == nil)) {
            // keep track of the first touch object in the view.
            // this touch will represent this finger for the duration
            // of the sequence
            g_firstTouch = aTouch;
            // more stuff.
… code to loop through the touchArr doing other processing not shown …

- (void)touchesMoved: (NSSet*)touches withEvent: (UIEvent*)event {
… looping code not shown …
        if (aTouch == g_firstTouch) {
            //do something apppropriate
…or…
    if (firstTouchNotInSet) {
        // the touchesMoved method was called, but our first touch
        // wasn’t in the set, use its current data
        CGPoint pt1 = [g_firstTouch locationInView:myView];
        // do something with pt1
…

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
… looping code not shown …
        if (aTouch == g_firstTouch) {
            // the first touch is over, do something appropriate.
…

 
Notes:

• I extracted this code from our apps, and tried to make it generic to illustrate the points.  I didn’t recompile/retest the extracted code, so I may have botched the process a little bit – apologies in advance
• Don’t forget that you have to enable multi-touch, it’s disabled by default.  You’ll need to set the multipleTouchEnabled property:  [myView setMultipleTouchEnabled:Yes];
• The timestamp property of UIEvent can provide another way to organize your app’s events
• For sprite movement, I typically have to apply deltas to the previous sprite location, I’ve always kept track of the previous touch point within my touchesMoved:withEvent method.  It turns out that this isn’t strictly necessary, as UITouch has the
  - (CGPoint)previousLocationInView:(UIView *)view
  method, which provides the exact same functionality – I haven’t verified the performance impact, but it could simplify your code.
• After all of this, I decided that I didn’t like two-finger dragging for controlling the player sprite. Multi-touch is great for swipes and gestures, but it doesn’t seem to lend itself to the quick movements and rapid direction changes needed to play the game, so I came up with a completely different interface implementation for v1.1 of iPuck.

 
Bottom Line:

We can take advantage of the fact that each specific UITouch object spans the duration of a down / drag / up operation to unambiguously identify each touch and track it from touchesBegan: through touchesMoved: and take appropriate action at touchesEnded:.  This allows us to reliably track the movement of each individual finger through the touch sequence and to respond appropriately to calls when not all of the fingers are represented in the touch set.

 
——–
Technorati Tags:  iPhone, iPod Touch, Apple, mobile, multi-touch, iPuck

With 3.0, several methods that were used in 2.x.y are now deprecated.  Use of these methods will generate warnings in 3.0.  Unfortunately, the correct code for 3.0 won’t work in 2.2.1, for example:

Perfectly good 2.2.1 code:

    [startButton setFont:playFont];

Clean compiling 3.0 code:

    [[startButton titleLabel] setFont:playFont];

So we’re faced with a problem.  How do we write code that compiles cleanly in 3.0, while maintaining our ability to do clean 2.2.1 (I’m tired of the 2.x.y notation – just assume that I’m talking generically about version 2 of the SDK) builds?

When we first encountered this, I found several suggestions, most of which were wrong to one degree or another.  As nearly as I can tell, the method that I’m suggesting is more generally workable.

Restating the problem, we need to write our code so that it compiles cleanly, and works, with both a strictly 2.2.1 version of the SDK and with a 3.0 version.  We get extra bonus points if the code won’t need to be revised when the successor to 3.0 comes out.

Because of the requirement to continue to work with strict 2.2.1, we can’t rely on the preprocessor constant for 3.0 being defined.  There’s also an interesting issue between the simulator and the device that I’ll cover later.

Anyway, here’s what we came up with:

#ifndef __IPHONE_3_0
#define __IPHONE_3_0 30000
#endif
#if __IPHONE_OS_VERSION_MIN_REQUIRED >= __IPHONE_3_0
    [[startButton titleLabel] setFont:playFont];
#else
    [startButton setFont:playFont];
#endif

When I’m building against the 3.0 SDK, __IPHONE_3_0 is defined by Xcode, so my directives don’t interfere.  If all you wanted was the answer, you can stop here.  If you’d like more background on this issue, please continue reading.

First, a bit about where the pertinent preprocessor #defines are specified.  The file is Availability.h

For the simulator, the full pathname to Availability.h is:

    /Developer/Platforms/iphoneSimulator.platform/Developer/SDKs/  ↵
      …   iPhoneSimulator2.2.1.sdk/usr/include/Availability.h

For the device the path is:

    /Developer/Platforms/iphoneOS.platform/Developer/SDKs/  ↵
      …   iPhoneOS2.2.1.sdk/usr/include/Availability.h

In the version of Availability.h that goes along with 2.2.1, the following are defined:

#define __IPHONE_2_0 20000
#define __IPHONE_2_1 20100
#define __IPHONE_2_2 20200

Note that there is no __IPHONE_2_2_1

Now, here’s the tricky bit.  With Xcode, the mechanisms for communicating the version of the SDK that you’re using differ between builds for the simulator and builds for the device.  When compiling for the simulator, Xcode’s default configuration for a 2.2.1 build sets a flag as follows:

    -D__IPHONE_OS_VERSION_MIN_REQUIRED=20000

If you’re paying attention, you’ll notice that, when building for the simulator, targeting the 2.2.1 SDK, Xcode is setting the flag to 20000.

When building for the device, on the other hand, Xcode uses a completely different technique.  Instead of defining a version value for the preprocessor, the preprocessor substitutes:

    __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__

in place of:

    __IPHONE_OS_VERSION_MIN_REQUIRED.

Xcode (according to the comments in AvailabilityInternal.h) then has the compiler set:

    __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__

by using -miphoneos-version-min.  The actual compile directive when building for the 2.2.1 SDK is:

    -miphoneos-version-min=2.2.1

The implication of this is that, when you build for the simulator, the following code:

    NSLog(@"MIN VERS REQD: %d -- Current Version: %d",  ↵
      …   __IPHONE_OS_VERSION_MIN_REQUIRED,__IPHONE_2_2);

Causes this string to be output to the console:

    MIN VERS REQD: 20000 -- Current Version: 20200

The exact same code, running on the actual device, produces:

    MIN VERS REQD: 20201 -- Current Version: 20200

The reason I shared this in painful detail is to explain why some of the solutions that people are suggesting for this issue might not work in the general case.

Assuming that we’re building for the simulator as many of us do during development, the default Xcode configuration won’t let us find out whether we’re using any SDK later than 2.0.  For example, if we have code that goes something like:

// DO NOT DO THIS
#if __IPHONE_OS_VERSION_MIN_REQUIRED > __IPHONE_2_2
    [[startButton titleLabel] setFont:playFont];
#else
    [startButton setFont:playFont];
#endif

This code will work on the simulator because __IPHONE_OS_VERSION_MIN_REQUIRED will be 20000, which is not greater than 20200.  It will not work on the device, however, because 20201 is greater than 20200.  Remember that there is no official definition of _IPHONE_2_2_1.  Sigh…

Another approach that I considered was:

// THIS MIGHT WORK, BUT I DON’T RECOMMEND IT
#ifndef __IPHONE_3_0
    NSLog(@"THE 3.0 SDK IS NOT DEFINED");
#else
    NSLOG(@"THE 3.0 SDK IS DEFINED");
#endif

The problem here is that I’m not testing the value, I’m simply seeing if it’s defined.  If the variable ever gets defined in my code (perhaps due to a bit like what I’m proposing) or if the Xcode ever picks up a version of Availability.h that defines __IPHONE_3_0 when you’re building for 2.2.1 (I know that this shouldn’t happen, but better safe than sorry) the preproccesor will eliminate the wrong lines of code.  Remember that there are multiple versions of Availability.h kicking around on your system.  Check out the one at /usr/include/Availability.h sometime.

——–
Technorati Tags:  iPhone, iPod Touch, iPhone OS, Xcode,Apple, mobile

• I’ve loved the Palm devices since the first moment that I used them.
• My teams developed some of the earliest Palm/Mac conduits.
• A surprisingly large number of my career decisions and options since then have been a direct result of the people that I met, and the ideas that I was exposed to, in the early days of working with Palm.
• I still have one of my Palm Pilots in those special clear bodies hanging around, somewhere.
• I flew to New York and bought a Palm Vx because they were out of stock in local stores.  I was actually there for meetings, but that was the quickest way for me to get my greedy hands on one of the finest PDA’s ever designed.
• I still use that Palm Vx, because my life is locked into its To-Do list.
• I shouldn’t admit this, but I’m faster with Graffiti then I am with the soft keyboard on my iPod touch

My point is, that I’ve always rooted for Palm, even when I haven’t been able to rationalize buying their increasingly irrelevant devices.  When I started hearing about webOS and the new Pre, I was really hopeful that this could be “the Next One” from Palm.  I even applied to get access to their Software Development Kit (no word back from Palm on our application).  It seems like they are really building up momentum for their launch this week, but some strange bits have started filtering into the infostream.

For example, clearly they need the Pre to be a big hit coming out of the starting blocks, so you’d think that all efforts would be focused on getting people to purchase quickly.  Instead of that, the week before the launch, they let word get out that the Pre will be available on the vastly superior Verizon network in roughly six months.  Almost immediately, they’ve limited their early adopters to current Sprint users.  Why switch to Sprint, now, when you can get the device on Verizon (or maybe AT&T, if you’re so inclined) in 6-7 months?  Curious.

There’s another interesting bit that has some in the developer community scratching our collective heads.  At launch, most third party developers will be limited to web programming using CSS and javascript.  As I’ve made quite clear in an earlier post, I firmly believe that the availability of third party apps and an active developer community will be critical to the success of any modern mobile platform.  Apparently, “special partners” have access to the good stuff, but the rest of us riffraff are locked out, at least for the time being.  In light of the explosive success of the App Store, it seems that Apple has set the bar for a third-party app ecosystem pretty high.  It’s hard to see how the early experience with the Pre will even be close.  I don’t accept the arguments that reference the early days of the iPhone.  That was then.  What matters, now, is the competitive environment today.

Oh yeah, and then there’s the bit about syncing with iTunes.  In the absence of their own entertainment source, this seems like critical functionality for the Pre, so imagine my dismay when I read that this may be a hack job that Apple will stamp out pretty quickly.  From the outside, it’s impossible to know what’s really going on at Palm/Sprint.  This seems like desperate times for both, but stunts like this rarely work out well for anyone except publicity-starved startups.  (Update: 2009.07.15 – I guess that “all good things must come to an end.”)

I sincerely hope that the Pre is a runaway success for Palm.  I’d like nothing better than to have a full suite of BluMtnWerx apps running on the Pre and generating boatloads of revenue for us.  When it’s available on Verizon, I may buy one, but the latest revelations are certainly unsettling.

Let’s be very clear.  Apple has set the standard.  Palm/Sprint need to field a clearly superior offering.  We’ll see what happens on Saturday…

 
——–

Technorati Tags:  iPhone, iPod Touch, Apple, mobile, Sprint, Verizon, Palm Pre

If you ask a UIView for its “bounds,” you get back a rectangle, with an origin at (0,0) and a size set to the frame size of the view.  That’s exactly what I would expect.  Now, I know that relative position in a header file means absolutely nothing.  However, the very next property specified in the UIViewGeometry category defined for UIView is “center.”  Guess which coordinate space “center” is in.  Unfortunately, I guessed that it would be in the space of the receiver – WRONG.  It’s actually in the space of the superview.  I even checked the UIView Class Reference documentation.  Surely enough, “The center is specified within the coordinate system of its superview.”

I’ve been warned, from now on, I’m always going to refer back to Apple’s Developer Documentation.

Happy coding…

Technorati Tags:  iPhone, iPod Touch, Apple, mobile

IB lets me position my controls interactively, and it provides somewhat straightforward hooks for connecting my program to the new controls.  One of the big complaints that I noticed, and one that frustrated me a bit, at least at first, was that IB doesn’t provide full access to all of the settings on the controls that it specifies.  The specific example for me was setting the font for the Title text for the regular "Round Rect Button."  Support for this operation is clearly evident via the "setfont:" method specified in the class header file, but I couldn’t find any way to get at the method through the IB Attributes Inspector.

As suggested above, I’m pretty lazy, so I didn’t want to abandon IB just to change the font face and size, then a solution appeared.  I simply established an outlet to the specific button:

@interface ButtonTestViewController : UIViewController {
…
IBOutlet UIButton *theButton;
…

and wrote the following code:
…
UIFont *theFont = [UIFont boldSystemFontOfSize:30];
[theButton setFont:theFont];
CGSize tOff = CGSizeMake(2.0,2.0);
[theButton setTitleShadowOffset:tOff];
…

For what it’s worth, my situation was such that I was able to put the code to set the button in the viewDidLoad method.

One other thing to keep in mind when you’re loading your application from a nib, the ViewController’s initWithCoder is the initialization method that gets called.  Thanks to Jeff LaMarche for the explanation of initializers in his response to this question.

Unless you just love writing and maintaining UI code, I strongly urge you to take a careful look at IB.  I’ll continue to use it whenever I can.

Technorati Tags:  iPhone , iPod Touch , Apple , mobile