Mischievous Ramblings II

Thoughts on the Apple Watch after less than 24 hours

 1) it's a little strange to be wearing a watch again.

 2) the apps screen gets full really really fast

 3) I want to write complications for it.  Complications are the elements that can be configured in watch faces.  A quick google search has not turned up any information on creating them.

 4) It was obvious that the watch was going to be a relatively simple i/o device attached to my phone. Brief experience bears that out -- with the exception of the watch face and complications (some of which DO depend upon the iPhone -- Weather, for instance) -- it's a new interface into existing apps on your iPhone.

As such, it creates a new category of interactions which used to be folded into your phone -- extremely brief ones for which you might have carried your phone in your hand (e.g., moving to the next song or changing the volume on your music -- exactly what buttons on your headphones or cable were intended to do) -- like incessantly checking the time, or a countdown timer you have in place.

So I'm not quite sure that I like the idea of games on the watch.  If you are sufficiently engaged in something to interact with it constantly, why not use your phone, which has a bigger screen and better UX?  The only game type I can see working on the watch is something where you make a very simple decision every few minutes or so.  Definitely NOT highly interactive systems.

5) Oddly, the watch is more intrusive than the phone for interacting, because it absolutely requires two hands.  There are a lot of things I can do on the iPhone with a single hand (the previously mentioned music manipulations, simple short texts or typing with one thumb, swiping, etc.) but I have to have my phone out and in one hand to do it.  The watch, which doesn't need to be taken out or put away, must be manipulated with the opposite hand.  It sounds small but it it weighing heavily right now -- partly because in each case the primary use hand is my right hand.  If i'm holding the phone to do one handed manipulations, it's in the right hand.  If I'm manipulating the watch in any way other than just flipping my wrist to the see currently displayed glance or app, I'm doing it with the right hand.  I assume that lefties will act correspondingly using the left hand.

Anyway, those are the first thoughts.  More later, I imagine.

 

Cross Posted to Group News Blog

My Top 3 iPhone Programming Books

I learn by reading a lot of books, and working my way through several of them. I've got a bookshelf three feet wide completely full of iPhone development books, and I thought I'd put my top three up here.

1) Programming in Objective-C 2.0 by Stephen Kochan (Amazon Canada Link, Amazon US Link)  is the best book on Objective-C there is. If you are a language geek, or want to know as much as you can about Objective-C, this is the place to start.

2) Beginning iPhone 3 Development: Exploring the iPhone SDK by Jeff LaMarche and David Mark (Amazon Canada Link, Amazon US Link) is one of many books doing a survey of basic iPhone functionality and how you program it. I like it a lot. I worked through about 75% of the book and found it very enlightening as I was starting out.

3) The iPhone Developers Cookbook: Building Applications with iPhone 3.0 SDK by Erica Sadun (Amazon Canada Link, Amazon US Link) is a great reference resource as long as you get the second edition. Like most Cookbook titles it has wide ranging "recipes" that give you a good idea of where you're going. I use it as a reference and for occasional reading because the topics tend to be short and easily managed.

Is there an app for that?

(h/t to Daring Fireball)

Objective-C: to dot, or not to dot, part deux

I've previously commented on the question of Objective-C dot notation.  After some additional thought and programming, I've got more commentary.

Assuming that all these lines occur inside a class implementation, consider the following assignments:

1) self.foo = somethingOrOther;

vs.

2) foo = somethingOrOther;

vs.

3) [self setFoo:somethingOrOther];

All are similar and would appear to be interchangeable.  But they're not.  And how they are not depends upon declarations elsewhere.  If foo has been declared (retain) in the interface declaration, 1) and 3) are distinctly different from 2).

The difference is that 1) & 3) may (depending upon the @property declaration in the @interface) retain or copy somethingOrOther while 2) will not.  IMO, this is a much bigger deal than whether 1) self.foo hides the explicit function call of 3) [self setFoo:...].

I digress...

Whenever we program with code written by others we are dependent upon the "kindness of strangers" -- we depend upon those other coders (often far away in time and in space) to behave according to some set of standards.  Despite years of wrangling over the minutiae of where braces go and whether tab characters are superior to space characters, what those standards are is largely less important than whether they are followed.  A mediocre standard followed religiously is better than a perfect standard used sporadically.  Standard ways of doing things mold your mental expectations, and you will see non-standard code as though it were standard code, opening the door to bugs which are difficult to find even though they are obvious.

Back to the three assignments...

Whether you believe in dot notation or not, all three of these things are basically similar, used for basically the same function (assignment to an ivar or instance variable), and they appear basically interchangeable.  The fact that they are not interchangeable is the same kind of problem as a poorly followed standard.

In a bunch of code, it's easy to see:

self.foo = someObject;

and

foo = someObject;

and

[self setFoo:someObject];

as the same thing.  One day you might sit down at the computer and be tired of writing 'self' and start using 2) instead of 1).  You should avoid this temptation.  It can lead to frustration if you don't remember that 1) & 3) use the property setter function and 2) does not.  And if you do remember that, and you take advantage of it, you face the risk that someone else will not (and that someone may be you in six months, or six days, or even six hours).

As I said, IMO this is a much bigger problem than the question of whether 1) or 3) is superior.

I recommend an iron-clad standard that you use one (and only one) of these constructs.  I don't care which one*. Or do not use the automatic generation of getters & setters (@property & @synthesize).

Just my toonie.

* I do note that using 2) means extra code everywhere you want to retain an object.  This has the advantage of explicitness -- you see the code when it is being used.  And the disadvantage of clutter -- there's extra "boilerplate" code around every assignment using retain -- which makes it harder to perceive the overall flow of the code.

XCode Error: dsymutil failed with exit code 10

I have been struggling for a while with what appears to be a systemic problem using XCode. Periodically, my projects will begin to display an error:
        ‘Command /Developer/usr/bin/dsymutil failed with exit code 10’
Once the error appears, it can sometimes be eliminated by some combination of:

• doing a clean build
• restarting XCode
• rebooting the computer
• reinstalling the developer tools

Sometimes, of course, it can’t be eliminated. As documented here and here, I found a workaround. But the problem recurs. Sometimes very quickly after implementing the workaround (which isn’t a real quick fix).

At the moment, I’m trying a full command-line uninstall of all developer tools to be followed by a re-install. Perhaps that will help. In the meantime, if anyone out there knows what’s going on here, I’d love to hear the cause and a solution.

The agony of agvtool, the ecstasy of XCode

OK, "agony" is a bit strong.

agvtool is Apple's generic versioning tool.  It can be used with XCode to automatically update build numbers and marketing version numbers within xcode projects.  It works well, except for the fact that it modifies your xcodeproj file.  If you're in XCode when you run agvtool, it asks you to reload your project file from disk.  It works, but it's annoying.  Especially when you hit command-R to run and then have to stop your executable because you need to reload your project file.

Turns out that you can get around this with a little bit of code.  Your build number is stored as XML under the key CFBundleVersion, while your marketing version is stored as XML under the key CFBundleShortVersionString.  Both are stored in the project info.plist file that XCode creates for you when you start a project (at least an iPhone project).  Because the info.plist file isn't part of the xcodeproj file, it doesn't require a reload when you modify it during a build sequence.

I wrote a little app that reads in the info.plist file (provided as a command-line argument), increments the CFBundleVersion, and writes the info.plist file back out.  Here's the code:

#import <Foundation/Foundation.h>

#define kCFBundleVersionKey @"CFBundleVersion"

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    NSString *filename = [[NSString alloc] initWithFormat:@"%s", argv[1]];
    NSDictionary *infoDictionary = [NSDictionary dictionaryWithContentsOfFile:filename];
    NSMutableDictionary *newDictionary = [infoDictionary mutableCopyWithZone:NULL];

    int cfBundleVersion = [(NSNumber *) [newDictionary valueForKey:kCFBundleVersionKey] intValue];
    ++cfBundleVersion;
    NSLog(@"new CFBundleVersion:%d", cfBundleVersion);
    [newDictionary setValue:[NSNumber numberWithInt:cfBundleVersion] forKey:kCFBundleVersionKey];

    [newDictionary writeToFile:filename atomically:YES];

    [pool drain];
    return 0;
}


Once you have this code compiled and put somewhere convenient (I used /usr/local/bin), you just add a new build phase to your target.  I used New Run Script Build Phase, and the script was just:

/usr/local/bin/versiontool Info.plist

Because I named my tool 'versiontool' and my info.plist file is named 'Info.plist' (duh).  YMMV.  If you have more than one plist file (like one for your full version and one for your lite version), just put two lines in the script and update them both.

Someday I may update this so it's smart enough to look for *.plist in the current directory, but for right now it's crude but effective.  Hope it helps someone out there.

Oh, and I plan to keep using agvtool for updating the marketing-version (1.01, etc.) manually.

Objective-C: to dot, or not to dot

There has been some discussion in the online Objective-C community about the propriety of using "dot notation" to access properties instead of getter/setter methods.  For those of you not up on the lingo and the language, Objective-C 1.0 had you use getter & setter methods to access object instance variables, so:

int foo = [someObject getFoo];
[someObject setFoo:newFooValue];

Objective-C 2.0 added properties, which are syntactic sugar in the compiler so that you can access these same getter/setter functions automatically by using the so-called "dot notation" which is commonly used in c and c++ to access members of structs (and therefore also members of classes, which are merely a special kind of struct). Like this:

int foo = someObject.foo
someObject.foo = newFooValue;

Clearly this newer syntax requires fewer square brackets and is more familiar to c/c++/c# programmers, but it also hides potential complexity. Is the code really just a memory access to a publicly available data member of the instance? Or is it a hidden method call of unknown complexity, possibly creating and tearing down multiple network connections in order to expend countless CPU cycles calculating an intermediate value?

The online discussion has been pretty civil as such things go.  Here's what I think: the dot notation is less annoying to read than the bracket notation.  That reflects my extensive background in c and c++ programming more than anything else.  Over time, as I do more and more Objective-C programming, I'll find the brackets less painful and will use them more often.

The concern about hidden complexity has a certain initial appeal: OMG! That variable access could be a network connection! Yeah, it could.  But in c++, the simple statement:

a = b + c

could be just as bad, because the '+' operator might be overloaded to do God knows what!

And it is always possible that you might assume a simple getter routine is just a getter routine even in bracket notation, only to discover that it, well, you know...

It's important to keep a little perspective here.  The person writing that code might have been an idiot.  That's always true, even when you're reading your own code.  But it might be a good idea to start out with the idea that they were reasonably smart and trying to do a reasonably good job.

And when that idea doesn't pan out, yeah, check to make sure that the getter and setter aren't accessing some server in Chelyabinsk every time you access a variable using dot notation :-).

update 20091009: I was working on an assignment for my iPhone Application Development class, and this came up.  Any construct that lets you write the following code must be considered eeevil:

CGPoint drawAt = CGPointMake((320 - [drawImage size].width)/2, (240 - drawImage.size.height)/2);

Compare the yellow highlighted code with the turquoise highlighted code: they are essentially the same, but I definitely prefer the turquoise, no matter how much detail is hidden in the [drawImage size] construct.  Ouch.

Alea Iacta Est, finale

Sorry for the delay in reporting...

On 2 September, I received an email containing the following:

We've reviewed Hero Roller and determined that we cannot post this version of your iPhone application to the App Store at this time because of inappropriate 'Keywords' used to identify your application.  We will not post applications that reference other applications in their search criteria. It would be appropriate to remove Dice Roller

But I cannot submit a new version because of an error.  Fortunately, on 16 September, Hero Roller was approved for sale!

So both the Lite and full versions of Hero Roller are now available on the App Store!  They are very specialized programs and I don't expect tremendous response, but I'll get around to posting some details to Hero forums wherever I can find them.

Hero Roller Lite

Hero Roller Full

Hero Roller FAQ

Alea Iacta Est, part 4

After an unscheduled delay for laptop repair (about which more later), Hero Roller full version has been resubmitted.  Hopefully it will be approved upon review and we can get this show on the road.

This is why I wanted to do a full submission process with a simple program before I contracted with anyone else.  To understand the entire process end to end.

Alea Iacta Est, part 3

I received a phone call (!) today from Apple asking for a tiny change in the application description for Hero Roller.  As of about 4:40 pm today, Hero Roller Lite was approved for sale, but Hero Roller has been Rejected.  I've asked for a clarification (since the requested change was already made), and hopefully this means that both apps will be available for sale in short order.

For now, I'm holding Hero Roller Lite off the App Store until Hero Roller is ready.