32 posts tagged “programming”

UITableView scrolling performance gotcha

Sep 30, 2009
Post a comment

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.

Objective-C discourages good OO design/code?

Jun 28, 2009
Post a comment

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.

UIScrollView and Multi-Touch zooming

May 19, 2009
4 comments

Let's say you have a nice, big, hi-res photo you want to show to your user on the iPhone. No doubt you want to let your user zoom in to see details of the photo and scroll around, just like the built-in Photos.app.

Most of you would probably come up with something akin to the following structure using Interface Builder:

UIView

|

--UIScrollView

|

--UIImageView

If you are coding the UI by hand, the top level UIView would probably be omitted. This may or may not be relevant to the issue you'll be encountering. See my note at the end.

Now that the view structure is setup, you will probably discover that double tapping to zoom in/out is not implemented out of the box by Apple (surprise!).

"Ok", you thought to yourself, "I just need to implement the touch events in the controller and it will all work."

So you go ahead and added touch event code to the controller class, probably something like this:

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {

UITouch *touch = [touches anyObject];

NSInteger tapCount = [touch tapCount];

if (tapCount == 2) {

[scrollView_ setZoomScale:zoomScale animated:YES];

}

When you run the code, you'll find that the touchesEnded method never get called!

Turns out this is actually by design from Apple. touchesEnded and other touch event methods are no-op methods by default. My guess is that this is probably a performance related design decision.

Regardless of why, here is what you need to do to 'fix' this. First, create a new class that inherits from UIScrollView. Then in this new subclass, implements the touch event method that you want to use and passes on the event to the next responder in the list. Like this:

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event

{

[super touchesEnded:touches withEvent:event];

[self.nextResponder touchesEnded:touches withEvent:event];

}

This will pass on the touch event to the parent UIView in the hierarchy and thus calls the touch method in the controller.

Problem solved!

(One thing I haven't tried is to removed the top level UIView from the hierarchy, and link the UIScrollView to the view outlet in the controller. My hunch is that this may eliminate the need to subclass UIScrollView.)

Inoperative Cancel button in UIActionSheet

May 9, 2009
Post a comment

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:

UIAlertSheet

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;

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

UITabBarController *tabBarController = appDelegate.tabBarController_;

[actionSheet showInView:tabBarController.view];

[actionSheet release];

iPhone development talk in Philly

May 9, 2009
Post a comment

Last Tuesday I travelled down to Philadelphia to speak at the Philly ALT.NET meeting. Brian Donahue, the group organiser, invited me to talk about my experience of developing iPhone application from a .NET perspective. Over 20 people turned up and I was surprised that most of them already owned an iPhone and a Mac (remember this is a .NET group afterall).

Waiting for people to fill in for Philly Alt.NET presentation

I began with listing out the things require for iPhone development (hardware and software), then moved onto comparing Objective-C/Xcode with C#/Visual Studio. I showed a quick code demo to illustrate my points on language and environment differences. Finally I talked about the good, bad, and ugly things I feel about iPhone development up to this point.

This is the first time I gave this talk and feel the Philly audience got good value from my experience. The event was hosted at Drexel University campus and a few of the iSchool students were in the audience. One of them even came up to me afterward and asked whether I'd be interested in doing more talks on iPhone development for iSchool!

Here are the slides I presented:

One of the attendee also took some videos and I'll post them as soon as I receive the link.

iPhone Developer's Cookbook review

Dec 30, 2008
Post a comment

The iPhone Developer's Cookbook: Building Applications with the iPhone SDK (Developer's Library)

Erica Sadun

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.

Spit and Polish

Dec 7, 2008
Post a comment

A few months back, I started working on an iPhone app using the beta version of the iPhone SDK. Since then various things got in the way (not to mention the restriction of the old TOS placed on developers so everyone were working in the dark) and I didn't spend any time on it to really finish the app. My interest was revived when I attended the iPhone Tech Talk event in NYC last Tuesday. The sessions were interesting but nothing technical or coding. I learnt a lot more about the process of provisioning an iPhone for development testing and distribution, as well as how to submit app to the iTunes App Store. Most importantly though were that I was able to resolve issues around my personal's Standard and ThoughtWorks' Enterprise applications to the iPhone Developer Program. Now I am able to distribute and test my app on actual phone(s)!

Since Tuesday, I've been spending lots of my free time on polishing up the CCPhone app so I can start distributing it to the masses. One main change from the original vision is the colour theme change. This stems from the advice in the "iPhone User Interface Design" session, where dark colour theme is the preferred colour for apps that people use for short period of time (and possibly under the table/desk).

Another I've found is that the SDK has improved in many ways since the 2.0 days. Now it is easy to find the relevant sample code from the API reference documentation since the links to the sample apps are hyperlinked! There are also a lot more documentation on how to use various type of controls/classes in an advanced manner, much more than just the simple basis stuff. And from talking to all the Apple staff in the Tech Talk, I was impressed by how receptive they are to feedback. Even the really stupid stuff that they shouldn't have released in the first place.

And get this. I ran across a problem with the iPhone Developer Portal on Wednesday when I tried to set myself up with both my personal account and the ThoughtWorks' enterprise account. Somehow I was not able to switch between the two and when I un-assigned myself from the TW's account, I no longer had access to my personal one! With no recourse, I ended up sending an email to Apple and waited. That evening around 5PM, I got a surprise phone call from Apple inquiring about my problem. By that time, the problem had mysteriously resolved itself so I gave the lady on the phone my feedback on the Portal instead. Imagine that, someone actually calls the developer to resolve an issue!

CCPhone is just my way of dipping my toes in the water, testing the temperature. Now I need some more ideas for apps that I can work on.

NY ALT.NET First meeting: OR/M

Sep 25, 2008
Post a comment

Tonight was the first NY ALT.NET meetup and I think it has gone very well. Over 30 people turned up and many have not participated in a fishbowl style discussion before. Stephen Bohlen first gave a quick, 10 minutes, overview of OR/M. Then after a quick pizza break Don Demsak, Stephen Bohlen, and Mark Pollack kicked off the discussion and soon more people joined in the fishbowl experience. After the meeting, I talked to a few attendees and all of them gave very favorable feedback about this more interactive style of meetup, verses the traditional presentation by a speaker style.

On the technical side, we decided to stream the video live after we received a few requests from people who couldn't attend in person. The logistic of setting a stream up using Ustream.tv is trivia but there are a huge amount of fingercrossing and wood touching because everything had to come together at the same time:

Mark's DV camera talks to my Macbook Pro via Firewire and record to tape at the same time.
Ustream.tv's player recognized Mark's camera
Ability to get onto Microsoft's guest wi-fi network
Ability to find a place to put the camera that doesn't get into people's view but close enough to get decent sound reception

Having said that, I can't imagine streaming live video on the internet to the public 5 years ago (or even 2!) without huge infrastructure expense, lots of testings, and poor results. Now, it is free, easy to setup, and provide great user experience.

Here is Stephen Bohlen gave an overview of OR/M before the main discussion (~10 mins):

The main discussion (~1 hr 47 mins):

What? A year already?

Aug 16, 2008
Post a comment

How time has flied! It has been a year since I joined ThoughtWorks. In the last 12 months, I've:

Visited ThoughtWorks India in Bangalore
Worked in 3 totally different projects (.Net desktop app, build & deploy at an enterprise level, and Agile coaching) in 3 different locations (London, Connecticut, New York)
Became a committer of an Open Source project, DbDeploy.net
Attended ALT.NET conference in Seattle
Started ALT.NET NYC with a bunch of great, like-minded developers
Edited 4 ThoughtWorks IT Matters podcasts
Helped out with recruitment (code reviews, office interviews, phone interviews)

Skills and tools that I've learnt/developed that I didn't think I would otherwise:

Agile project management, planning, estimation (Mingle)
Presentation and coaching (PowerPoint!, public speaking)
Build & Deploy (CruiseControl.NET, Cruise, TeamCity, NAnt, MSBuild, PowerShell, etc.)
iPhone development
Mocking (NMock, Moq)
UI Automated testing (Selenium)

What I can't quantify is the amount of learning I've done during this time. Working with smarter people than myself drove me to self-improvement in ways that I did not think I can or would.

I don't know what would happen in the next 12 months but one thing for sure, I would definitely enjoy it.

Build there, check status everywhere

Jun 29, 2008
10 comments

I've been using the iPhone SDK since its original release way back in March. Many frustrating moment in the beginning but the recent beta 7 and beta 8 release proved to be ready for prime time. Apple has added many helper classes or helper methods to classes to make it far easier to work with the UI components, which is by far the most frustrating things I encountered. I am still having problem wrapping my head around the idea of Interface Builder but since the apps that I am building do not involve very complex UI, I just hand coded all the UI instead.

To illustrate, the original iPhone app idea I had that I started developing using the original SDK is a mobile application for Mingle. The application would consist of a series of table views showing projects, cards, and card details, along with some network code to talk to the Mingle server through REST API. At that time, progress was slow because of many factors. First, learning Cocoa/Cocoa Touch API and Xcode at the same time was tough. Second, the Cocoa Touch API was a bit 'primitive' in the beginning. What I mean is that while the API provides all the necessary hooks for developers to create an iPhone app it does not provide many pre-build components, making it difficult and required lots more work from developers to re-create the look and feel of the built-in iPhone apps.

I was so put off by the initial experience that I skipped beta 4-6 and did not open up Xcode until last weekend. And what a refreshing change with beta 7! Now it is straightforward to make an app that looks and feels just like an Apple's one. I was so fired up that last Sunday evening I decided that I would try to create an app for an idea that one of my fellow ThoughtWorker suggested to me. Instead of days of tearing my hair out and got no where, I was able to create a almost features completed app within hours, using beta 8.

So what is this app? It checks the build status on the CruiseControl server. Just like CCTray (Windows) or CCMenu (OS X), it allows users to monitor their software build status. Following the convention, I am calling it CCPhone. The app isn't more complex than the Mingle app but the fact that I was able to almost match the productivity I normally get on my Windows development environment means that I was excited about working on the app rather than dreading it.

Now here are couple of screen shots: