iLife 09 Won't Install When the iPhone Simulator Is Running
Posted by Michael in Uncategorized on October 20, 2009
This post is a bit of a deviation from my usual posts, but it falls into the something-that-bit-me-that-might-bite-you-too-so-here’s-how-to-fix-it category.
I recently upgraded to Snow Leopard by doing an erase and install. After getting everything back up and running I realized that I still needed to install iLife. I popped in disc 2 of my MacBook Pro install DVDs and proceeded to open the Install Bundled Software installer. After customizing my options I hit the install button and waited. And waited. And waited. The installer never got past the Preparing Bundled Applications stage.
I checked out the console and saw a series of messages that ended with:
10/17/09 4:23:10 PM Installer[8135] *** -[NSMachPort handlePortMessage:]: dropping incoming DO message because the connection or ports are invalid
I decided to try a restart to see if that would fix my problem but shortly after restarting and before I could try my install again I cranked open Xcode and the iPhone simulator to check out something in my latest project. Remember this part of the story, because it’s important.
A few days later I remembered that I still needed to install iLife and grabbed my MacBook Pro installation discs again. I kicked off the installation and instantly hit the same issue. The installer never got past the Preparing Application Bundles stage. I opened Console.app again and saw the same message:
10/20/09 7:39:40 PM Installer[9025] *** -[NSMachPort handlePortMessage:]: dropping incoming DO message because the connection or ports are invalid
I decided to turn to Google and happily came across this gem of a radar filing: Installer hanging for any installer after uptime of X hours. If you read through the comments on that bug you will find that the installer hang isn’t based on uptime, but rather on the iPhone Simulator running. I had been working on an iPhone project both times I tried to install iLife and it was causing the installer to hang (for some inexplicable reason).
I quit the simulator and Installer.app immediately stopped trying to prepare the bundled applications and displayed an error. I quit the installer, tried again, and voila, everything worked as it should.
Core Data Code Generation
Bill Dudney has a great post about using categories to avoid some of the work when generating and regenerating classes from your Core Data model. Read about it on his blog, PrEV, here: Core Data Code Generation.
Your New Friends: Obj-C Associated Objects
Posted by Michael in Cocoa, Link, Sample Code on August 28, 2009
Andy Matuschak has posted a little-known feature of the Objective-C API under Snow Leopard on his blog. I can’t think of a use for associated objects at the moment, but there’s a good chance that I will need them in the future. You can read about them at his blog: Square Signals : Your New Friends: Obj-C Associated Objects.
UIView Manipulation Made Easier with a Category
Posted by Michael in Cocoa, Sample Code on July 27, 2009
I was watching a presentation recently where the presenter showed the header for a category that he had added to UIView to make his life a little easier. The point of the talk did not center around the category so I never saw much more than the header, but that was all I needed to recreate it for my use. Here’s the header:
#import <uikit/UIKit.h> @interface UIView (MFAdditions) - (id) initWithParent:(UIView *)parent; + (id) viewWithParent:(UIView *)parent; // Position of the top-left corner in superview's coordinates @property CGPoint position; @property CGFloat x; @property CGFloat y; // Setting size keeps the position (top-left corner) constant @property CGSize size; @property CGFloat width; @property CGFloat height; @end
As you can see there isn’t a whole lot to this category, but if you’re doing a lot of view manipulation the benefits of it will rapidly become clear. There was one sticky wicket that I hit when implementing this class and it centers around this method:
+ (id) viewWithParent:(UIView *)parent;
When I first implemented this method I wrote it like so:
+ (id) viewWithParent:(UIView *)parent { return [[[UIView alloc] initWithParent:parent] autorelease]; }
This was all well and good as long as the only class that I was creating was a UIView, but I ran into trouble when I started creating UIImageViews. Instantiating new UIImageViews worked fine, but as soon as I called a UIImageView-specific method the app would crash:
*** -[UIView setImage:]: unrecognized selector sent to instance 0xd1b350
I struggled with the answer to this one for a while and it wasn’t until I presented my problem to the local CocoaHeads group did I get it all figured out. Here’s the correct way to write this method:
+ (id) viewWithParent:(UIView *)parent { return [[[self alloc] initWithParent:parent] autorelease]; }
By calling self instead of strongly typing the returned object as a UIView the class would dynamically determine the correct type at runtime.
You can download this category here: UIViewAdditions
Standard iPhone Element Sizes
Great quick reference for Standard iPhone Element Sizes at Jonathan George‘s site.
iPhone Development: Updating Project Hint
Jeff posts a great hint that answers some problems that folks were having with one of my older posts, Finding Memory Leaks With The LLVM/Clang Static Analyzer
Check out Jeff’s post here: iPhone Development: Updating Project Hint.
Quick and Easy Drawing Performance Debugging with NSShowAllDrawing
While watching one of the WWDC09 session videos I was informed of a great tip that I had been previously unknown to me: Pass -NSShowAllDrawing YES as an argument to your application in Xcode to see a visual representation of the drawing that your application performs as it runs.
To illustrate how NSShowAllDrawing works and the issues it can help you correct I’ve put together two videos. The first shows my app, Bezipped, in its current 1.0 state and its current drawing behavior.
This second video shows how I improved the drawing in Bezipped simply by setting the top-level container to be backed by a Core Animation layer:
I highly recommend giving your app a spin with NSShowAllDrawing if you haven’t already, it was certainly a real eye-opener for me. There are some additional resources for debugging your drawing performance on OS X (as pointed out to me by André Pang) provided by Apple here: Drawing Performance Guidelines: Measuring Drawing Performance
Lastly, both Alan Rogers and Steve Streza pointed me towards Quartz Debug.app (included with the developer tools) as another means to see similar redrawing behavior. I found Quartz Debug’s options to be a bit heavy-handed as the drawing performance of the entire OS was shown instead of just my app, but your mileage may vary.
The Best Interface Builder Layout Ever
This morning I posted a screenshot of my Interface Builder layout on Twitter. I didn’t think much of it at the time, but I received enough positive feedback on it that I decided to post it here for generations of future Cocoa developers to find. The layout gets harder to work with the smaller your screen gets, but it works very well on my 24″ display. Another tip for working well with IB: keep it in it’s own space and don’t let other apps invade that space. I find that when I can concentrate just on my IB windows without having to mentally block out background windows it makes my workflow much smoother.
ParseKit
While I don’t have an immediate need for ParseKit, I’m fairly certain that it’s going to come in very handy in the future. Written by Todd Ditchendorf, the framework offers:
- String Tokenization via the Objective-C PKTokenizer and PKToken classes.
- Language Parsing via Objective-C – An Objective-C parser-building API (the PKParserclass and sublcasses).
- Parser Generation via Grammars – Generate an Objective-C parser for your custom language using a high-level grammar syntax (similar to yacc or ANTLR). While parsing, the parser will provide callbacks to your Objective-C code..
Head on over to the ParseKit website to download it.
Well That Didn't Take Long
As you can see we are now flying under a new banner: Core Fruition! In less than two hours from my last post I had the answer to my naming quandary from Paul Goracke, and I can’t thank him enough.
When I saw Paul’s suggestion my first thought was, “That’s an awesome name!”. My second thought was, “That sounds really close to another popular Cocoa site…” Not wanting to step on any toes, I decided to throw the name into some focus testing, asking a bunch of high ranking folks for their gut reaction. Here are the results:
Mickey Roberson: “That’s not bad“
Bill Dudney: “Frution is too ‘hard to read’, but not gut reaction is I like it … cool name“
Danny Greg: “rip off of core intuition, other then that – nice“
Jeff LaMarche: “I like it.“
Dave Verwer: “I like Core Fruition“
Brent Watson: “I like it“
Marcus Zarra: “I like it. Makes me think of learning cocoa“
As you can see, most folks liked it with only Danny giving me the reaction I was afraid of, which wasn’t enough to keep me from pulling the trigger. I’d like to thank everyone for submitting names and cool ideas, and especially Paul for hooking me up with a winner. Now, if some intrepid graphic designer would like to hook me up with a sweet logo…