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.
