So I’ve been writing a lot of code the past few months :). Some are just small apps that I wrote to learn iPhone coding. Others are hacks that I’ve been using for a while in various projects. A lot of it is just sitting on my computer taking up space. I thought it would be neat if I just open-sourced it and let everybody play (and maybe learn something in the process).

I’ve been slowly cleaning up recent projects and putting them up on github for everyone to download. Right now, you’ll find Emojicon (a hack to get the Emoji keyboard on your iPhone), Pickture (a HOWTO app I wrote for Dennis’ class back in the Fall) and Round Robin (a small experiment/game we ran at MobileCamp a few months ago).

There’s a whole folder of this kind of stuff on my Desktop — I think I’m going to slowly start sharing it all.

Last week, Emoji on the iPhone was all the rage with some people in my circle of friends (/followers). By default, usage of the Emoji keyboard is only available on iPhones purchased and used in Japan. However, some hacks exist that can allow your non-Japanese iPhone to access the Emoji keyboard. The first version of the hack requires that you jailbreak your phone (too complicated for most); the second requires loading of special Vcards into your address book (messy); the last method is to download an app from the App Store that enables this setting on the handset (easy, but for a small price).

We were talking about these different methods a few days ago and found the easiest way to enable this was to use the App Store method. There are a few apps currently in the store that can do the trick but I wanted to build my own for three reasons:

1. I was interested to see how quickly I could build such an application. It didn’t take long to code.
2. I thought the price of $4.99 for such an app was too much; and I was curious to see if I could get a similar app approved for much lower.
3. I wondered whether the App Store would actually let me submit an application that changes a low-level user preference (outside the application “sandbox”, as Apple describes it).

I submitted my application (Emojicon) five days ago. Earlier today, I got news that it was rejected. Hah! I half-expected it. The best case I could have hoped for would have been that the App Store accepted it, but then rendered it useless by enabling it in a future iPhone update. The reason given for the rejection:

“An Application may write data on a device only to the Application’s designated container area, except as otherwise specified by Apple. [...] For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application’s “sandbox.” The sandbox is a set of fine-grained controls limiting an application’s access to files, preferences, network resources, hardware, and so on.” [Taken from the iPhone OS Programming Guide].

It was a good experiment: I got to challenge myself on how quickly I could go from idea to submitted app. And I got to test the acceptance process - particularly when working with shared preferences.

The question I have now though: How did the other Emoji-enabling apps make it into the App Store? :)

Emojicon is open-source (all four lines of code - ha!). Get it at /code/emojicon.

I recently guest-lectured Dennis/Michael’s Designing Around Place class. I mostly talked to the kids about iPhone development — with some primer material on OO, MVC, etc. We wrote a lot of sample code in class (most of it got deleted shortly after class ended. wah!). Then I got to thinking that others might find this code useful too especially because there’s not much open iPhone code out yet (and almost _none_ in small bite-size chunks that beginners can use as a start). So I’m trying to package a few examples together into small working apps. The first of these apps is something I called “Pickture“. It will allow you to get an image from either your photo gallery or from the camera.

Charlie and I were talking about Socialight’s open source client and one good point he made really stood out: How do you create a groundswell out of this? How do you get others to do the same? He said it felt too much like “here’s what we’re doing” instead of “here’s what everyone should do”. The latter idea is exactly the point I was going for but I don’t think my language was right. I probably got distracted by the excitement of being published again (like in grad school). So, some amendments are in order.

Why should everyone do this?

For starters, if there had been a similar open and well-documented client in the marketplace, we wouldn’t have had to spend two months of hard work recreating our own application. This had to have been one of the most frustrating things we went through. There were so many other features to work on but we were devoting nearly all our time on simple client-side interface details. We know other mobile developers have the same difficulty in developing interfaces but have done very little to share their work. We hope to lead by example.

This is not a new concept, really

We’ve already seen numerous examples of how openness and sharing can lead to better products and faster development cycles. Consider the work that’s been put into Rails. The platform not only provides an underlying development framework, but also makes available numerous plugins and sample code to make your job easier. If we have something similar in the mobile world, we’ll have a much easier time creating the products we love and want to build. We’ll spend less time worrying about the underlying principles behind something like GUI buffering code (which is not something every mobile developer needs to know).

Open for you…and you and you and you

More than anything, this code means more openness and should mean more to developers and others in the industry that it does for Socialight itself. If the app were closed, Socialight would still need a client and we would continue to develop it closed for our needs. However - if the app were open, Socialight would get the same benefit of having a client but now other developers will have something to touch and use. Both external developers and Socialight win in this situation because by having it open, both parties benefit from future improvements.

So where does that leave us

Open code is not a unique thing - it’s been around for as long as software itself. I think the difference here is open startup code. We’re all in the same small developer boat - especially in mobile. I think we can really help each other out even more if we all did this. I hope to leave you this time not only with a “so here’s what I did” but rather “here’s the start of something bigger”. Here are the first bits of what we’re going to do.

I guess the one thing I didn’t do in my last writeup was to make a call for action. So here it is. The game’s started - knight to f3. Your move.

I’ve released Socialight’s mobile client as open-source software. There are a few reasons why this is a Big deal with a capital ‘B’:

A. The Java mobile world has been around for at least ten years now but doesn’t have the same excitement around development as Android and iPhone have managed to get in the last year. From a developer’s standpoint, this is mainly due to ease-of-use. J2ME still does not have a reliable base from which to build GUI systems. This means that everything has to be coded from scratch. This includes interface elements such as lists, buttons, scrolling and word wrapping. Android and iPhone come with these toolkits. No longer do developers have to waste half their waking hours putting together text-coloring code. The code base I’ve put together has some of this basic functionality: Yes, Virginia, there is a scrollbar. [1] I’m no wizard at GUI development in Java, but the code is open and is waiting to be improved and reused.

B. Big companies (unless they are heavily software focused) usually will not allow you to release your work into the community. You could be a great developer and could have stumbled upon something big, but the chances are great that it will remain locked up. Actually, the chances are high that another really smart developer somewhere else has also done the same thing. Now you have two silo-ed solutions to the same problem. Imagine how much further you could’ve taken the solution if only these two people were able to collaborate and share thinking.

C. These days, there are a lot of startups doing mobile development. You might think, “ok great, these good hackers are no longer constrained by a big company telling them what to do with their code.” However, still many of these small companies are usually hesitant to release code they’ve work so hard to build. [2] These teams have poured lots of money into a solid development team. Their work is great but they do not want their competitors taking advantage of the time and effort they put into it. This means that there is a lot of well-designed mobile software in the marketplace, but every development group still codes their own stack of toolkits.

D. This is the most significant piece of open software that has my name on it. It’s a little like baking a cake and giving it and the recipe to your friends. Those that can appreciate good taste will look at, eat and comment on the cake itself. Friends that are cooks will not only taste it but will pore through the recipe and will be sure to point out both the good and the bad.

So there you have it. If you are the hacker-type, get the code and play with it. Let me know your thoughts.

Notes:

1. Yes, I realize some UI frameworks exist. TWUIK has some great elements but the cost turns away a startup or an individual developer. J2ME Polish is open and is a nice idea but I don’t like that you have to embed CSS code inside your Java code. Whatever happened to separation of content and presentation?

2. Of course, recently, this trend seems to be changing. Twitter recently released their backend queue server, Starling. Imity’s proximity client is also open.