Posts Tagged iPhone

Book Review: Tapworthy

Posted by rad in Reviews, iPhone on August 2, 2010

Tapworthy
Tapworthy
Designing Great iPhone Apps
by Josh Clark
Publisher: O’Reilly Media
Released: June 2010
320 pages

I’m a programmer who occasionally dabbles in user interface design when I’m doing solo projects. I know enough to know when a UI is bad or good, but I’m at a loss on how to create good UI from scratch. On my iPhone games, I do my own UI. There’s the iPhone Human Interface Guide, but I feel that it’s a bit hard to digest and I feel that it’s too specific to non-gaming applications.

Tapworthy takes iPhone HIG then mixes it with insights from recent user interface research and human psychology. The result is a very readable guide with specific do’s and don’ts to follow in designing your iPhone app interface. The tips, along with the long but readable discussion on the principles behind those tips, are general enough that even game developers will find them useful.

For example, the recommended hit region for user interface elements should be 44×44 pixels. This is a very important principle to follow (n00b mistake: on an app I was developing, I started with swipeable coins that are 20×20. Not surprisingly, on my first user tests, the users found the coins too small and very hard to swipe). The iPhone HIG actually mentions this, but this tip is buried in there and is only mentioned three times. In Tapworthy, this tip has its own section title (“The Magic Number is 44″) and is mentioned more than a dozen times to really drill in the point.

Another solid tip from the book: Do not use text in designing the app’s icon. It won’t be readable, and it will just add visual clutter to the icon. This tip is actually part of an entire 30-page chapter (Chapter 7) devoted to App Icon Design.

I can’t find anything that I don’t like about this book. It can use some improvements, though:

  • Given that roughly half of iPhone apps are games, it could add more tips specific to gaming applications. Maybe games aren’t in the author’s repertoire, and that’s a topic for another book.
  • The book contains lots of internal references, e.g. “…a concept explained in the Facebook case study on page 236…”. On the PDF version, the references aren’t links, though. What’s more, on the ePub version, when reading it on Stanza for the iPhone, the links are meaningless because the ePub pages on Stanza doesn’t really match the PDF’s page numbers. This isn’t major, though, and it’s something O’Reilly can easily fix with an updated digital release.

If I have to describe this book in a nutshell, I’ll say it’s Alan Cooper’s About Face, translated to the iPhone world. Great work.

, ,

No Comments

Corona SDK

Posted by rad in Game Development, Programming, iPhone on June 16, 2010

It seems I can develop some games much, much faster with the Corona SDK. It will cost me $99, and it’s not as macho as mastering Objective-C, but I think I’ll end up saving hundreds of hours with this kit.

I think Corona is a great kit for writing games in general, especially arcade games and board games. There’s no built-in support yet for tiled maps, and it looks like Cocos2D will have that built-in first. But even with that disadvantage, developing on Lua is so much more productive than developing on Objective-C that I’ll still come out ahead.

Some apps aren’t a good fit, though:

  • those that extensively use the CocoaTouch UI controls. In Corona, you have to create your own buttons, text fields, etc. There’s the ui library, but it only covers a few controls.
  • those that access APIs that aren’t wrapped yet by Corona. For example, access to the address book seems to be missing.

There’s the worry that Corona SDK will violate section 3.3.1. Folks from Corona gave some reassuring messages, but of course, with Apple, you can’t have absolute uncertainty. My take is that even if Apple gives Corona the boot, Corona will become Android-only, and Corona SDK is worth $99 even as an Android

I’m taking the $99 plunge. If nothing else, I think Lua will give me a refreshing break from my day-to-day Ruby and Javascript coding.

, ,

No Comments

iPhone SDK TOS 3.3.1: One Month later

Posted by rad in Game Development, iPhone on May 8, 2010

If you’ve been living in a cave, “3.3.1″ refers to section 3.3.1 of the iPhone Developer Program License Agreement. Section 3.3.1 for the iPhone 4.0SDK beta reads:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

It’s been about a month since 3.3.1 came out. The most obvious impact of this is on Adobe Flash CS5. Prior to 3.3.1, Adobe has announced that Flash CS5 will include a Flash-to-iPhone compiler. Now, Adobe has cancelled that feature.

Here’s a roundup of how the other iPhone development tool providers have reacted to 3.3.1. Except for funkaster, writer of shinycocos, most of them seem to be optimistic that they’re in the clear.

AnscaMobile (Corona SDK):
http://blog.anscamobile.com/2010/04/corona-and-iphone-os-4-0/

Torque (iTorque):
http://www.torquepowered.com/community/blogs/view/19715

Unity:
http://blogs.unity3d.com/2010/04/10/unity-and-the-iphone-os-4-0/

funkaster (shinycocos):
http://github.com/funkaster/shinycocos/commit/9ebda7fcfc853db266b4b49c01bdbc5fa5a9be42#comments
(see the comments below the git commit)

Rhomobile:
http://rhomobile.com/2010/04/09/iphone-4-0-sdk-rules/

Me? I’ll stick to learning plain XCode, Objective-C, plus the Cocos2d Library.

,

1 Comment

CS193P Study Group: Session 2

Posted by rad in Programming, iPhone on February 19, 2010

Session 2 was conducted on the same venue as, and right after the PhRUG meetup.

Attendees:
topher
rad
eumir
buddy
tin
nico

There were two new attendees, tin and nico, who promised to catch up with the previous assignments.

We discussed memory management. The following questions were raised:



When should you call release on an object?

When you’re the one who did the alloc for the object.



When should you not call release?

When you did not do the alloc for the object.



Why bother with alloc and init at all, when, for example, you can use class methods that do it for you?
For example, why use:

NSString *my_string = [[NSString alloc] initWithFormat:@"format"];

when you can instead the format below?

NSString *my_string = [NSString stringWithFormat:@"format"];

Answer: The stringWithFormat call returns an autoreleased object. On the Mac OS X desktop, there’re practically no difference. On the iPhone, you want to limit the number of objects in the autorelease pool and use alloc/init most of the time so that you can be explicit (and optimize) on when you call release.



As before, let’s try to do Week 3 in one week. That means lectures 5 (Views, Animation, OpenGL) and 6 (View Controllers), and assignment 3 (HelloPoly II). Let’s aim to view the lectures and finish the assignment by next week and have a meetup Thursday next week, February 25.

For those that are catching up and still working on previous assignments, feel free to post questions about them, both on the forum and on meetups.

,

No Comments

Learning iPhone Game Programming

Posted by rad in Game Development, Programming, iPhone on December 29, 2009

Recently I decided to join the Get Rich By Selling an iPhone Game bandwagon. I had several things going against me. First, I’m starting from scratch when it comes to Objective-C and Cocoa. Second, this is completely unrelated to my current work, so I will not be able to port any know-how I gain from work into this new endeavor. Lastly, I still have to maintain my full-time job, and my family obligations, so this will at best get 5-10 hours a week of attention.

After several months of pursuing this inconsistently, my efforts have paid off and I finally am at point where my confidence in building an iPhone game is at about the same level as my confidence in building a web site on Ruby on Rails (my full-time job). I haven’t released a game yet, but I think I’m finally over the steep part of the learning curve.

If you’re planning to embark on a similar journey, here’s some advice:

1. Enroll on an iPhone programming course

I didn’t, but if one was available locally when I was learning, I would have seriously considered it. What I discovered during my learning process was that spending just one to two hours per session (the most I can spare in a day, given my full-time job and family obligations) for learning a completely new language and framework was very unproductive. I got stuck on most of those sessions, then I spent a considerable portion of the next session retracing my steps and figuring out where I stopped during the previous session. I made the most progress when I took a leave for several days from the my full-time job to concentrate on my studies.

Here are the bootcamps I recommend:

Alternatively, you can follow the Stanford CS193P iPhone Application Development class. Video transcripts of the lectures are freely available in iTunesU. The assignments are great, IMHO even better than the iPhone books. I’ve been looking for the Objective-C equivalent of the K&R book, and the lectures and the assignments come closest to it.

2. Go through these books, in order

If you follow the Stanford CS193P class, you will find these books very useful. The Apple reference docs are your, well, references. The Beginning iPhone book and the Developer’s Cookbook will be helpful if you find some concepts aren’t adequately explained in the lectures or in the reference materials.

3. Get an actual iPhone or at least an iPod Touch

Theoretically it’s possible to build and release an app by just using the simulator, but it’s not recommended. Here’s why:

  • You cannot test multi-touch and the accelerometer using the simulator
  • You need to be an actual iPhone OS user to be able to understand the UI expectations of your users. You need to actually use an iPhone or an iPod to be able to appreciate much of what’s written in iPhone Human Interface Guidelines
  • Apps, especially games, will be much slower on an actual device than on the simulator. You need to verify that your app won’t be sluggish on an actual device

4. Start with a framework

I recommend the cocos2d-iphone framework and the chipmunk physics engine. Both are free and are supported by a healthy community. They may not be the best, but they’re accessible and are enough to get you started.

5. Lastly, always remember to have fun!

That’s what this is all about, right?

2 Comments