Saturday, August 6, 2011

Another iPhone Developer Story


Reposted from my old blog on bigroostersoftware.com from March of 2009.

Another iPhone Developer Story

Yes, this is another iPhone developer story.  There are several out there and each of them offer a unique perspective on the entire development process for the iPhone. This is my version, I hope you find it useful.

About Me

I have been developing software for 6 years now. My focus has been mainly the Microsoft stack (C# and ASP.NET). I had a side project in Python and  I have also done a site in Ruby on Rails. Other languages that interest me are LISP, Erlang, LUA, Perl, Javascript, and now Objective-C.  I am originally from Michigan, but now live in Phoenix, AZ.

Computer Setup

I started out by purchasing the 20 inch iMac on January 18th, 2009. I have never owned a mac. The only Apple product I had at this point was an iPod Nano. I purchased a mini DVI adapter and hooked it up to my 24 inch monitor. It isn’t a bad setup, the only thing missing was RAM. The 20 inch iMac only comes with one gig. Newegg sells 4gb (2gb x 2) for around 40 bucks. If you are familiar with the unix or linux command line, you will feel right at home. I still use my PC for gaming, however all my normal activities are now performed on the Mac.

Learning Curve

Doing most things on the Mac is very intuitive. However the new development environment can be a bit overwhelming. I spent my first week downloading the developer videos from Apple. I spent very little time in Xcode, only looking at a few code samples. This helped familiarize myself with all of the new lingo, frameworks, and techniques. I read a few of the Objective-C primers. I love learning new languages, so this was an exciting challenge for me.

Development

After a week of watching videos and learning the lingo, I was ready to get my hands dirty. After thinking of a few game ideas I decided to go with the most simple for obvious reasons. Overall Apple’s documentation on their API’s is excellent. I would say it compares to MSDN, having fewer code samples. You can alt double click a type in XCode and it will bring up the API docs. I love the quick access. My real struggle came from Interface Builder. Apple’s documentation wasn’t that great for it. Google saved me here. I found a good Interface Builder tutorial (here)  and suddenly the entire thing made sense.
My game has some basic animation requirements. I used the quartz framework for this because OpenGL would be overkill. I used GIMP for the graphics, and Garage Band for the audio. A mistake I made was to play system audio in MP3 format. This works fine in the simulator, but I later learned the device doesn’t support it. A quick switch to AIF did the trick, and only required me changing the extension in the API call. I ran the application in Instruments and found a minor memory leak. I had missed calling CFRelease with the C library I was using. Instruments does a really great job telling you what is leaking.

Submitting

There are several things to consider before submitting your application. Don’t make the mistake I made and decide if you are going to sell your application as a company or as an individual. This will give you time to register the company before you apply to Apple’s Developer Program. From other stories I have read, you cannot switch this easily. I decided to go with a company. I came up with Big Rooster Software. Where does this name come from? My grandpa was a chicken farmer and had a business named Best Caged Eggs. If you live in south east Michigan chances are you probably know where his business is. It is the big rooster on M-24 between Lapeer and Oxford.
In Arizona you are not required to register your business name with the state, however it is common practice. I had my trade name application notarized at my local bank, and mailed it to the Secretary of State. Two weeks later the business name was registered. The next step was registering for the Apple Developer Program with the new company name. They require you to fax in proof of your business. Not a big deal, this process took another week. Once you are accepted you can put the application on your phone, and submit to the App Store. As mentioned earlier,  I had one issue with the sound when I copied it to the device. The digital signing required to submit and develop are not as difficult as I had read about. Apple provides pretty clear instructions on what to do with the digital certificates, and how to setup Xcode for this.
Once you setup Xcode to digitally sign your build, you can create a distribution build for the App Store. They require a few screenshots, a description of your application, and the binary compressed as a zip file. My app was now sitting waiting for approval. Surprisingly this process only took several days. The next status I saw surprised me, and was yet another mistake I made. The application was now pending contract approval. To make things worse, I had just read a new article on Reddit that said Apple’s contract department was back logged. Make sure to head to the contracts section of iTunes Connect and fill out the contracts as soon as you are accepted into the Developer Program! This cost me another week!
I purchased my iMac on January 18th and my first application was approved and ready for sale on March 11th. The process is not as bad as I was expecting, and I will know what to expect for my larger projects.

Friday, August 1, 2008

Payment Processor Hits 1.1

I spent some time refactoring more code in Payment Processor (payment-processor). The result is a much more flexible library that developers can extend to meet their own requirements. The library contains a lot of XXInfo classes (where XX is a container category). Example: OrderInfo, ShippingInfo, etc. The old version of the AuthorizeRequest class had a massive constructor that took each XXInfo class. Internally there is a BuildPostString method that calls ToString on each one, which will result in the final POST string that is sent to Authorize.NET. This wasn't very friendly in many ways.

The first problem was usability. The old AuthorizeRequest constructor set was just too big and confusing. Passing in null 5 times looks extremely ugly and was hard to read.

The second issue was the ability to extend the XXInfo classes. There was absolutely no way to extend the POST string if needed and Authorize.NET does allow custom POST strings. So this issue was very critical. A developer can now implement their own XXInfo class by implementing the IInfo interface and passing it into the AuthorizeRequest CTor. It will generate a POST string for Authorize.NET request.

The final problem was the internal code to build the POST string was extremely redundant and very painful on the eyes. The old code for BuildPostString was 50+ lines of code, the new code is roughly 15.

Enjoy 1.10! Feel free to contact me with any questions or comments.

Wednesday, July 9, 2008

Python and C

I don't typically write in C, but lately in my free time at home I have been dabbling in C code. My two favorite dynamic languages are both extensible in C. There have been times my Python code was slow, and I either scrapped the code, or wrote it completely different to avoid the problem entirely. The ability to re-write that method in C would have been handy. This combination gives the quick development time of a dynamic language, and the speed of C. Next time I will be prepared.

Here is a great article for extending ruby in C:
http://www.onlamp.com/pub/a/onlamp/2004/11/18/extending_ruby.html

For Python:
http://docs.python.org/ext/ext.html
and
http://docs.python.org/api/api.html

Monday, June 9, 2008

Finally Moved In

This past month has been very busy. My wife and I just purchased our first home. We moved in on June 2nd, and are finally getting all of the boxes unpacked. I think I under-estimated how much work is involved. With an apartment, you can call your maintenance guy when something goes wrong. Boy am I going to miss those days! I am, however, enjoying the piece and quiet.

Friday, May 30, 2008

PaymentProcessor

I just finished version 1.0 of payment-processor. It is a C# library to communicate with Authorize.NET via their AIM integration. The library has support for ECHECK as well. ARB will be supported in later releases. I am pretty excited about this project. I am using the library in one of our internal applications here at Mission3. We have decided to release the library as open-source under the MIT license. Head over to Google code and check it out!


http://code.google.com/p/payment-processor/