Beautiful Pixel

I haven’t posted in forever, but I have good news!

We just released an iPhone app side freelance project I have been poking for the last 9 months or so called Timeless Reminders

It allows you to create multimedia presentations of things that mean something to you, and then schedule that they be sent to yourself at scheduled times. It sounds odd, but it can be very powerful when you get a slideshow of your wife in the middle of the Wednesday afternoon doldrums at work. You should check it out. It’s FREE after all.

I don’t really know what I was think when I designed the flight UI for VOID. Someone once described it as “it likes a clown threw up on my iphone”. Awesome.

Well the good news is that there is an update coming out soon with something far less intrusive and much easier on the eyes. Stay tuned for that and more, soon.

Thanks Apple!

I’ve spent the past 6 months working on an iPhone game. In January I released a lite version of the game, to be followed by the full game a bit later on. Then I update the Lite version to fix bugs and add a feature or two. No problems, no rejections.

Lite version: http://void.beautifulpixel.com/app_store/lite

So I finally finish full game 1.0 and submit to Apple. I’m thinking it should pass approval fine since the Lite version was approved without an issue and the full game is just like the Lite version except bigger.

This morning I get my rejection email. The issue they cite is improper use of a built in control that goes against the HIG (Human Interface Guidelines). That specific thing has some validity, and that is not what I am about to complain about. The problem here is that my app got rejected based on an unchanged feature that was once approved. Timelines, sale dates, and review line ups, they all now need to be pushed back, mostly because Apple didn’t do a thorough enough job the first time.

I don’t think it’s fair to developers for Apple to reject an update based on an issue that exists is previously approved builds of that application. This is actually the second time this has happened. I have a free social app for a small community that had an update rejected because it did not have a graceful failure if there was no internet connection. But this was update 1.4, and that part of the app had not changed since 1.0 launch.

My point, Apple, if you insist on enforcing this level quality control over your apps, then you really need to be thorough and consistent. As an iPhone developer, it just feels like I am trying to hit a moving target. Except it takes a week for my arrow to get from my bow to where I think the target might have been a week ago.

App store submissions are like a box of chocolates: You never know what you’re gonna get.

Coming soon to an iPhone near you…

I created my first iPhone application recently. It’s been an interesting road.

It’s a small app for browsing the chat threads of a specific community, Shacknews.com, which is a gaming news site with a following of interesting people that like to play games.

Memory management, and cryptic stack traces continue to be the biggest issues for me in this whole Objective-C venture. That, and the app store approval process is incredibly frustrating. Updates seem to be taking AT LEAST a week to be approved, which really sucks when you need to fix a critical bug. And recently, I got denied because a new feature in the update didn’t work. Turns out, this was because of a temporary failure in the website that feature connects to that happened to coincide with when they were doing the testing. That was all fixed pretty quickly, but my app is still rejected, and I imagine it will take at least a week for them to respond to my email.

Come on Apple, I know you can do better than this.

iTunes App Store Link

Next up, I’m gonna try to learn some OpenGL and see if I can muster some cool game or something.

I’ve been working on an iPhone application for the community of Shacknews.com. It’s an app that allows access to the comments areas that are attached to the news stories. Simple enough, but I ran into the problem in that the site had no API.

I started to examine the tools I had in the iPhone frameworks to parse html content. It quickly became a chore. Hpricot has spoiled me. So I did what any Rails developer would do: I wrote a small Rails webservice to scrape the HTML, and return organized semantic XML. This stuff was much easier to parse on the iPhone.

I told the community of my progress on the iPhone app, and they were excited. As a minor aside, I also informed them that the API was open for whatever anyone else wanted to do with it.

This is when something magical happened. I didn’t think much would come from the API, other than me being able to use it for the iPhone app. But almost overnight, there were a multiple projects being cooked up by some tech savvy members. Very quickly they began to release their work. Suddenly it felt like a mini renaissance as the community interaction began to spread like a virus into new domains. Suddenly, you can post from the beach with ease, or report the score of a sports game to your buddies from your seat in the bleachers. Or you can post from work via a command line terminal that doesn’t look like your wasting time posting about video games as your boss walks by.

When you have an API, you give the community a way to improve your offering for you. And the best thing is, people do it for FREE, because they want to. You can pay some developer to make an iPhone app for you, or you can have an API and let someone else decide to do it for free. Overall, community participation is up, because people can do it easier, and in more situations. As a result, you get more traffic, and more importantly, more user activity in your site.

There are lots of smart people out there. Give them the chance to make cool stuff for you, and if they are passionate about your site, they will. And you will reap the benefits.

After a week or so of the API being available, this is list of ways you can now participate in the community beyond a computer based web browser.

(List compiled by a community member)

LatestChatty.app

• Best UI and features

• iPhone only

LatestChatty Command Line App

For Windows 3.11 and later, a command line interface. This is probably the most impressive, to be honest.

• 36K!
• Work safe!

• Code will probably make your head hurt when he releases it
• Probably not going to display images any time soon

LatestChatty for Windows Mobile

Why does the iPhone get to have all the mobile fun?

• Makes Windows Mobile slightly less embarrassing to own

• Fairly feature light at this point – color-coding of tagged posts would be nice
• Navigation is not the best

2 mobile optimized web apps for mobile browsers

Why does the iPhone get to have all the mobile fun?

• Nothing to install
• Works broadly on small screen sizes

• Less powerful UI and features than a native mobile app.

I’m still trying to learn Objective-C and Cocoa here, and coming from Ruby, its an interesting experience.

Method calling Syntax

I simultaneously love and hate the method calling syntax. Take this for example:

[UIColor colorWithRed:1.0 green:1.0 blue:1.0];

This create an instance of the UIColor class with red green and blue values as specified, in this case white. I do like that the parameters are labeled, and I like that better than simply passing in a list of anonymous argument that most languages give you.

But what I don’t like is the method name being forced to mingle with the arguments. Semantically, red, green, and blue are all equal things. However I am forced to prepend the declaration of the red value with this colorWith prefix. The named parameters actually are the method name. According to the langauge internals, the name of this method is:

colorWithRed:green:blue:

Here’s how I might do the same thing in ruby:

UIColor.new(1.0, 1.0, 1.0)

Although, this requires some formal knowledge that the order of arguments is red, then green, then blue. But I can easily remember this since its a basic language feature.

Usually I don’t mind long method names, but when handling things as simple as initialization, it seems like I should have to look up the syntax. Long ruby method names aren’t too much of a problem, because they only have one part. Objective-C methods tend to be more verbose, and its hard to know where the arguments go and what type the arguments are supposed to be.

The result is that I can’t possibly imagine writing Objective-C without a code completing IDE. I have written huge amounts of ruby in Textmate, and really don’t miss code completion much. Maybe I just have to get used to the IDE mindset.

Objects and non-Objects

Ruby has spoiled me. Everything is an object in ruby. A string, a number, a chunk of code, everything. Even a class is an instance of the class Class.

In Objective-C the story is different. An object is an instance of a class that inherits from the NSObject class. Basically this means that the only things that are objects are things that are provided by Cocoa. Other things that are provided by the underlying C, like floats, strings and whatnot are not objects. Although, to be fair, Cocoa provides object based wrappers for most of the C non object primitives, but its not always worth the overhead to use them for simple stuff.

This makes the syntax a bit of a mess. The bracket method calling syntax only works on objects, because a non object (I dont even know what to call it) cant have methods at all. And then you have calls to C functions like:

UIGetCurrentGraphicsContext()

Which doesn’t even use the bracket syntax at all. I’m sure I will get used to all this, but I can’t help but feel this language would be a lot more fun if everything was an object. I think most people go from something like C to ruby, but I am going the other way around, and it’s odd. We’ll see where this goes.

With the release of the iPhone SDK, it’s clear that I need to learn some Objective C. I have been meaning to pick it up for a while now, if only to write Mac OS X Desktop Apps. But coming from Ruby, and not knowing C, its a little weird. I have a brain dump of initial thoughts as I trudge through my learning process that I will document here.

First of all, memory management? Ruby has way spoiled me here. Having to manually allocate and deallocate memory manually seems like a huge pain the ass. But on the other hand, maybe that is one reason that Rails apps take need 50MB of RAM just to be present.

The bracket method invocation syntax is pretty weird to me. As is the method declaration syntax. I’m getting used to it, I am starting to see why it’s done that way. But its still ugly.

1
2
3
4
5

// method declaration
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {

// method invocation
[myObject touchesBegan:someTouches withEvent:someEvent]

The “every argument is named” thing, is actually pretty nice. But the syntax to hook all that up, and strongly type every argument, is pretty ugly.

Lastly, for now, the language just seems needlessly verbose. For example, to create a new Photo:

photo1 = [[Photo alloc] init];

I much prefer ruby’s Photo.new. Or to get objects out of an NSArray object you actually have to do something like:

[myArray objectAtIndex:123]

Learning a new language is a great mind expanding exercise. But I hope to, one day, learn a language that didn’t make me wish I was using ruby instead.