I've been playing around with development for Mac OS X and iOS for a few years. I've had a pretty good grasp of how Cocoa and UIKit worked, and I've written some simple apps, but for the past month I've been working on my first Real iOS Application. I've had to solve some problems that were easily ignored when writing little apps for fun. What follows is a randomly ordered collection of some of the little techniques and tips I didn't know before, which may be useful for other Cocoa newbies.
My wife, stepson, and I carpooled today. I picked them up at school and we made the 45-minute drive back home. As we parked the car, my wife noticed that she didn't have her iPhone.
Newcomers to iPhone development are sometimes surprised at how ugly the standard button controls are. They quickly learn that they need a graphic artist to create a nice-looking button image in Photoshop and then attach that to the buttons. However, in this tutorial, I'll show how to create nice shiny buttons in code, without any image files, by using a
Version 1.1 of JacksOrBetter for the iPhone and iPod Touch is now available, and it's still free. If you have an iPhone or iPod Touch, you can get it from the App Store.
This version has a lot of cosmetic improvements over version 1.0. Version 1.0 was, frankly, a little embarrassing, and I'm glad I finally got around to fixing it.
I created JacksOrBetter back in September 2008, when the App Store had only existed for a couple of months, and the iPhone App Store Gold Rush was on. The news was full of stories of iPhone developers who were making tens of thousands or hundreds of thousands of dollars from simple games. I wanted in on that action.
JacksOrBetter wasn't intended to make me a fortune; it was my first learning-how-to-write-an-iPhone-app exercise. I figured I'd whip it out, learn what I needed to learn to make and sell an iPhone app, and then I'd get to work on the apps I really wanted to write. (Those other apps are still in the conceptual stage, a year and a half later.)
At that time, there were only a few hundred apps in the App Store, and many were little better than JacksOrBetter. I initially charged $1.99 for it, and after a couple of weeks dropped the price to $0.99. I made about $280 over the next few months. Initially I was selling a dozen or so copies per day, but sales eventually fell to only a few per week, so I decided to make it free.
Since then, I've seen a lot of really nice iPhone apps, and I've learned a lot more about how to make them, so I finally decided to sit down and make JacksOrBetter what it should have been.
So now, it has nicer looking cards, a nicer background, and some cool animations of cards being dealt, discarded, and cleared at the end.
It's still pretty simple, but it no longer has that first-app stink.
There are a few more changes I want to make, but I've got this idea for an iPad app...
As an exercise in using the Core Animation API, I've implemented a little iPhone app that reproduces the behavior of the iPhone home screen's icon reorganization interface. (You know, dragging the wiggly icons around.) You can download my sample code to see how it works. Some descriptions of the highlights follow below.
A common problem for iPhone developers is demonstrating the apps they've developed to others. Showing it on an actual device only works well if you are showing it to one or two people. Showing it in the iPhone Simulator running on a Mac takes a lot of setup, and may not work if the app depends on things you can't do in the simulator.
This week, there was a lot of chatter in the blogosphere about the prospect of writing web apps for the iPhone instead of developing native apps.
I hit a little snag while adding a feature to an iPhone app today. I added this code to load a logo to be displayed in a view:
UIImage *logoImage = [UIImage imageNamed:@"Icon.png"];
This worked fine in the iPhone Simulator, so I thought I was done. I loaded the app onto my iPod Touch, and it didn't work. Running in the debugger, I discovered that
logoImage was being set to
Why would this not work on a device, when it ran fine in the simulator?
It turns out that the iPhone OS filesystem is case-sensitive, while the Mac OS X filesystem is not case-sensitive. The actual name of the image file was
icon.png, with a lowercase-i, so it didn't match on iPhone OS.
No big deal, but it's another reminder that you always need to test on an actual device before considering an iPhone development task done.
I've finally got around to doing some work on that iPhone application that I've committed to finishing this month.
On days I do a lot of work on the app, I don't feel obligated to work too hard on the blog, but I will post a little something about whatever I worked on. Today, I got my iPhone app to connect to a Google App Engine-based web site.
Without giving away too much, I'll just say that the iPhone app and the web site work together to provide a service to iPhone users. I put the web site together in a couple of weekends. I decided to use Google Accounts for authentication, meaning that to log into my web site, either via a web browser or via the iPhone app, a user has to provide a Google account ID and password.
If you do things this way, the server-side authentication stuff is easy. However, writing the client side is not easy, because the mechanism for authenticating with a Google account and connecting to a Google App Engine web site is not well documented. Luckily, I found a Stack Overflow question and answer that provided all the clues I needed to get my iPhone app working.
After using Google's API for implementing the web site, I'm growing increasingly frustrated with the Cocoa APIs. What takes two lines of code on the web side takes dozens of lines of code on the client side. Simple operations like connecting to a URL, downloading data, and storing it to a local database requires a lot of boilerplate code on the Cocoa side. It's not difficult, but it's incredibly verbose.
I should note that I'm using the Python API for Google App Engine. If I was using the Java API, then I'm sure it would be as grotesque as the Objective-C stuff.
When you create a table-view-based iPhone app, by default you get tables with plain white rows. But all the cool kids are making apps with 3D-ish gradient backgrounds. You want to make those kinds of apps too, right? This article explains how.