Tuesday, November 10, 2009

Navigation-based Application Core Data Tempalte

I've updated the Navigation-Based Core Data Application Xcode project to include a suggested workaround to a problem in NSFetchedResultsController. I believe this problem only existed in SDK 3.0 and was later fixed, but for backwards compatibility, I've added the workaround to the project template for anyone interested in supporting 3.0 users.

As before, unzip and copy the folder to this location, replacing the one that's there:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Project Templates/Application/Navigation-based Application/

Note: I updated the project yet again, at 1:11 pm Eastern time, to deal with a problem with inserting the first object when using a section name key path. Because tables can't have zero sections, this new version checks to make sure before inserting a new section, that it isn't an empty table getting its first row. In that case, the table will already have one section and doesn't need a second. Adding a second in that scenario causes a crash.


Thanks to Simon Wolf for catching it

NYC Tech Talk Update

I had heard about a few isolated incidents of people receiving acceptance notices for the NYC Tech Talk next month, but now they seem to be rolling out of Cupertino like rolling thunder. Several people have reported that they got their confirmations overnight, and I did as well.

See you in December.

Monday, November 9, 2009

NSFetchedResultsController

I have been fighting with NSFetchedResultsController. After some struggles, I think I have finally made peace with it.

If you want to save yourself some hassle, replace your current Navigation-Based Core Data Application Xcode project with this one. Unzip and copy the folder to this location, replacing the one that's there:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Project Templates/Application/Navigation-based Application/

NSConference 2010

I am pleased to announce that I will be speaking at both NSConference 2010 Europe and NSConference 2010 USA. I've never been to NSConference before, but have heard only wonderful things about it. I'm excited to finally be attending, and to be speaking at the inaugural US NSConference.

After taking a look over the Speaker List, I was pretty sure inviting me was an accident, but I said yes before they could change their mind.

Registration for NSConference Europe is already open, and the prices are very reasonable. Registration for NSConference USA should be opening soon.

MKMapView Category

I've been working with MapKit quite a bit the last few days as I finish the chapter on MapKit. I was surprised to find that the map view didn't have a method for telling you whether specific coordinates were currently being shown on screen. The map view has a method to tell you whether the user's current location is visible, but I couldn't find one to that indicated if any arbitrary coordinates were currently visible on screen.

This category rectifies that.

MKMapView-CoordsDisplay.h
#import <MapKit/MapKit.h>

@interface MKMapView(CoordsDisplay)
- (BOOL)coordinatesInRegion:(CLLocationCoordinate2D)coords;
@end


MKMapView-CoordsDisplay.m
#import "MKMapView-CoordsDisplay.h"

@implementation MKMapView(CoordsDisplay)
- (BOOL)coordinatesInRegion:(CLLocationCoordinate2D)coords
{
CLLocationDegrees leftDegrees = self.region.center.longitude - (self.region.span.longitudeDelta / 2.0);
CLLocationDegrees rightDegrees = self.region.center.longitude + (self.region.span.longitudeDelta / 2.0);
CLLocationDegrees bottomDegrees = self.region.center.latitude - (self.region.span.latitudeDelta / 2.0);
CLLocationDegrees topDegrees = self.region.center.latitude + (self.region.span.latitudeDelta / 2.0);

return leftDegrees <= coords.longitude && coords.longitude <= rightDegrees && bottomDegrees <= coords.latitude && coords.latitude <= topDegrees;
}

@end

The UI Cockroach

Back in the eighties, during the cold war, the possibility of a nuclear holocaust was a widely-discussed topic in both fiction and casual conversation. As part of that, there was a persistent belief that the one thing that would survive, no matter how bad the nuclear winter, was the lowly cockroach. I have no idea if there's any science behind this belief, but it's a persistent one, seen in popular culture as recently as 2008's Wall•E.

I would like to suggest that a User Interface element that is completely unnecessary and not part of an application's core functionality, yet can't be gotten rid of, be called a UI Cockroach. A shining example of this is the ribbon bar in Word 2008, which is that circa-2001 Aqua-style bar right above the ruler:



You can't get rid of this thing as long as you're in layout view. Although Microsoft has provided literally hundreds of configurable toolbar items that can be reorganized, reconfigured, hidden, combined, and detached in ways that no sane person would ever want or need, somebody at Microsoft made the decision that this monstrosity had to stay on the screen at all times no matter what. Even if you press the lozenge in the upper right of the window's toolbar — the one that hides all the toolbar elements — it still says visible.

And it serves very little in the way of a useful purpose. When you click-it accidentally, you're treated to an absolute abuse of Core Animation. It's animation that serves absolutely no useful purpose. It's there because somebody wanted to do it. I know a lot of Apple-haters think that the animation in Apple's applications are just bells and whistles, but they aren't. WIth few exceptions, Apple uses animation as a visual cue to convey something to the user. Even the much-maligned minimize genie animation serves the purposes of making sure you know where your window went. If it just disappeared, and you didn't already know where minimized windows went, you'd be stuck searching for it. With that animation, you have a visual clue about the fact that it went to the Dock.

The galleries available in the ribbon bar, however, just pop up for no apparent reason. Worse than that, they don't all pop up at the same time, so you lose a few seconds waiting for them all to show up. A few seconds may not seem like much, but if you multiply that by the times you've hit it and the number of people who have, it's not an insubstantial number of seconds that have been wasted by a completely superfluous animation. I'm actually kind of surprised they don't have them all burst into flames when you close the gallery.

I will never, ever use this horrible, horrible ribbon thing. I want that screen real-estate back, and I don't want to ever accidentally be exposed to those horrid document styles or Microsof'ts über-hokey text art again, never mind the silly, superfluous animation that is used to present them.

The only way to describe this is: obnoxious. Well, that's not the only way. I can think of many adjectives that also fit. Ill-advised, ill-considered, and tasteless all work, too.

If anyone knows a way to kill this thing with fire, please, please tell me.

iPhone "Worm"

Many sources are reporting on the existence of an iPhone "Worm" that RickRolls the phone's user. Harmless, but troublesome.

It should be noted, however, that this isn't exploiting a known security hole in the iPhone, but rather is a side-effect of one-button JailBreaking. By packing up the JailBreak process so that anybody can do it, regardless of their level of technical knowledge, the JailBreak community has handed less technically adept people a loaded gun that they've never been trained to use. People in the jailbreak community know enough to change the default password used by their jailbroken phone's SSH server, but many of the less-technically adept people who have used Quick-PWN and other JailBreaking tools do not. Some of them likely don't even know what SSH is.

This time, people are only shooting themselves in the foot. Next time, it could be the head. Next time, it could impact all of us. Instead of a RickRoll, it could be a DDOS attack that degrades AT&T's already horrid network.

if you're going to jailbreak your phone (and personally, I would rather you didn't), it's your responsibility to make sure you understand the risks you are taking by doing so, and that you take reasonable steps to secure your phone. If you don't know enough to do that, leave your phone the frack alone.

I fully expect Apple to redouble their efforts to prevent JailBreaking and, you know what? It's perfectly understandable. The idea of a totally open and unrestricted device is great, in theory. It would be great if all the people with those open and unrestricted devices were all technically adept super-users or developers. When you throw less-techical people into the mix with a device that's always connected to a shared network, the theory falls apart. Simply put, most people should have a locked-down phone, and it has nothing to do with wanting to restrict what you can do with your device, it has to do with making sure the rest of us are able to use ours.