My first published iPhone app

One of the two iPhone app that I worked on during earlier part of this year has landed on iTunes AppStore! As part of the sponsor for Agile 2009 conference, a small team of ThoughtWorkers developed a conference app to help the attendees. I left my fingerprints on the Twitter, Maps, and Schedule screens. The other interesting parts include the cloud computing (on Google App Engine) that provides up-to-date sync of conference schedules, ability to mark sessions that you plan to attend, and provide feedback to the presenters. The app also includes the Agile Manifesto, the 12 principles, allows you to sign the manifesto, or even send email to your friends to sign up.

Objective-C discourages good OO design/code?

I started learning Objective-C when Apple released the iPhone SDK over a year ago, and started programming in it seriously at the beginning of this year. While there are many things I like about Objective-C as a OO language, there is one thing that continuously bother me.

One of the four main tenant of object-oriented design is Encapsulation. Meaning, the inner working of an object is hidden from public view.

In Objective-C, an instance method can be declared in the implementation file (.m file) in the following ways:

  • Implement the method without declaring it in the header file. This is (almost) equivalent to private method in C#/Java.
  • Declare the method signature in the header file, and implement the method in the .m file. This is like declaring a method public in C#/Java.

So how does this discourages me from writing good OO code with respect to encapsulation?

If I choose the first option, I have two choices. Either I implement the method before its first usage which does no good with readability re Uncle Bob’s Clean Code‘s newspaper metaphor, OR implement it after and put up with the compiler warning about the method call may not exist.

To get the freedom of placing the method anywhere in the .m file, I have to choose the second option and declare the method signature in the header file. The downside of this is that now the method is exposed as part of the class public interface and break encapsulation. (Yes, I know that the method can still be called without the header file declaration. Again, a compiler warning greets you.)

All three options are undesirable to me. It is really a case of pick my poison! Right now, I choose option one and put the method before first usage. Readability suffers because I like reading methods after the usage but at least the header file is clean and represents the intended public interface.

Update: Martin Pilkington makes a suggestion to me via Twitter. I’ll have to try it out and see.

Update #2: Someone else on Twitter also suggests using Extension to solve this issue. The Apple’s documentation here (at the end of the page) shows how an extension of a class can be used to define private method, separated from the main class interface definition.

My initial feel? Pretty inelegant workaround to an inherited problem of Objective-C legacy linkage to C. No thanks, I’ll stick with declaring private methods before usage.

Inoperative Cancel button in UIActionSheet

Let’s say you want to use UIActionSheet to show three buttons to the user with a cancel buttons in a UIView, which itself is managed by a UITabBarController:

Your code would probably look like this:

UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@”Action Title” delegate:self cancelButtonTitle:@”Cancel” destructiveButtonTitle:nil otherButtonTitles:@”Option 1″@”Option 2″@”Option 3″nil];

actionSheet.actionSheetStyle = UIActionSheetStyleDefault;

[actionSheet showInView:self.view];

[actionSheet release];

And you’ll also probably find that all the 3 option buttons works, but the Cancel one doesn’t!
It is because the UIView which the UIAlertSheet belongs to is behind the UITabBarController, and the TabBar’s hitTest method gets called before the UIAlertSheet’s.
To fix this, it is just a simple matter of using the view from the UITabBarController in the showInView method. Like this:

UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@”Action Title” delegate:self cancelButtonTitle:@”Cancel” destructiveButtonTitle:nil otherButtonTitles:@”Option 1″@”Option 2″@”Option 3″nil];

actionSheet.actionSheetStyle = UIActionSheetStyleDefault;

UIApplicationDelegate *appDelegate = (UIApplicationDelegate *)[[UIApplication sharedApplication] delegate];

UITabBarController *tabBarController = appDelegate.tabBarController;

[actionSheet showInView:tabBarController.view];

[actionSheet release];

iMovie needs batch export

Since I was a teenager, I have been fascinated by the process of video production but purely from the technical point of view. The complexity of capturing video, editing (the process not the artistic element), video effects, etc. drove my curiosity. A few years ago I worked with someone who also really into video as well. He captured videos for lots of family events and learnt to use professional tools and techniques. While I get really excited as I discussed the ins and outs of the equipment and setup my friend has, I was definitively unable to find a reason to take video for personal use. Capturing family memory is great but who actually would sit down and watch hours upon hours of family videos, apart from the family themselves?

It all changed when I started organising the NY ALT.NET events last September. We decided that we would video tape each meeting so members who were unable to attend would have a chance to participate, albeit in a passive form. As a result, I started learning to use iMovie ’08 as a tool to process approximately 2 hours of video from each monthly meeting.

When Apple rebuilt iMovie from the ground up for the ’08 version, lots of complains were raised because many features from iMovie ’06 were dropped. What the user gained, however, was a much simpler user interface that makes editing movies a snap. Without any preparation and little learning time, I was able to import, pick video clips, add title and transition, and export videos within minutes. Literally. And the new version iMovie ’09 added new features that were missing from iMovie ’06, such as Precision Editor, themes, more transitions, etc. I especially love the Precision Editor because I can easily control the entry and exit points of each clip with ease.

But, and there’s always a but, all these great time-saving features come to nothing when I need to export the video for people to consume. Because Apple is targeting the consumer market with iMovie (Final Cut Express for prosumer, and Final Cut Studio for pros), there is no facility to batch up video export.

Why is it important? Let’s look at the typical time I spent working on videos for a monthly meeting:

  1. ~2-2.5 hours importing from camcorder. This is fixed time because it is a MiniDV tape camcorder and the only way to get from tape to hard disk is to replay all the footage in realtime.
  2. ~20-30 minutes editing each part. I break down the 2 hours meeting into around 30 minutes parts (actual length depends on the nature stopping point of the conversation). I then change the opening credit, make some adjustment to the audio (boast volume) and video (colour correction).
  3. ~2 hours exporting each final video to hard disk for uploading. This result in a 640×480 H.264 QuickTime video file around 550MB.
  4. ~1 hours uploading to Vimeo.

Now, there is no way for me to multi-task step #1. There is only one camcorder and thus I can only do one import at a time. Not a big problem as I can do other things once the import has started.

Step #4 is a background process. Once I kicked it off in the browser, I can do other things on the computer. For example, step #2.

The problem is with step #3. iMovie does not have the ability to export video in the background. What it means is that once the exporting process has started, I can’t use iMovie to work on my next clip and thus save time. It would not be that bad if iMovie uses all the CPU power my computer has. My Mac Pro has two CPUs, each CPU has two cores, making it a total of four cores. That’s a lot of computing power. But iMovie can only take advantage of one CPU at a time! So instead of a reasonable export time of around an hour, I have to wait for two before I can work on the next clip.

Now, if iMovie is able to export in the background, then at least I can work on the next clip using one CPU while exporting uses the other CPU. Alternatively, if iMovie has the facility to batch up videos for export in a queue, then I can work on editing all the clips and export them in a single batch while I sleep, or do whatever. But iMovie has neither and so the process of producing four 30 minutes video clips basically takes up most of my weekend instead of a few hours. Granted most of the time is spent waiting but still…

Of course one can argue that background or batch exporting is a pro feature and I agree. But when should I sacrifice the ease of use of iMovie, learn a completely different editing paradigm (arguably more difficult to use), just so I can save a few hours each months when my hardware is more than capable? I am more than willing to pay extra for iMoviePlus or plug-ins to achieve what I need but unfortunately I don’t think either would be available any time soon.

iPhone Developer’s Cookbook review

When learning a new language/platform/framework, sometimes learning from a book is a good approach. But that depends heavily on picking the 'right' book. What I mean is that the book contains the 'right' amount of content for the reader's skill level. So when I looked for book to learn more about iPhone development, I have something specific in my mind already.

With Apple's original rather restrictive NDA placed on iPhone developers, all the iPhone development books were placed on hold until Apple changed of mind a few months back. One of the book that I received good recommendation from fellow ThoughtWorkers who were also interested in iPhone development was Erica Sudan's iPhone Developer's Cookbook. I bought it earlier this month along with Christmas presents so I can read it during the holiday vacation.

The book is not thick at all, coming just under 340 pages, and took me couple of afternoons to read through. It is written half in traditional cover-to-cover manner and half in 'recipe' manner where developers can find solutions to problem quickly. Perhaps because I've been part of the iPhone SDK program since the beginning and had seen the evolution from the first beta, most of the book content (I'd say 90%) is not new to me. Particularly the sections on table, advanced table, and UI controls are areas that I am already very familiar with after poking around the SDK for over 6 months. I did learn some valuable tips on media and animation, which I've not spent any time on yet.
I'm kind of disappointed by the book because I was hoping I would learn how to create great iPhone app. Particular I was looking for code examples of common application requirements (e.g. how to implement options screen) with in-depth discussion on the limitations imposed by the public API, alternative ways to work around them using legitimate means, as well as undocumented API. I am also hoping to see some mention of unit testing with OCUnit or Google's unit testing framework, profiling using Instrument, and other libraries that would fill in the API gaps. Instead, the book only provides isolated information on each topic and spends to my mind, a disproportion amount of time on undocumented API thus giving it an implicit approval. (On the topic of private/undocumented API, I am in the camp of John Gruber of Daring Fireball)
In the end, I would give this book 3 out of 5 because it provides a lot of valuable information for any one starting out with iPhone development. But it does not provide any insight into building great iPhone application, which I think is sorely missing in this area.

Read and post comments |
Send to a friend

Website Built with WordPress.com.

Up ↑

%d bloggers like this: