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.

I recently wrote an iPhone application for a client using v2.2.1 of the iPhone SDK. (The client did not want to go OS v3.0 yet.) I needed to give a user the capability of taking and uploading a picture with the built-in camera or uploading a picture from the photo library on the phone. Seems pretty straightforward so far. Yes? I thought so. It turned out to be pretty tricky but the solution was very simple and was staring me in the face. The Problem I had a UIViewController with an UIImageView setup to be used as a container for the selected image. I also had several UIButtons on the page. (One button for calling up the camera. Another button for calling up the photo library, etc...) So what should have happened is that the Camera or photo library UI would display a Modal View window the user instructing them to either take a picture or select a photo from their library. Once they did that, they would be returned to the main view and whatever photo they took or selected would appear in UIImageView as a preview. However, when I was selecting the photo the "editingInfo" NSDictionary object that was supposed to be returned would be there only about 50% of the time. The other 50% it would be returned empty. I double and triple checked my code and it was all correct. Something was zapping my dictionary object and I couldn't, for the life of me, figure out what it was. The second part to this problem was that the preview image never appeared whenever the user was grabbing their image from the camera. It worked if the photo library was the source but not if it was the camera. Very, very frustrating. Here is my original code: My .h file - [code lang="cpp"] @interface AddPhotoController : UIViewController { IBOutlet UIImageView *imageView; IBOutlet UIButton *snapNewPictureButton; IBOutlet UIButton *selectFromPhotoLibraryButton; } @property (nonatomic, retain) UIImageView *imageView; @property (nonatomic, retain) UIButton *snapNewPictureButton; @property (nonatomic, retain) UIButton * selectFromPhotoLibraryButton; [/code] My .m file - [code lang="cpp"] @implementation AddPhotoController @synthesize imageView, snapNewPictureButton, selectFromPhotoLibraryButton; - (IBAction)getCameraPicture:(id)sender { UIImagePickerController *picker = [[UIImagePickerController alloc] init]; picker.delegate = self; picker.sourceType = UIImagePickerControllerSourceTypeCamera; picker.allowsImageEditing = YES; [self presentModalViewController:picker animated:YES]; [picker release]; } - (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingImage:(UIImage *)image editingInfo:(NSDictionary *)editingInfo { NSLog(@"Image Meta Info.: %@",editingInfo); UIImage *selectedImage = image; imageView.image = selectedImage; self._havePictureData = YES; [self.useThisPhotoButton setEnabled:YES]; [picker dismissModalViewControllerAnimated:YES]; } - (void)imagePickerControllerDidCancel:(UIImagePickerController *)picker { [picker dismissModalViewControllerAnimated:YES]; } [/code] Like I said before, it all seems pretty straightforward. However, there were two things wrong with the above code. #1. Deprecated Method The UIImagePickerController method, – imagePickerController:didFinishPickingImage:editingInfo:, is deprecated in v3.0 of the iPhone OS. So even though I built the app using SDK v2.2.1, because the app will be running on 3.0 devices, I needed to use the new and improved method, - imagePickerController:didFinishPickingMediaWithInfo:editingInfo, which contains FIVE pieces of really important information:

1. UIImagePickerControllerMediaType - Which specifies the type of media that this dictionary contains.
2. UIImagePickerControllerOriginalImage - Contains the original non-cropped image.
3. UIImagePickerControllerEditedImage - Contains the user-edited cropped image.
4. UIImagePickerControllerCropRect - Contains the CGRect that was applied to the original image.
5. UIImagePickerControllerMediaURL - If the object is a movie, this object contains the URL to be used by the media player.

I simply accessed the "UIImagePickerControllerEditedImage" object from the dictionary and was off to the races. #2. Dismissing the Modal View This one was really painful as it was so simple to solve. In order for the UIImageView to be updated correctly, you must dismiss the ImagePicker modal window BEFORE you attempt to update your UIImageView. As a result of this, here is my updated method call: [code lang="cpp"] - (void) imagePickerController:(UIImagePickerController *)thePicker didFinishPickingMediaWithInfo:(NSDictionary *)imageInfo { [thePicker dismissModalViewControllerAnimated:YES]; UIImage *img = [imageInfo objectForKey:@"UIImagePickerControllerEditedImage"]; previewImage.image = nil; self.previewImage.image = img; NSData *imageData = UIImagePNGRepresentation(img); if ([imageData length] > 0) { [self archivePictureData:imageData]; self._havePictureData = YES; [self.useThisPhotoButton setEnabled:YES]; } } [/code] That was it. Hope that was 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.

I was really excited by the news of the new iPhone OS v3.0 announced last week. Copy-and-Paste aside, there are a lot of less-talked-about features that I find pretty cool and crucial to the advancement of the platform:

Peer-to-Peer Connectivity over Bluetooth

This is a feature that I thought seemed so obvious to have baked in. With Peer-to-Peer connectivity, you are now given the ability to communicate with other local phones WITHOUT having to pair with them in order to do it. (Like you have to when you use a Bluetooth mouse or headset.) This is great for applications that would need to share pieces of data for short periods of time. Or games that share proximity for a short period of time. I'm just starting to mess with this now so I am really anxious to see what the full line of functionality that is provided for is.

In App Purchase With this feature, in my mind, the iPhone grows up. Now is when e-commerce will really begin to take off with the device. I also feel that now we will *really* begin to see some money being made in the mobile arena. In App Purchasing means that you can have fully-functional mobile e-commerce without having an entire website and all of the complexities that it involves. (Yes, I realize I am a developer of web-based e-commerce solutions. We plan to make some of that money.)

iPhone Core Data Of all the new functionality and features presented... none were more significant, (for me), then Core Data now being available on the iPhone. For those of you less geek-inclined... Core Data (http://developer.apple.com/macosx/coredata.html) is a method for managing the data model for MacOSX applications. Up until now you had to write your own methods for handling things like data relationships, the adding, updating and deletion of records.

As anyone who has had to build an application with persistent data will tell you, while it's awesome to be able to develop using SQLite and plists on the iPhone, it does not compare with being able to code against an abstraction layer that just works! So I'll take the added complexity associated with Core Data any day of the week.

In Summary I love developing for the iPhone and the Macintosh. The iPhone OS v3.0, even in BETA, is such a huge leap forward. Not just for the platform, but those who write software for the iPhone and have been waiting for Apple to enable developers to really take their applications to a level above "cute" or "neato" or niche.

The only outstanding issue I see before Apple is it's whole approval/review/rejection process for iPhone applications. As a developer, it is a really frustrating process. Their methods just seem so arbitrary. (One app gets rejected. Similar app, different developer and it get approved.) I would be willing to forego new features and frameworks in the short-term in order to give Apple more time to create a more thoughtful and predictable review process with metrics and benchmarks to boot.

I've recently *really* been getting into Cocoa development for both the MacOSX and the iPhone. Can I just say that Cocoa, (especially Cocoa Touch), ROCKS!!! I am in the middle of building a soon-to-be-published app for the Apple App Store. I forgot how much I loved writing C code. Objective-C is really a nice, simple and clean language. I'll be posting some tutorials on it soon.