Archive for category Cocoa
WWDC Attendee Guide
Last year was my first time attending WWDC and I can easily say that it was one of the most enjoyable weeks of my life. My geek squee didn’t shut off from the moment I left SYR until about 3 months after I returned.
I’ve been meaning to put together an attendee guide since I got back, so I figured what better time than two days before I leave for WWDC again this year.
- Pack jeans, t-shirts, and hoodies/sweatshirts/long sleeve shirts. San Francisco is not warm. It was typically between 50º and 65º the entire week last year.
- Stand in line for the keynote. I had a great time standing in line with people I had only known online and who have become good friends.
- Meet people. Many of us geeks are shy and that’s OK, but do yourself a favor and try to break out of your comfort zone and say hi to someone you don’t know. Easy conversation starters include, “Where are you from?”, “What have you worked on?”, and “Wanna see my Steve Jobs tattoo?”
- Find a group to hang out with. I had a really great group of folks that I stuck with for most of the conference last year and it made it a much more enjoyable experience. Go to parties with them, sit with them in sessions, but don’t be exclusive. Remember to say hi to other folks too.
- Go to the sessions. Plan ahead of time by looking at the session list and see which ones interest you and try to hit all of them. There is some amazing information presented in these sessions so soak it all up. The videos that are made available after the fact are great, but only cover about 50% of what you will get by actually sitting through it.
- When you sit down in each session plug your laptop into a power strip and plug your iPhone into your laptop. Yes, even if it doesn’t need it. With the amount of tweeting and texting you will be doing you will be testing the limits of your iPhone battery every single day. NEVER waste an opportunity to charge it.
- Stay hydrated. Drink lots of lots of water to help keep your energy up. If you do this one simple thing you will not tire out the entire week.
- Charge your laptop and iPhone over night every night. It gives you a good jump on the day.
- Use the labs. The labs are basically free DTS incidents where you get to sit face-to-face with the Apple engineers that wrote the code that you are using to create amazing things. Ask them to help you work out an issue that you’ve hit. If you haven’t already done so, start a list of WWDC Lab Questions so that you’re prepared. If you aren’t working on anything or don’t have questions of your own, see if a friend (or a new friend) would mind if you tag along to their lab session. You will learn something.
- Eat the free lunch. I had heard horror stories about the lunches at WWDC, but to be perfectly honest they were pretty good. Sit with folks you don’t know, strike up a conversation, and enjoy the free food. Even if you think the meal sucks, chances are the conversation won’t.
- Go to the bars and go to the parties. Do not go back to your hotel room for more than 15 minutes after the conference ends for the day. Get changed (if needed), take a few minutes to stretch out on the bed and relax, then get your sneakers on and get back out the door. (see #3 above). Even if you are not normally a barfly or even if you don’t drink at all, get out there with a Pepsi in your hand and talk to people.
- Do not get hammered every night. Enjoy the company with a drink or two, but don’t get blitzed. You want to be on your game for the full day of sessions the next day and you don’t want to waste a day puking and avoiding solid foods.
- Use Twitter. Do a standing search for the #wwdc hashtag and get to the good parties and bars.
- Nervous about talking to some of the rockstars in the Mac and iPhone programming world? Buy them a drink and don’t be shy about it. I have yet to see anyone decline free booze at WWDC.
- Bring and handout business cards. Or anything that has your name and info on it. Something that helps me remember who you are. Yes, say what you want about handing out pieces of dead trees and I will no doubt agree with you, but to be perfectly honest the only people that I really remember from WWDC last year are the people with whom I exchanged business cards. When you get back to your hotel for the evening make a note on the cards you received to help you remember something about the person.
- Email the people that you met when you arrive back home. When I got back to SYR I sent out a mass email to everyone whose email address I had acquired just to say “hi” and tell them that I had a great time meeting them. I’ve also emailed this same group a few times during the year just to drop them a line and let them know what I’m working on. It’s a good way to keep in touch.
This is by no means an exhaustive list, but these are the things that really stick out to me from last year. Enjoy and I hope to see you there!
365Cocoa – Day 12: Custom drawing
As I have neglected to post the second in my series on Cocoa drawing I’d like to point you to 365Cocoa for their next few posts starting with the one linked below. It sounds like they are going to go down the path I intended (and will probably do it better than I could have). Enjoy!
Custom Drawing Using drawRect, Part 1
Posted by Michael in Cocoa, Design, Sample Code on December 18, 2009
One of the more advanced techniques for creating custom user interfaces on the Mac is the use of NSView’s drawRect method. Many answers to questions on StackOverflow and Apple’s mailing lists include recommendations to “just override drawRect and do the drawing yourself”. Some folks see this recommendation and their eyes glaze over, thinking that it’s too advanced of a technique for them to wrap their heads around. Over the next few days I’m going to go over some basic techniques that can yield powerful results.
Let’s start by setting up the Xcode project that will be the basis of the rest of these posts.
- Open Xcode and create a new Cocoa Application project called DrawingSample.
- Create a new NSView subclass called CustomDrawingView.
- Open MainMenu.xib, add a new Custom View to the Main Window, set its class to be CustomDrawingView, and set it’s autosizing flags as seen here:
Save and Quit Interface Builder and switch back to Xcode. Open CustomDrawingView.m, it should look like so:
@implementation CustomDrawingView - (id)initWithFrame:(NSRect)frame { self = [super initWithFrame:frame]; if (self) { // Initialization code here. } return self; } - (void)drawRect:(NSRect)dirtyRect { // Drawing code here. } @end
We’re going to start (and finish) today with just a simple concept and some basic drawing that will set the stage for the future posts. All drawing in Cocoa is done by first setting up the environment in which you want to draw, and then doing the actual drawing. For instance, if we want to draw a blue box, we first have to setup the color blue, define the bounds of the box, and then draw it. In this case we are using the NSRect that is passed to the drawRect method as the box we want to draw, and we setup the color blue by calling [[NSColor blueColor] set]. We then use the convenience method NSRectFill to fill the dirtyRect with the color blue. Notice that we didn’t pass the color to NSRectFill, we set it, and from then on anything we draw will be blue until we change the color.
You can think of drawing in Cocoa much the same way as you would think of painting with a brush. You dip your brush in a certain paint color, paint the shape you want to paint, and then dip your brush in a new color and paint some more.
- (void)drawRect:(NSRect)dirtyRect { [[NSColor blueColor] set]; NSRectFill(dirtyRect); }
The preceding code, when run, will generate a view that looks like this:
Now, this may not look like much, but in future posts we will build on these concepts and, hopefully, by the end have drawn some pretty cool and useful things.
Bottom Bars in Interface Builder
Dave posts a handy tip for those that may not know that there’s a non-code way of setting up the bottom bars on your windows. Check it out here: Bottom Bars in Interface Builder – Dave Dribin’s Blog.
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
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.