Powered by Squarespace
Development Blog Archive
CIRCUS BLAST

Test your aiming skills! 

Circus Blast -- 3D Puzzle Shooter. You're a monkey. In a circus. Trying to help the other animals escape, with a cannon!

 

 App. is no longer available. 

SUMO TAP

Enter the dohyou to challenge yourself to a fast pace game of Sumo Tap! Play online with friends, using Bluetooth and post your high scores to Twitter.

 

 App is no longer available.

Monday
Apr192010

Ruby on Rails For iPhone

Ruby on Rails has been supported within Xcode since version 2.1, making integrated iPhone app and Rails app co-development a breeze. I took complete advantage of this in our first game, flipNgive, to meet two requirements: fresh content and happy lawyers!

By partitioning the "charity" aspects of our games to the server, we could update information on the charities, add new charities, new contribution goals, etc. All without the need to update the code of the iPhone app. I do this by creating a series of records in Rails for each charity we're supporting, their title, basic information, website, funding goals, etc. We could theoretically support thousands of charities this way, allowing users to dynamically recommend charities and creating a "competition" for funding between the charities if we wanted to. We've instead chosen to manually select three initial charities and entered their information into the Rails database. The initial charities were LIVESTRONG, Planet Cancer and Ryan's Ride Foundation.

But this partitioning also helped with one important legal challenge we had: Apple rejected our iPhone app initially because we explicitly stated that a percentage of our revenue was going to benefit these charities! From Apple's point of view, this could constitute a liability if we didn't do what we claimed. That is, if a user purchased our app expecting us or any company to make a donation to charity and this expectation wasn't met, Apple could be seen as a party to fraud or false advertising. The only way around this was for us to change, and I had to re-write both the iPhone app code and Rails server code to only put "charity" information on web pages served by Rails.

On the iPhone, when you serve web pages, you present the user with what's known as a "UIWebView" which effectively renders raw HTML into nice images on the screen. The amazing thing for me about the iPhone is that this effectively puts an embedded web browser into every app, seamlessly. So seamless, it's hard to know whether apps are showing "embedded" code, or rendering HTML. This screen is embedded:

But this screen is a dynamic HTML page:

Can you tell the difference?

What we wound up doing was to change the embedded code to eliminate the reference to the word "Donate" and then change the HTML code so that it doesn't display within the iPhone app itself but instead forces the user to launch Safari on the iPhone -- this allow the Apple review team to approve the app because there could be no liability for a user viewing a public web site!

Next I'll talk about the techniques behind developing the Rails app, the use of the WebApp framework for Javascript and CSS based display of next generation web applications that look and feel just like native iPhone code.

--yarri