I was recently building an iPhone app that required a UIButton be held down and then released after a certain period of time had elapsed. The problem I encountered was that testing for touchesBegan didn't work for buttons. I'm not talking about UIControlEvents. I didn't need to know that button had been tapped or it's current state. I needed to know when the button was being pressed and when it was released. The solution was to simply create a UIButton subclass and pass it's touches up the responder chain. MyButton.h - [code lang="cpp"] @interface MyButton : UIButton { } - (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event; @end [/code] MyButton.m - [code lang="cpp"] #import "BrakeButton.h" @implementation BrakeButton - (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event { [self.nextResponder touchesBegan:touches withEvent:event]; // This is where the touch is passed on } - (void) touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event { [self.nextResponder touchesEnded:touches withEvent:event]; // This is where the touch is passed on } @end [/code] Then in your view controller be sure to import your new class: [code lang="cpp"] #import "MyButton.h" [/code] Then you simply implement the touchesBegan and touchesEnded methods. [code lang="cpp"] -(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event { NSLog(@"Button Touches began"); } -(void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event { NSLog(@"Button Touches ended"); } [/code] So what is happening here? The main point to understand is that UIButtons are in actuality just UIViews. So they inherit from UIViews giving them the ability to access UIView-like functionality. (touchesBegan, touchesEnded, etc...) I've seen many folks banging their heads against the wall trying to figure out how to capture / intercept button touches so I apparently it's a pretty common problem. Let me know if you find this helpful.

About a month ago, my company: WebSight Design released our first iPhone application, (http://itunes.com/app/Santana), for the musician Carlos Santana. I thought it might be interesting and maybe even helpful for others iPhone developers if I listed some of my experiences with building this application. I figure I would describe the application (features, etc...), and illustrate some of the pitfalls I encountered throughout the development process and how they were dealt with.

Application Features
Right off the bat, having such a distinctive and dynamic client such as Carlos Santana means that nothing can be done in a simply pedestrian manner. (The man is an icon for crying out loud.) We wanted to incorporate custom artwork to try to create an immersive as an experience as possible. (Without blowing the bank of course.) We wanted the focus to be on his music. So we started there. Our Creative Director has been working with Santana for years now so she knew exactly what needed to be done. She came up with the icons for the navigation and the photo-scroller watermark image.

Seeing how we wanted it to be focused on Carlos' music, we incorporated several of his most popular music videos and song tracks. We optimized all of the videos for delivery specifically for the iPhone. We included his entire album discography and even included links to purchase songs and entire albums, (How old am I that I actually refer to them as "albums".), via iTunes. but we also wanted to take advantage of the intimate nature of the iPhone by bringing back a feature that Carlos had intended for his website called: Musician's Corner.

I really wanted to take advantage of the personal or intimate nature of the iPhone. On Santana.com, there is a section buried way, way down on the site called "The Musician's Corner". The original intent was to establish an area online where fellow musicians and fans could see and hear directly from Carlos and the musicians in his band, and learn how they work. Gain a better understanding and appreciation of some of his most popular songs. A few videos had been recorded and posted to the Santana website. Unfortunately, it never really took off. (I think, because it was so buried on the site.) However, I felt that the iPhone was the PERFECT platform for this type of content. With the tacit agreement from Santana Management, we added two videos for a couple of Carlos' most popular songs: Black Magic Woman and Oye Como Va. We added them to the "More" section of the application under the heading "Lessons".

So all told, we had about 12 videos and 25 music tracks. Plus, the discography, bio information, News and Tour Dates, made for a pretty hefty app. (Both in size and overall experience.)

Ad-hoc Distribution
Once we had the foundation laid out, I wanted to get the application installed on Carlos' and/or an iPhone for Santana Management. Apple provides two methods for deploying an app on to an iPhone: 1.) Via the App Store. 2.) Via Ad-hoc Distribution. Ad-hoc is the method given to developers to test their app or to get client approvals and such. Apple is very clear about it's instructions on what you need to do in order to make Ad-hoc distribution work. I was so focused on building the app that I didn't test as throughly as I could have, the steps to make the ad-hoc method work. The day came that Santana Management wanted me to install the application so they could play with it and review it. Sat there for several hours and could not for the life of me get it to work. That could have killed the deal right then and there. Thankfully, the folks over at Santana Management were very cool and understanding. They saw it running on my phone so they knew I wasn't trying to pull a fast one. Still, that could have spelled the end-game right there.

Certificates and App Store Submission
Actually, writing the app code was the easy part compared to submitting the app to Apple and getting through their review process. First off, you have no idea how long it will take. You aren't given a ballpark or even just a rough estimate. Nada. You just have to wait. We waited for one month before we were finally approved. (I have spoken with folks at Apple and they have since told me that the amount of time we spent "In Review" was about normal.)

My second error in this whole thing was that I failed to put in the appropriate alerts for when there is no available Internet connection. (Either WiFi, 3G or Edge.) I know, I know... a really silly, academic and time-wasting error. Well, Apple caught it immediately and rejected the app. doh! However, corrected the error and resubmitted the app within 24 hours of said rejection. One month later, I received notice that we were approved and inserted into the App Store.

Lessons Learned
There are several lessons I took away from the whole experience of developing for the iPhone platform for the first time. Here are a few of them:

1. Read the Apple Human Interface Guidelines (HIG): Apple is *very* serious about developers following their guidelines. Plus, it's actually a really good read with lots of extremely helpful information. Don't skip this... you have been warned.
   
2. Work With A Designer: I recently attended an iPhone Tech Talk where I sat in on the UI Design workshop. Several iPhone apps were compared to one another. Time-and-time again, the most popular apps in their category were the ones with original artwork and a unique UI. Let's face it. A table view is what it is. The trick is to come up with a unique approach to solving common problems. I was lucky enough to have access to a great designer. Take the time to work on the UI.
3. Check for Leaks: Leaks will crash your app. Apple provides an AWESOME app called Shark to help with tracking down memory leaks and helping optimize your code.
   
4. Code to Avoid Leaks: There are many best practices you should follow to avoid writing "leaky" code to begin with. Remember, there is no garbage collecting on the iPhone yet, (we'll see in v3.0), so be sure to watch your retain-and-release counts. (It sounds much more daunting than it actually is.)
5. Use the Simulator But Don't Rely On It: The iPhone simulator that comes with the iPhone SDK is very nice but you have to be careful when using it. Sometimes code that works correctly in the simulator DOES NOT work once you compile and deploy onto the phone. This is true inversely as well. For example, I couldn't figure out why I kept getting an error when compiling code for the simulator that included the Media framework. As soon as I just recompiled and deployed to the phone, the error went away.
6. Test Ad-Hoc Deployment: There is gonna come a time when you need to deploy your app on a phone other than the one you use for your development. Perhaps your client would like to see the application running on their phone. You don't want to be caught off guard like that. I know already... it's not a fun position to be in!
   
7. Submit and Be Patient: There is no rhyme-or-reason to the Apple app review process. (At least no reason they've made public anyway.) You just have to submit your app and then walk away. Go walk the dog. Go work on another app. Go be with your family that you have been neglecting for the past few weeks. ;-) Some application categories have a longer review queue than others. Regardless, it's a fact that you're gonna have some time on your hands. Don't fight it. Embrace it.

The only other takeaway from this whole experience I found is that people LOVE Carlos Santana. In the first week alone that the application was available in the Apple App Store, it was downloaded and installed by over one thousand iPhone and iPod Touch users. I've received comments from users that they really love the original artwork and in particular, they really like the music lessons. (I'm a musician too. I know what I'm talking about.)

I would love to hear if anyone has downloaded the app and would like to get your thoughts on it. Drop me a line and let me know.