iOS needs a block-based UIAlertView. So many currently-delegate based interfaces would be better served by block callbacks.

I’ve wanted the same. I’ve also wanted to contribute more open source code. With some time on my hands, I threw together RooAlertView.

As I mention in the README, I’m not terribly happy with it. I like the public interface, a single class method. But am sad to report that the static analyzer doesn’t like the implementation. The static method alloc, init’s a RooAlertView and then relies on the UIAlertViewDelegate’s callback to be called and then releases itself. I’m fairly confident it works and all, but am hopeful someone will provide a better solution that the analyzer likes and that’s probably cleaner.

So to avoid having to manually update the date every time I release a new beta, I used gcc’s __DATE__ to come up with the following code:

    NSDate expirationDate = 
        [[NSDate dateWithNaturalLanguageString:
            [NSString stringWithCString:DATE]] 
            addTimeInterval:(60602430/30 days/)];

if( [expirationDate earlierDate:[NSDate date]] 
     == expirationDate )
{
    int result = NSRunAlertPanel(@"Beta Expired", 
                 @"This beta has expired, please visit "
                 "http://roobasoft.com/rooAppNumber2 to grab"
                 "the latest version.", 
                 @"Take Me There", @"Exit", nil);

    if( result == NSAlertDefaultReturn )
    {
        [[NSWorkspace sharedWorkspace] openURL:
                  [NSURL URLWithString:
                   @"http://roobasoft.com/rooAppNumber2"]];
    }
    [[NSApplication sharedApplication] terminate:self];
}

Make sure the file that contains this code is always compiled before you ship your beta. Otherwise the DATE referenced will be whenever the file containing it was compiled. This works for me because I keep a separate “production” sandbox where a clean build is run before handing anything out.

Want to get fancy? Use Hyper Alert to make the URL clickable or to pretty it up a bit. You could probably have it pull release notes for the current release from a pre-defined location (that’s an assumption – I haven’ tried this).

SetADateForAnAppToExpire on CocoaDev wiki has some more information. Enjoy!.

p.s. If for some reason you’re interested in participating in a private beta of “rooAppNumber2” without knowing anything about it, send a note to rooAppNumber2@roobasoft.com I’ll make sure you get notified on how to participate when it’s ready. rooAppNumber2 will require OS X 10.4.

1) update 6.7.06: there is no #1 – I just had this blatantly wrong – see comments. Thanks Jean-Francois.

<

p> Binding to a BOOL requires the result to be returned in an NSNumber. My isIndeterminate method, although backed by a simple BOOL, needed to be

- (NSNumber ) isIndeterminate
{
return [NSNumber numberWithBool:isIndeterminate];
}

- (void)setIsIndeteriminate:(NSNumber *)flag
{
[self willChangeValueForKey:@“isIndeteriminate”];
isIndeteriminate = [flag boolValue];
[self didChangeValueForKey:@“isIndeteriminate”];
}

Some other goodies:

• Accessorizer can create your accessor methods for you. This is a great tool that greatly speeds up a tedious task.

• Core Data can generate similar code for you. Go to your data model and right click on an entities attribute. You should see a “Copy Method Declarations to Clipboard” and a “Copy Method Implementations to Clipboard”. Core Data doesn’t need you to generate these. If you use the setValue:foo forKey:@“bar” syntax the correct things happen. However, it’s often nice to just say [obj setBar:foo];

[NSImage imageNamed:@“NSDefaultApplicationIcon”];

NO is defined as:

define NO (BOOL)0

we have an issue. 0 is also ‘nil’. Just below the definition of NO we see nil:

define nil 0 /* id of Nil instance */

Since ‘nil’ has to be a valid NSNumber *, you are allowed to pass NO as a NSNumber * parameter. If object ‘foo’ has a method ‘setBarOn’ with a declaration of

- (void) setBarOn:(NSNumber *)aBooleanAsANumber;
- (NSNumber *) barOn;

You need to make sure you never call that method with NO, as in:

[foo setBarOn:NO]; 

If you were to try to read the boolValue by hand you’d be OK. Calling ‘boolValue’ on a nil object seems to return 0, which is NO, so you wouldn’t notice the problem. The problem comes in when you use predicates.

I had a predicate that looked like:

“isBarOn == 0”

If you setBarOn:NO instead of setBarOn:[NSNumber numberWithBool:NO] the instance in question will not be returned by this predicate. Ouch. Fortunately if you were to look at the attribute that had been set to :NO you’ll see it reported as (null), which is a good hint your Boolean got set wrong.

I’m not sure how common this is or not, but it seemed worthy of pointing out. Hopefully it made some sense to someone.

The other funny thing about this is that if you try to use the name “isDeleted”, Xcode squawks up and makes it clear that “isDeleted” is a no no. See image of squawking:

I settled on “isProfileDeleted”. Redundant, but it works a heck of a lot better now (reads and writes!). Why the “name clash” code in Xcode isn’t catching “deleted” I don’t know.

I did some searching and couldn’t find a list of reserved words. If you know of one, please share.

- (id)propertyList

What does it do? To quote the docs:

Parses the receiver as a text representation of a property list, returning an NSString, NSData, NSArray, or NSDictionary object, according to the topmost element.

If you started staring at CFPropertyList(…) functions, just trying to figure out how to read a plist file, the ‘propertyList’ method of NSString is tums for your heart burn.

Also, I’m loving the developer doc’s new “hover over a method to see the short description” as pictured above. If you don’t see this, grab the March ADC Reference Library Update.

I want to add a progress bar to rooVid’s dock icon. This one progress bar would be the aggregate of all the running tasks. How does one add a progress bar to their dock icon? I don’t know, but I’ve known for a couple months that I wanted to do it. My best lead was Chad Weider‘s CTBadge. The plan was to look at Chad’s sources and learn how to draw a progress bar. Well, today I found a solution that should be quite easy to implement (I’ve already created a proof of concept app in almost no time). The solution is Uli Kusterer‘s UKDockProgressIndicator. The funny, it’s a small world, thing here is that Uli Kusterer commented on my Sparkle post over a month ago. But that’s not how I stumbled into UKDockProgressIndicator. I stumbled into it via:

• Andy Matuschak posts about Sparkle Beta 2 and NNW picks it up
• In the comments of that post, Andy mentions Uli’s app called Shovel, and how it might be gaining support for Sparkle’d applications soon. However, Andy does not provide a link to shovel.
• Google “Shovel OS X”
• Find link to Uli’s site via Softpedia
• Poke around on Uli’s site a bit and bump into a blog entry about UKDockProgressIndicator

This wandering into solutions happens enough that it’s one the first things I do when I can’t figure out how to tackle a problem. To many, that’ll sound like procrastination, and, well, it is. But nonetheless, it’s effective. Can’t argue with the results.

update: As I was driving to work I felt I needed to update this entry with this addition. Here goes: As a religious man, I’d be stupid to think that all this “stumbling” was really just random luck. Yet, going into any detail on my religious beliefs is not the focus of this blog. So we’ll just leave it at this: Yes, some of it may just be random stumbling (if you look around enough, you’re bound to find an answer to something), however it’s important for me to acknowledge that (according to me) there is something greater going on and I need to remember that and give thanks. There, I feel a little better now.

rooVid’s appcast: http://roobasoft.com/rooVid/appcast.xml

    self = [super initWithWindowNibName:@"NibNameHere"];

and then I call showWindow on my now init’d controller object. All pretty straight forward. Problem is that the dang “window” assigned to files owner wasn’t showing up. Well, to make a painful story short, the problem was that I stupidly wrote a ‘window’ method myself which overrode NSWindowController’s window method and understandably confused/broke things. Not sure what I was thinking, probably something like “oh, I need that ‘window’ reference elsewhere, I must need a – (NSPanel *) window, let me just create that now”. Nuked the – window and all was better in the world. It’s been a tough 24 hours.

The lesson learned? If you’re panel or window isn’t showing up when you run initWithWindowNibName / showWindow, make sure you haven’t overloaded any of your base class implementations with a wrong one of your own. Although, 90% of the time it probably just means you didn’t set ‘window’ for your Files Owner in IB.