Silly new app has been submitted to Apple’s App Store for review. I’ll tell you about it in a few days.
I’m going to jump right into this contentious issue. There has been a lot written about using dot notation in Objective-C. Before we get into the arguments, let me first show you something from some actual code I’m working on right now:
“Normal” bracket notation Objective-C:
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sort]];
Dot notation Objective-C 2.0:
fetchRequest.sortDescriptors = @[sort];
Alright, so I used some literals in there as well. But that’s really part of my point. The language evolves over time and just because something has “always been done this way” doesn’t mean it’s necessarily the best way to do it.
The dot notation line is almost half as long and, to my mind, much easier to read. Having been typing Objective-C for a few years now I can tell you that brackets are tough to manage. Xcode seems to get its “bracket helping” wrong almost half the time. And they are just visually cluttery.
Some say “OK, use dots but just for properties!” Me, I’m getting used to using the dots for everything except (void) methods with no arguments.
Everything else is up for grabs. I guess because I think of everything as a property and/or object to grab. For instance if I use:
I immediately think “OK, we’re peeling off a blackColor from the UIColor class.”
Here’s a more involved example. I have a “SensorManager” class that is a singleton. This class basically wraps up the functionality and behavior of the location manager and the motion manager. Here’s some actual code from the app I’m working on:
SensorSample *newSample = SensorSample.new; sensorSample.latitude = @(SensorManager.sharedInstance.locationManager.location.coordinate.latitude);
This may make you cringe or it may make you go “ah-ha!”
When I look at it, I think to myself, “OK, we’ve got a new sample that we’re peeling off of the SensorSample class. We’re setting it’s latitude to a boxed up NSNumber that we get from the Sensor Manager’s shared instance’s location manager’s location’s latitude coordinate.
The other way to write this is:
SensorSample *newSample = [[SensorSample alloc] init]; [sensorSample setLatitude:[NSNumber numberWithFloat:[[[[SensorManager sharedInstance] locationManager] location] coordinate].longitude]];
ARE YOU FUCKING KIDDING ME?!?!? I couldn’t even type that second line without Xcode fucking up the brackets. Only it works fine IF YOU KNOW EXACTLY HOW MANY BRACKETS YOU HAVE TO TYPE FROM THE BEGINNING.
Also, the only time I needed to use the dot was to get the longitude out of the struct. Are the dot-notation-naysayers really saying that I have to type all those brackets because of that single dot attached to the struct? Whatever.
Geeze. This post went from casual to rage in a hurry.
Working on a new/old project. Thought I would wrap my UIPickerView customizations into a self-contained class. Here it is.
I’ve improved UIPickerView by adding in presentation and interaction functionality that it should frankly have had from the beginning. Here’s what it does:
1.) Added a (void)show and (void)hide method. This makes the pickerView pop up from the bottom of the screen and pop back when asked. When the pickerView pops up, the background of the view controller (or navigation controller if that’s what we’re presenting in) dims and becomes a dismissal tap target.
2.) Added three delegate methods to notify clients if the pickerView has popped up, if it has disappeared, or if the selection indicator was tapped.
To use it in your view controller, just make your VC conform to the JMPickerViewDelegate protocol, and init it with a delegate and view controller. Easy peasy!