Objective C’s Verbosity

I enjoy the verbosity of Objective-C; those long method names and variable are fun to read (and fun to write with auto-completion turned on). Recently, I accepted that fact that some people like to limit code to 120 characters (or even 80 characters). Code lines this short are predictable at small window sizes, a big advantage in small terminal windows. Even though I’m writing code in XCode on a 27” iMac, I thought I’d give this a try.

Mashed Potatoes

It turns out that Objective-C formatted this way starts to look like an unreadable pile of mash. What I immediately noticed is that I rely upon the long method definitions to break apart my code. Using a line limit makes it harder to distinguish sections that previously were quite pronounced.

I’ll admit I was a little disappointed to go back to long lines, so I decided to do some investigating. I thought, “Lets see what any famous open-source project does in their code.” Moments later, I was on the Chameleon GitHub page and to my utter surprise—the code style had no line limit at all.

I hit up @BigZaphod (the primary author of the Chameleon project) on Twitter to see what he had to say about code formatting:

@bentford No one has ever mentioned it. :) My limit is basically “size of my window” but it doesn’t really bother me much.

— Sean Heber (@BigZaphod) January 24, 2013

Conclusion

I’m happy to report that I went back to my old style. I’ve changed it up a bit and try to keep long code lines to a minimum. In Objective-C, it makes sense to let those long lines be.

It’s a nice feeling to gain confidence in a decision you’re not sure about simply by asking a respected peer.

Related Links

http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

https://wincent.com/blog/on-the-80-column-limit

List of opensource projects and their styles

No Limit

Chameleon:
https://github.com/BigZaphod/Chameleon

Tapku:
https://github.com/devinross/tapkulibrary

InAppSettingsKit:
https://github.com/futuretap/InAppSettingsKit

Sharekit (mostly does not):
https://github.com/ShareKit/ShareKit

Hockey:
https://github.com/TheRealKerni/HockeyKit/

MTStatusBarOverlay:
https://github.com/myell0w/MTStatusBarOverlay

Some Limits, Some Not

RouteMe:
https://github.com/route-me/route-me/

Has Limit

Three20 limits to 100 characters by lining up colons. But also uses /////////// to signal breaks in methods.

This post is more for my reference than anything else, but it may come in useful to other people.

I’m slowly starting to incorporate 3D elements into UI elements of a few different iOS applications. For decent looking output in OpenGL ES2, you need three basic elements for a model: vertex data, normals, and texture coordinates. I’m happy using simple objects, a lot can be accomplished with a plane and cube, but manually creating the coordinates has been tedius to accomplish by hand.

I’m lucky to have copy of Cinema 4D 11.5 lying around; eventually I hope to create some other primary shapes, perhaps a sphere and rounded corner box. Cinema 4D 11.5 does export models int the OBJ format, but it doesn’t include normals, so it’s useless for importing into OpenGL ES2.

The riptide plugin is a fully featured OBJ exporter that exports normals. The free version of riptide doesn’t work on Cinema 4D 11.5, but the pro version does, which costs only $50. I tried out the demo version and it did the job perfectly.

The last step in the process would be importing the OBJ format into my application code. I’ll post more once I get this far (but don’t hold your breath, it will be a while.)

Links

OBJ Parser writting in Obj-C:
http://code.google.com/p/iphonewavefrontloader/

OBJ Parser writtin in C:
http://www.kixor.net/dev/objloader/

Riptide Pro:
http://skinprops.com/riptidepro.php

Wavefront OBJ format:
http://www.eg-models.de/formats/Format_Obj.html

The Wavefront .obj format

a comment until the end of the line

# some text

A single vertex coordinate. The first vertex listed in the file has index 1, and subsequent vertices are numbered sequentially.

v float float float

A single normal. The first normal in the file is index 1, and subsequent normals are numbered sequentially.

vn float float float

A texture coordinate. The first texture coordinate in the file is index 1, and subsequent textures are numbered sequentially.

vt float float

A polygon face. The numbers are indexes into the arrays of vertex positions, texture coordinates, and normals respectively. A number may be omitted if, for example, texture coordinates are not being defined in the model.

f int int int ...
    or
f int/int int/int int/int...
    or
f int/int/int int/int/int int/int/int ...

There is no maximum number of vertices that a single polygon may contain. The .obj file specification says that each face must be flat and convex.

Example of an .obj cube:

v 1 1 1
v 1 1 -1
v 1 -1 1
v 1 -1 -1
v -1 1 1
v -1 1 -1
v -1 -1 1
v -1 -1 -1
f 1 3 4 2
f 5 7 8 6
f 1 5 6 2
f 3 7 8 4
f 1 5 7 3
f 2 6 8 4

Are you getting this error while doing CoreData multi-threading: “An observer of NSManagedObjectContextDidSaveNotification illegally threw an exception”?

I was stuck on this problem, and reading the CoreData docs wasn’t helping. Doing everything in the section “using thread confinement to support concurrency” wasn’t helping.

This error randomly produces exceptions and crashes.

This fix is embarassingly simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// getting this error?
// "An observer of NSManagedObjectContextDidSaveNotification illegally threw an exception"

// observing the notification here 
[[NSNotificationCenter defaultCenter] addObserver:self
                                        selector:@selector(otherContextDidSave:)
                                            name:NSManagedObjectContextDidSaveNotification object:nil];


// FIX: you must mergeChangesFromContextDidSaveNotification: on main thread
// handling the notification occurs on background thread. 
// it needs to "merge" on the main thread.
- (void)otherContextDidSave:(NSNotification *)didSaveNotification {
    NSManagedObjectContext *context = (NSManagedObjectContext *)didSaveNotification.object;

    if( context.persistentStoreCoordinator == globalContext.persistentStoreCoordinator )
        [globalContext performSelectorOnMainThread:@selector(mergeChangesFromContextDidSaveNotification:)
                                        withObject:didSaveNotification waitUntilDone:NO];
}

The 3.5 years that Apple spent working on the first iPhone before releasing it in 2007 is a indicator of the amount of work Apple puts into new products. It takes an immense effort to invent ground breaking technology.

Apple doesn’t launch things just because they can. They endlessly toil away behind the scenes to refine the small details. This is apparenly what is happening with the AppleTV SDK.

Simply putting Apps onto the AppleTV causes many problems.

List of Problems

• Are users going to buy AngryBirds for the 3rd time just to play on the TV? ( Don’t forget that you can AirPlay iPhone and iPad apps over to the AppleTV now—no extra app purchase needed.)

• How are they going to control the game? I’m betting the controller will be an iPod Touch/iPhone app, but how are people who don’t own these devices going to use it?

• Besides games and video, what kind of Apps make sense on the TV?

• Isn’t an NBC app going to cut into iTunes profits? Is NBC even willing to make an app for AppleTV?

• Is a $99 device that plays all the same AppStore games going to hurt iPod Touch sales?

Apple is either working on something revolutionary, or they are not even thinking about it.

My bet is it is something revolutionary, and it will have us all staring with dropped jaws wondering how we never thought of it before. It might be this year, or in a few years, and I can’t wait for when it happens.

I figured out why the new iPad was not called the iPad 3. The carriers (AT&T and Sprint) are pushing their new 4G data plans, and the new iPad could not be called the “iPad 3 4G”. That is a truly awful name.

Instead, it became the “new iPad”.