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.

From the uncrustify website:

The goals of this project are simple: Create a highly configurable, easily modifiable source code beautifier.

Since Tony had provided nice Automator actions, I figured I’d take it for a spin. After a quick

brew install uncrustify

and a few minutes messing with Tony’s sample .uncrustify.cfg making my own, I was impressed.

While in Xcode 4 I used Tony’s Automator service to uncrustify the selected text (I select whole files at a time). However, I had to give up on Xcode 4 due to stability issues so found myself back in Xcode 3.2.x. While in Xcode 3 I decided to create a User Script for uncrustify, thinking it would be much faster to execute. So now I have a shell script execute uncrustify on the selection and replace the selection with the uncrustified result (stealing the uncrustify line from Tony’s Automator service). I also have this bound to cmd+option+ctrl+u.

#!/bin/sh
/usr/local/bin/uncrustify -l OC -q

Here’s the User Script setup:

Liar! Note that it says I’m using ‘g’ as the shortcut instead of ‘u’ like I said. I’m pushing the ‘u’ key but it’s bound to ‘g’ in the Dvorak keyboard layout.

I’m not sure if I’m early or late to the uncrustify party, but I’m happy to be here.

Oh, and if someone does know how to setup User Scripts in Xcode 4, do tell!

Wait, one more thing! I’m working on a project where my 6 lines of whitespace after each function body wasn’t appreciated (understandable, it’s not for everyone ). rooSwitch to the rescue! I already have profiles for slight differences in Xcode prefs, so I dropped my .uncrustify.cfg on each profile and am now switching that file with the slight difference for this project. Success.

GoogleAuth.setup_captcha("some@email.com")

After that runs, the next time I try ClientLogin with that email address it’s almost guaranteed that the CAPTCHA requirement will happen.

The script is available at http://gist.github.com/11820

As you can see, the script just hammers away trying to log into the given account until Google returns with the CaptchaRequired response.

No this isn’t nice or pretty. Ideally Google would let us pass a parameter that would force the CAPTCHA requirement to happen. Until then, this works.

gwd()
{
  $*
  growlnotify "${1} is done" -m '...'
}


Drop that in your .bashrc or .bash_profile and you can now do things like:

gwd sleep 1
gwd some time consuming command

Assumptions: * You have growl and the command line growlnotify installed * You use bash

Update: The friend I was talking with didn’t have growlnotify installed. His google search for ‘growlnotify install’ turned up this, much more complete solution: http://www.simplicidade.org/notes/archives/2007/08/tip_use_growlno.html.

Update: The traineo guys provided an API and I updated the widget. See: TraineoWeight.wdgt Updated

Like most Americans I’d prefer to be less fat. To help me with that goal I’ve been logging my weight on traineo.com. They offer plenty more than just weight tracking, but I haven’t gotten into all that quite yet. Anyway, it seemed silly to log into a web page just to enter my weight each day (who has the time for that! </lazy>). So I pinged the traineo folks and got this in reply:

I’m afraid that at the moment we don’t have an open API, although we are planning to release one in the not-too-distant future.

<snip>

If you want to input your weight remotely, this is possible, but not something we actively advertise, as it’s currently not really ready for public consumption.

If you were to visit http://they.made.it.sound/like/i/shouldnt/share while logged in (i.e. you have a cookie saved in your browser (they don’t go stale for a long time)), your weight would be submitted.

To which I said (to myself): “C Is for cookie, that’s good enough for me!”.

When I found myself awake at 3am[1]. I knew just what to do:

1) Fire up Dashcode
2) Author a widget based on a template Apple provided[2] using 1997 methods of screen scraping[3].
3) Publish widget with minimal testing
4) Hope traineo doesn’t change their response HTML

This took ~3 hours of my time[4] and surely has bugs and will surely break when traineo changes their response. I provide this “as is”. With that:

Enjoy! TraineoWeight.wdgt.zip Make sure you log into your traineo account with Safari first.

[1] our 3 year old likes to wake me up and make me tuck her back in (it’s not that bad really – I’m sure I’ll miss it when it stops).
[2] I can’t make pretty things. But I can copy pretty things!
[3] .substring() – I fought the DOM parser for too long and finally reverted to .substring(). Yes, this is a hack and this widget *will* break someday…possibly soon.
[4] I would have never tried this without Dashcode. It’s pretty slick. Two thumbs up.
[5] Wait…there wasn’t a [5]. Well, if you want access to the Dashcode project let me know and I’ll put up an svn repo. Feel free to take the widget and do with it what you will.

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.