My first app is a simple memory game aimed at pre-reading children. You turn over cards to find letters and must find matches. I think it's time to find a graphic artist for some more beautiful buttons. The game is solid but won't win any beauty contests.
I did some stress testing myself and discovered a logic error in the allocation of letters to tiles that only occurred after the third game. I'm always struck by how much of programming is programming, no matter the platform, and logic errors are logic errors no matter what. Then I experimented with flipping cards as often and as fast as I could. Along the way I discovered some edge-cases where you could flip a card before a matching pair had been registered. I tightened the interaction model to resolve that.
I handed the iPod Touch to my kids for some testing. My seven year old had already figured out how to play it from peering over my shoulder the past few days. My 4.5 year old had it figured out in no time. They were both engaged by the game.
End-user testing did reveal some problems. Both kids inadvertently brush against the tab control on the bottom of the screen which moves between three variants of the game -- matching uppercase letters, matching lower case letters or matching an uppercase letter to its lower case counterpart. Clearly the three variants of the game need to be differentiated somehow to make it obvious that that has happened, e.g. with different colored backgrounds. Or perhaps, in the spirit of iPhone simplicity, I should rethink the three-games-in-one model.
Wednesday, March 4, 2009
Saturday, February 28, 2009
Deploying to the iPhone
It's taken me more than two weeks to get my app on to the iPhone. Most of the delay was bureaucratic, caused by a mix up in my account profile (mixing a New Zealand contact phone number with the US billing address for my card -- ack!). Resolving things took several weeks, faxing notarized copies of passport pages, several phone calls etc.
When I tried to provision my device and build I started getting the error "a valid provisioning profile is required". Various gurus have pages describing the steps you have to take to hack the underlying project files (analogous to manually editing a project file for Visual Studio) to resolve this error. In the end, I just manually deleted the .mobileprovision file that I had downloaded and replaced it, deleted the provisioning information and recreated it.
You have to Provision the device (Window/Organizer, select your device, point it at the .mobileprovision file). Leave the "Applications" section blank for now. (I was confused -- the only compiled app I could navigate to was the x86 version for use in the simulator).
There are many step-by-step guides online. The one gotcha that I would draw your attention to is that you have to specify your code signing identity in two places -- in the Project preferences and by navigating in the left pane of XCode to the Targets section. (Click your application, then control-click and select "Get Info" from the context menu.
Then it's a matter "Build and Go".
Yay, my teach-myself-iPhone-programming app works on the device.
When I tried to provision my device and build I started getting the error "a valid provisioning profile is required". Various gurus have pages describing the steps you have to take to hack the underlying project files (analogous to manually editing a project file for Visual Studio) to resolve this error. In the end, I just manually deleted the .mobileprovision file that I had downloaded and replaced it, deleted the provisioning information and recreated it.
You have to Provision the device (Window/Organizer, select your device, point it at the .mobileprovision file). Leave the "Applications" section blank for now. (I was confused -- the only compiled app I could navigate to was the x86 version for use in the simulator).
There are many step-by-step guides online. The one gotcha that I would draw your attention to is that you have to specify your code signing identity in two places -- in the Project preferences and by navigating in the left pane of XCode to the Targets section. (Click your application, then control-click and select "Get Info" from the context menu.
Then it's a matter "Build and Go".
Yay, my teach-myself-iPhone-programming app works on the device.
Monday, February 16, 2009
IDEs rot the brain
In a previous post I was talking about how Visual Studio is like a comfortable, well-worn pair of jeans so moving to XCode and Interface Builder has been taking some adjustment.
Today's programming.reddit.com has a link to an oldy-but-goody posting from Charles Petzold on the subject of Visual Studio rotting the brain: link. He claims we're addicted to IntelliSense and all those other snazzy features and that the boilerplate code that the IDE churns out for us is a poor example of good programming practices.
Maybe so. My other addiction is Google -- my prosthetic brain. I seldom use the built in help. MSDN might turn up in the results, or not. When I was doing Delphi development I really noticed how many fewer results you would get for basic classes in the framework. Usually the best course of action was to read the source code for the framework classes. As I Google the iPhone API I am struck even more by the paucity of results. I just might have to start reading documentation top to bottom. And scrolling through the list of autocompletions.
Today's programming.reddit.com has a link to an oldy-but-goody posting from Charles Petzold on the subject of Visual Studio rotting the brain: link. He claims we're addicted to IntelliSense and all those other snazzy features and that the boilerplate code that the IDE churns out for us is a poor example of good programming practices.
Maybe so. My other addiction is Google -- my prosthetic brain. I seldom use the built in help. MSDN might turn up in the results, or not. When I was doing Delphi development I really noticed how many fewer results you would get for basic classes in the framework. Usually the best course of action was to read the source code for the framework classes. As I Google the iPhone API I am struck even more by the paucity of results. I just might have to start reading documentation top to bottom. And scrolling through the list of autocompletions.
Saturday, February 14, 2009
Interface Builder
I have been using Visual Studio since the Clinton administration. The Windows Form Designer is like a familiar old pair of jeans. Before that I used Borland's RAD tools. Their form designer is much the same. Interface Builder is...different. Not different in a bad way, just different.
I have been working through Erica Sadun's "The iPhone Developer's Cookbook". The section on using Interface Builder was particularly frustrating. She begins with a blob of code and discusses bolting a UI on it using Interface Builder. This seems exactly backwards -- I usually like to paint something up and then fill in the meaty logic. Beginning with the UI has the added advantage of something that you can show to stakeholders before you begin the heavy lifting.
There are a few screen shots sprinkled through the text but they could do with some annotation. Sadun says things like "Tap the application delegate object in your main XIB window. (It's the one that's not the file's owner or window)." Her screenshot shows three icons, so if you eliminate two you will know which one she means. I see four.
Youtube to the rescue. There are a lot of video introductions to making an app using Interface Builder. Many of them suffer from poor quality that leaves you unable to see exactly what someone clicked on or typed. This one was particularly good:
http://www.youtube.com/watch?v=Tz9mzB2fWhs.
Once you figure out how to wire up UI elements and how to associate events with buttons, it's really pretty nice. Press a button and some code gets generated for you. It's not like Visual Studio, where you get to see all the nitty gritty code that adds components to the forms and registers delegates. Instead we see a total separation of UI (stored in the XIB file) and business logic (in the generated classes).
Interface Builder enforces a strict adherence to the Model-View-Controller pattern. With Visual Studio forms, you will often see people mush together the UI and underlying logic in one awful mess. Interface Builder seems much more rigorous.
Armed with a better understanding after watching some YouTube videos, I managed to wire up Sadun's code to a UI to produce a trivial temperature conversion program.
I have been working through Erica Sadun's "The iPhone Developer's Cookbook". The section on using Interface Builder was particularly frustrating. She begins with a blob of code and discusses bolting a UI on it using Interface Builder. This seems exactly backwards -- I usually like to paint something up and then fill in the meaty logic. Beginning with the UI has the added advantage of something that you can show to stakeholders before you begin the heavy lifting.
There are a few screen shots sprinkled through the text but they could do with some annotation. Sadun says things like "Tap the application delegate object in your main XIB window. (It's the one that's not the file's owner or window)." Her screenshot shows three icons, so if you eliminate two you will know which one she means. I see four.
Youtube to the rescue. There are a lot of video introductions to making an app using Interface Builder. Many of them suffer from poor quality that leaves you unable to see exactly what someone clicked on or typed. This one was particularly good:
http://www.youtube.com/watch?v=Tz9mzB2fWhs.
Once you figure out how to wire up UI elements and how to associate events with buttons, it's really pretty nice. Press a button and some code gets generated for you. It's not like Visual Studio, where you get to see all the nitty gritty code that adds components to the forms and registers delegates. Instead we see a total separation of UI (stored in the XIB file) and business logic (in the generated classes).
Interface Builder enforces a strict adherence to the Model-View-Controller pattern. With Visual Studio forms, you will often see people mush together the UI and underlying logic in one awful mess. Interface Builder seems much more rigorous.
Armed with a better understanding after watching some YouTube videos, I managed to wire up Sadun's code to a UI to produce a trivial temperature conversion program.
Sunday, February 8, 2009
Hello World
I have read some Apple Human Interface Guidelines, a few tutorials on Objective C (which looks nice) and my "The iPhone Devloper's Cookbook" by Erica Sadun. It's time to write "Hello World".
Erica includes a simple example that displays a static image that contains the words "Hello World". I decided to create her example from first principles in XCode by way of exploring the IDE rather than just to open the projects from her site. That all worked fine.
Then I moved on to the next example. A trivial app that displays some flowers on screen that users can drag. I modified the existing Hello World more or less as per her code. It displayed flowers but they weren't draggable. Setting breakpoints showed that the methods associated with dragging weren't being called.
Long story short, I was adding the flowers as children of a UIImageView instead of as children of a UIView. Children of a UIImageView seem not to get the drag messages. This is no doubt in the Completely Obvious (R)(TM) category. Anyway, we're off and racing now.
I think I'll follow my usual approach to learning a new language and framework. I'll spend a week messing with the examples in the book and rereading sections once I have figured out from the online documentation what the book was trying to tell me anyway.
The book is better than many in its genre but it does assume a certain Macintosh development programming background e.g. in discussing the file Info.plist "It works in the same way Info.plist files work on the Mac." Poking around in the IDE, it's not hard to see where the resources live and the analogues of a manifest in Windows.
Erica includes a simple example that displays a static image that contains the words "Hello World". I decided to create her example from first principles in XCode by way of exploring the IDE rather than just to open the projects from her site. That all worked fine.
Then I moved on to the next example. A trivial app that displays some flowers on screen that users can drag. I modified the existing Hello World more or less as per her code. It displayed flowers but they weren't draggable. Setting breakpoints showed that the methods associated with dragging weren't being called.
Long story short, I was adding the flowers as children of a UIImageView instead of as children of a UIView. Children of a UIImageView seem not to get the drag messages. This is no doubt in the Completely Obvious (R)(TM) category. Anyway, we're off and racing now.
I think I'll follow my usual approach to learning a new language and framework. I'll spend a week messing with the examples in the book and rereading sections once I have figured out from the online documentation what the book was trying to tell me anyway.
The book is better than many in its genre but it does assume a certain Macintosh development programming background e.g. in discussing the file Info.plist "It works in the same way Info.plist files work on the Mac." Poking around in the IDE, it's not hard to see where the resources live and the analogues of a manifest in Windows.
Dipping my toes
I have always been a Windows person. It's not an ideological thing. It just turned out that way. Of course, ten years spent at Microsoft did rather tend to reinforce the habit.
Lately I have been thinking that I should dip my toes in the iPhone waters. Sip a different Kool Aid. I downloaded the XCode IDE from Apple and was about to install it when it occurred to me that it might not work on Windows. Phew. One red face narrowly averted.
It's not terribly surprising that you would need a Mac to do iPhone development. After all the dev tools for Windows on mobile platforms all run on Windows.
I spent a little time perusing sites to do with hacking vanilla PCs to run Mac OS but decided that could consume way more time than I really wanted. So I had to buy a Mac.
Buying a Mac turned out to be more difficult than you might imagine in Auckland, a city of more than one million people. None of the stores appear to carry stock of the MacBook that I wanted or stock of iPod Touch of any kind. (Given the insane pricing of iPhones in New Zealand and the apps I am thinking of, an iPod Touch is sufficient). I ended up ordering online and having a machine within 48 hours.
I can see that using a Mac will take a little getting used although I am really only interested in XCode. A good friend, a true Mac aficionado, assures me I will soon be seduced. Maybe so. But I did just buy three copies of Office 2007 and one copy of Visual Studio 2008 to go on some of my home machines.
As with any new machine, the first hour is spent ripping out stuff that I don't care for -- shortcuts to Garage Band, movie making software etc -- and tweaking preferences. Then I have to train myself to use that clover leaf key. And to figure out where PgDn is. Anyway, I am now cutting code. My "Hello World" app runs in the simulator!
Lately I have been thinking that I should dip my toes in the iPhone waters. Sip a different Kool Aid. I downloaded the XCode IDE from Apple and was about to install it when it occurred to me that it might not work on Windows. Phew. One red face narrowly averted.
It's not terribly surprising that you would need a Mac to do iPhone development. After all the dev tools for Windows on mobile platforms all run on Windows.
I spent a little time perusing sites to do with hacking vanilla PCs to run Mac OS but decided that could consume way more time than I really wanted. So I had to buy a Mac.
Buying a Mac turned out to be more difficult than you might imagine in Auckland, a city of more than one million people. None of the stores appear to carry stock of the MacBook that I wanted or stock of iPod Touch of any kind. (Given the insane pricing of iPhones in New Zealand and the apps I am thinking of, an iPod Touch is sufficient). I ended up ordering online and having a machine within 48 hours.
I can see that using a Mac will take a little getting used although I am really only interested in XCode. A good friend, a true Mac aficionado, assures me I will soon be seduced. Maybe so. But I did just buy three copies of Office 2007 and one copy of Visual Studio 2008 to go on some of my home machines.
As with any new machine, the first hour is spent ripping out stuff that I don't care for -- shortcuts to Garage Band, movie making software etc -- and tweaking preferences. Then I have to train myself to use that clover leaf key. And to figure out where PgDn is. Anyway, I am now cutting code. My "Hello World" app runs in the simulator!
Subscribe to:
Posts (Atom)