After a few months of .NET reporting/SSIS development work, I’m back to an iPhone project this week. One enhancement I added yesterday was a better formatted table section title in a UITableView. Before, the section title is either a bunch of unformatted (also incorrectly by locale) dates (e.g. 2009-09-30), or times (e.g. 14:58) straight from the data source. The enhancement/bug fix is to format the date or time to be locale aware so the title would either be “Wed Sep, 30 2009” or “2:58 PM” if you are in the US.
Pretty straightforward I thought, and after a couple of trips to
NSDateFormatter and use the output in UITableView’s
titleForHeaderInSection:section method, it was all working very well in the simulator. That was until I put the app onto my iPhone for some real in-device testing.
The scrolling performance in the table was horrible! My first thought was that it had to do with the background view I added to the custom table cell view for colouring the table cell background. But after nearly an hour of debugging through the code I still couldn’t find anything wrong.
Turns out that the
titleForHeaderInSection:section method is not just called once per controller instantiation. It is called once per table cell display!
Once I moved the code to format the section title into
viewDidLoad and cached a copy of the nicely formatted titles in an array, the scrolling is back to normal speed.
Most people I know do not have any plan to backup their data. Somehow they put their trust to a piece of 3.5″ glass disc, spinning at 5400 times a second or more with a sharp metal spike fraction of a hair above it. Me? I like to spread my risk and backup my data, especially after suffering a total data lost about 12 years ago. As Alex Lindsay from the PixelCorps often says on podcasts, “Unless the data is stored in 3 different places, it doesn’t exist”. This may sound over the top but with all the online file sharing or storage services available it is actually pretty easy to have decent backup strategy with minimum cost. To achieve comprehensive backup coverage, it would definitely cost a few dollars.
Like computer security, any backup strategy should be constructed in layers. This applies to both time, location, and accessibility. Let me use my backup strategy as an example.
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.
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.
One of the great thing about my new E61 is that the built-in music player supports AAC files. So I can play all of my tracks encoded in iTunes. But the one thing the music player can’t do is to read the tags information in the m4a files. It only reads ID3 tags. After some googling, I’ve found this Windows app called mp3tags that copies the tags info in the m4a files into the ID3 tag fields, thus allowing the music player to read and displays them on the screen. But I can’t find any equivalent on the Mac. That sucks! May be it is time for me to dive into XCode and write a tag converter myself!