Friday, February 27, 2009

iPhone Journal 0000 1001

My objective today was to begin chapter 8 of Beginning iPhone Development: Exploring the iPhone SDK by Dave Mark and Jeff LaMarche and to meet with Mr. Collias' programming team. The day was more productive than I had anticipated.
In the morning, I learned about the implementation of tables, which are to be found in virtually every iPhone Application. Screenshots of a sample application I altered slightly are provided below.

Later, I spoke to Mr. Collias and Mr. Morelock about the problems I encountered over the course of the week and about what application would be suited for my final project. Mr. Collias explained good programming practices and warned me that I should never lose sight of the final goal of satisfying consumers and fulfilling the project goal in the midst of "fancy" code that is difficult to understand for others. Furthermore, efficiency may be slightly sacrificed for the goal of making code unfocused and capable of solving more than its goal. This allows for reusability when the project is inevitably expanded or when a similar application must be produced. Additionally, he was able to tell me from experience that interface code is constantly changing, but the underlying logic and languages change much more slowly. As a result, logic should be implemented in its own section such that a program may be deployed on a multitude of machines and operating systems by switching out the interface code while maintaining the basic program structure. This is especially important in a corporate environment, when efficiency is greatly reduced if code needs to be completely rewritten and tested due to initial bad programming decisions. Programs should always be planned out, and both Mr. Collias and David Malan, the Harvard professor teaching the CS50 course agree that programs must begin with a basic set of functionality that can be expanded only when it all works properly. Mr. Malan advocates taking "baby steps" to facilitate the debugging process.
In regard to my final project, I suggested both my "Blobs and Globs" application and my "Cingo" board game for porting to the iPhone. The result of a long discussion with Mr. Collias was that "Blobs and Globs" would be an amazing application, but I do not have time to fully complete all of the physical interaction logic between game particles in addition to learning Open GL for drawing and finally coding a sophisticated AI for determining the correct times to maintain defensive versus offensive play. For maximum effectiveness, an AI would have to assess distances between a multitude of particles and evaluate the structure of the particles relative to each other. A two player variant would require learning internet communication protocols. To do this project justice, I will have to work on it during Spring and Summer breaks from school.
It would be more beneficial for me to work on my board game concept which I currently could implement, even though I do not yet have the experience needed to draw moving images on an iPhone screen. Realistically, I will be able to advance to this point and an application of this type has plenty of room for improvement. Updates could include a one player variant against a computer opponent and a polished interface.
I also spoke to Mr. Morelock about some of my less general programming questions. He told me about specific bad programming practices and cited an example of a zip code application that included reading the last four digits of a zip code with code similar to the following:

int fullZipCode = zip; // zip is some number ending with a more specific 4 digit code
int zip4;
int *zipPointer;
zipPointer = &fullZipCode;
zip4 = *(zip + 4);

This code takes advantage of the fact that an integer is stored in memory "on the stack" in one block and reads the last 4 digits from memory directly. In another example, a programmer broke an application by writing to the first memory location, against which pointers are often checked to see if they do not point to anything. Altering memory can be extremely dangerous, which is why newer languages such as C#, .net, and objective-C attempt to prevent such code, which is extremely prone to security flaws.
Mr. Morelock demonstrated how to put Apple's documentation system to good use and was able to explain how objective-C classes can be made to conform to "protocols," the concept of which I had previously found confusing. He suggested that I begin making selective decisions about which chapters to read in my textbook and that I should start working on my final project earlier than what I had intended because from his experience applications usually take twice as long to write as planned. I can certainly verify this; it took me upwards of ten hours to write my checkers application when I had planned to take three. At the end of our meeting, we discussed board game AI, and he mentioned that he works with systems that are based on similar principles. When analyzing a string of text that contains a company name, probabilities of items in the string are assigned based on word location and relative location to prevent a computer from evaluating a location or a department name contained in the string as a company name. The problem is made more complex when the company name is abbreviated or contains a hyphen. For example, hyphens are often used to separate legal department names from company names, and always relying on this can cause a company name to be chopped in half.

For continued progress, I plan to start sketching out the basic specifications of the "Cingo" application and to read about and experiment with graphics functions for drawing the board of the game.

iPhone Journal 0000 1000

Today (2/26/08), I planned to get further in my textbook and to plan part of my final project, for which I had some ideas yesterday.
A few years ago, when I was first examining programming concepts using a graphical programming language, I played a game with a friend in which we each tried to use replicating objects to fill a screen as quickly as possible with as few commands as possible. The result of this evolved into an extremely addicting computer game for two players, "Blobs and Globs." Today, we spoke together about the physics that would be involved in simulating fluid on a tilting plane with friction such that a mobile device such as the iPhone could handle the required calculations of an updated version. The only problems with the game in its current form is that a one player implementation is not as good as would be possible with a language such as objective-C, and movement was possible only with two sets of keys that could not be held down to move characters; the key buffer was essentially of length one.
Using the iPhone and its unique accelerometer controls could improve that game to a very high degree and produce a fun game-playing experience. However, creating this game will likely require me to gain at least a beginner's understanding of OpenGL ES, a low level graphics API. In case I am unable to reach this point by the end of this project, I invented a board game several years ago. It is easy to learn, yet very difficult to master, involving strategies at a similar level as Chess. I could easily create an application for the iPhone that implements this game, "Cingo," in two player form. The problem with this app would be training a computer player to be a challenging opponent. Furthermore, the amount of people interested in board games is sadly much smaller than the amount interested in short addicting games with a simple premise.
Finally, I reached what seems to be the end of the C portion of the CS50 Harvard Lectures and finished chapter 7 in my textbook. While I intended to make progress into chapter 8, the final step of the chapter, which is simply to import the AudioToolbox framework into the project proved to be a painful experience. After adding it and pressing compile, the compiler informed me of 416 errors of the type "Syntax error before...". I tried compiling the version included with the book successfully, but deleting the framework in the provided project and reimporting produced the same error. I searched online extensively, and yet no one seemed to have reached the same error. After multiple application restarts, computer restarts, "Clean all Targets" commands, and a great deal of trial and error, I copied all of the files in my project to a blank project. Upon compiling, I got only 7 errors, which I fixed by adding two #import statements. However, when I launched my application, I got a black screen. At that point, I realized that both the new and old projects were likely irreversibly broken, and I am only glad that I have sample code available that does essentially what my application was intended to.
In the future, I will never make any changes to frameworks without making a project backup first. There is no "undo" option to reverse a process of that nature.
Tomorrow, I will forge ahead in chapter 8 and will get an opportunity to ask questions of Mr.Collias' team of programmers. Maybe they will be able to figure out what went wrong with my chapter 7 project.