Tuesday August 31, 2010

Design and Data Structures

On Tuesday afternoon we started our 3rd paper for the semester, Design and Data Structures. In this paper we are introduced to iPhone application development using XCode, Objective-C and Cocoa Touch. These are all keywords that I jumbled up a bit when I started exploring it myself a couple of months ago, but now it's all clear what the difference is. Objective-C is the language, based on C (as one could guess). Cocoa is the framework that you can draw from when making applications for OSX. It contains libraries and UI elements that you can reference in your code. Cocoa Touch is the same thing but it's the iPhone/iPad framework and it's UI elements. XCode is simply a development environment supplied to make your applications in. It's the Complier, and a separate program called Interface Builder where you can drag & drop UI elements to build your interface. So, a couple of months ago I might have said to anyone who would listen (er, which is no one really) "I'm going to try to learn XCode" meaning I was going to learn iPhone app development, I sort of sounded like someone saying "I'm going to learn Dreamweaver" when they really meant they wanted to learn HTML and web development. *sigh* when did I become the kind of person who finds that mildly amusing...

We have a guest tutor, a man who has built an iPhone app and published to the App Store. Tuesday was theoretical, we were introduced to some concepts on the Objective-C language, but much of it would have gone over people's heads, although hopefully enough retained so that it reveals itself when it's nature is understood.

Wednesday and Thursday were much the same, the concepts were... well conceptual. We were given a handout on Wednesday, if we followed it we'd have an iPhone app that didn't really do much but had graphical elements that responded to touch. I took that home and worked on it but didn't get it finished due to some interruptions at home, and then I got to a point where the stupid thing would crash on startup with no explanation. Debugging was a bit difficult as I didn't really understand the code so I just listened to the Tutorials. We received our first assignment for this paper, worth 30% of the total, to build a stopwatch application. The basic application had been built but was missing critical parts that we had to add. I decided to duck out and find a book shop that had a book on Objective-C. Nowhere in town had anything, and if they had have I'd probably have been charged some ridiculous price, in NZ we seem to be ripped off with the price of text books. I also went to the AUT library twice, the first time I found nothing, the second time I decided to loosen my criteria as I was getting desperate and this time found 2 great books, although not on Objective-C.

The first one, Learn C on the Mac is around 300 pages and easy to read. The second one I was very happy to find, C Programming Language (2nd Edition) - written by the creators of C and regarded as the THE book on C. C is a good primer for Objective-C as Objective-C is an object-oriented superset of C and you can write C code in Xcode and it will compile and work. I have an Objective-C book lined up, Auckland Public Library has the follow-on book to Learn Objective-C on the Mac. On Friday we were to work on our Stopwatch, so I stayed home and read the first book.

    Sunday September 19, 2010


Due to the way my weekend went (I should point out this is not a euphemism for "I partied all weekend" but usually "My time was a commodity for other people") I really only got to work on my stopwatch the morning that it was to be handed in. This didn't bother me too much, I'd been reading a book on C. Although this is Objective-C, I felt I should be able to wing it and get it out of the way so I can continue my self-learning. I actually did surprisingly well with it. I modified it's functions and buttons and UI. I'd really have liked time to dress it up a lot more but it was functional and not ugly and I made 2 versions, because I decided to put a twist on the application. We have a holiday coming up and I can use that time to get good with C, Objective-C and iPhone app development. I need to come out of that break with a completed iPhone app worth 70%.

The rest of the week was turning up to tutorials on how to do various things with iPhones like switching views and hooking up to databases. However I felt like I was sitting in a Computer Science class that's been learning C for 6 months and started on Objective-C a month ago. Without the groundwork, it was mostly lost on me.

I continued to read Learn C on the Mac and flipped though the K&R which interests me more but I think a tutorial-type walk through dummies type book would be more applicable for someone under serious time constraints.

Friday afternoon we had to hand in our abstract for the Essay that we are to write. Given that the groundwork - my Literature Review - was so appalling, I found it a bit difficult. I'd really like to re-write it. But that wont be happening, not enough time, or really enough enthusiasm either.

    Sunday September 19, 2010


I've had the last 2 weeks "off". Every single day though was dedicated to developing this application worth 70%. I found it annoying actually. 2 weeks work on something that would pass an entire paper and 2 weeks was enough to barely prepare for it. I have some understanding of programming and yet I could not understand what we had learnt. - Objective-C's syntax is odd. C was easier to understand. If I'd been given a month to learn C and a month to learn Objective-C, I could have decided to build an application and gone and built it without much fuss.

I spent my first week reading Learn C on the Mac. I had meant to finish it by that weekend and start-and-finish the K&R within the week too and have made headway into some Objective-C material. That is a ridiculous goal really. Absorbing and understanding such dry material in a time limit and battling the inevitable attention wandering as you read all about the joys of pointers. By about Friday in the first week I decided it was time to start building the interface of my application. I used one of the tutorials from earlier in the week to build it and connect it via code, sort of making sense of things. But there were so many unanswered questions about the processes behind this very visual way of building an application and how it connects with the code.

I had settled on making an iPhone version of Simon, the game from the 80s.

Original Simon

I was weary about it at first as I thought it might be a bit simple or lack navigation to other views. I couldn't help myself and googled to see if any Simon iPhone apps already existed, and yes they did. I then looked through the iTunes store and yep, there were a quite few. I had been worried that looking at them might influence my design. But I wasn't that impressed with the apps that already existed and I was able to check some comments by users about what they liked and didn't like. This made me realise that while the game is basic, it's very customisable. I could have an options screen. Those options could be saved as user preferences.

I started to make decent progress over the weekend, and I started polishing up the UI with Photoshopped buttons and a textured background.

I had an idea of how one would code the basic game but googled for a JavaScript version so I could analyse that and take anything from it. I found an example and they had built it kind of the way I'd have done it. Well, the beginning part anyway I never got past reviewing the initial set up of the game before I was knee-deep in my own code that I was comfortable with continuing on.

I had a few ideas though: I wanted to give 2 options to game play. Standard is where Simon plays a sequence, progressively adding another step as the game continues. I called this "Advance". The other way was harder, called "Scramble". Each time the user won a round another step would be added, but the sequence would be entirely different.

Another option was an 8-tile game.

Other options added to the options screen was setting the tempo of the game, the timer before you lost, and how many steps in the game was to start. I also originally added volume but slowly got the idea that such a control is somewhat redundant. I think it would have been hard to implement anyway.

I had some major issues that seemed insurmountable. I had a function that plays a tile according to the value of a particular variable handed to it from another part of the program. The other part of the program is a loop that iterates as many times as the game has progressed. The first time I implemented it, it did what I expected it to do, which was play everything too fast - just about instantaneous. My solution was to add a delay, so I googled how one would do that. The standard way(s) unfortunately halted UI updates so the tiles did not light up until the entire sequence had played. Other methods of implementing it confused me, it seemed that the for loop that called that function didn't wait for the function to say it had finished and it could be called multiple times at the same time. Basically a lot of stuffing around was done until I finally gave up and implemented a timer that everything in the application runs in sync to.

Every step in this was difficult because I didn't (and still don't really) understand the syntax, or how and when pointers are implemented, memory management (of which there is quite a bit on the iPhone) so my application leaks like a siv I'm pretty sure.

That said I did manage to get the game running, the tiles lighting up, sounds playing (Which I sampled from a rock organĀ  posted online, the notes are A, D, G, A like the original), play sequences and then waiting (for a limited time) for the user to reply. It has 99 levels (the original has 68 apparently), you can pause the game at any time, mute it (someone wanted that as a feature on a different Simon iPhone game) and atm there is a quit button which is apparently against Apple interface guidelines... Though the home button doesn't quit the game properly. I could replace it with a new game button but then I wonder why anyone would want such a feature... It originally had a new game button beside the quit button but I took it out for that reason. If only I could afford a real iPhone or iPod Touch to get familiar with. Trying to design a HIG-compliment interface when I've only spend about 10 minutes using one is a bit difficult.

I couldn't get the options view to come up until last night (Saturday). This is something I've spend hours mucking around with much like the timer/sync issues. Now I have it poping up I don't really have time to get it to change settings or learn how to save settings. And passing variables between screens isn't straightforward it turns out too.

Simon main screen Simon options screen

I think it will pass me through but I don't think I'll get an A. This annoys me as I don't really think it is possible to get an A, looking at the requirements verses our knowledge. I'll be interested to see what everyone else comes up with.

I have found some really good books on Objective-C and I still have to read the K&R. With this project out of the way I will dedicate some time to it with the view of understanding iPhone/iPad and to a (much) smaller degree Mac/PC application development by the end of the year. I think there is real money in this platform and this will be fulfilling the idea I had early on about this course: It has the potential to pay for itself while studying because the skills it teaches are so current. If I can use what I learn as I go, then doing postgrad is much more likely. Given that there is a certain devaluation in education because there is more of it, I think it's important to not stop at degree level. Not that I ever intend to be a worker Bee making someone else rich ever again. I quite like the idea of multiple (and hopefully passive eventually) income streams that I generate for myself.