Lessons learned from IPod Development

A timeline with a new library and language

Learning a language like Objective-C and the iPhone SDK is very time consuming. Doing this at the same time where a professor is expecting you to produce a vague product (read: no concrete requirements), and expect to be confused. That's not to say it wasn't a very effective learning experience.

Challenges

Learning a library and developing a product at the same time is not an efficient process. Your designs are colored by your understanding of the previous libraries and languages you have worked with--not the current one you need to develop with.

This boils down into two categories of challenges:

Identifying constraints

What can the library not do? Is there functionality from other libraries I would use and isn't available from the current library? What alternatives are there with the library I'm using now?

Identifying capabilities

What things can the library make easier for me? These are much harder to discover as they lurk in hundreds of html docs or deep in information-light tutorials. Ofter there are constraints which are only imaginary because the library offers the functionality you want, you just don't know about it yet.

Inaccurate (Imaginary) Constraints and Capabilities

Working in an unfamiliar language with an unfamiliar library easily lends itself to inaccurate assessments of the tool's constraints or capabilities. There might not even be an analogous construct, such as moving from Python to C and expecting duck typing. The tool might offer new constructs to use such as going from C++ to Ruby and not knowing about mixins, an example of inaccurate constraints.

Since the cost of changes in software grows exponentially as the project progresses, continuing under flawed assumptions of constraints and capabilities often makes it cheaper in time and effort to redesign and rebuild from scratch.

Conclusions

Know when to start over and redesign

This is may be the more painful of the two lessons. Abandoning a program and retooling it from scratch is a hard prospect when facing approaching deadlines. This can be important to realize during design and further emphasize the need for clearly defined subsystems and packages and components with minimal interdependencies as a levee against cascading changes in a redesign.

Abstractions and a levelizable design will act as firebreaks when you rip out part of the system after finding several capabilities you didn't know the library had.

Writing for a new library is liberating when you expect to throw your code away, but don't get careless. Rewriting something is a lot easier when it is hidden behind an abstraction and the fewer dependencies on a component means less code to change if that component gets modified significantly.

Rewrite may not mean "full rewrite" if you watch and reduce the number of places you're depending on that new library. Of course you're sunk if the new tool is a new language.

Learn your environment

Learning about the environment is especially important if you are to make a product out of it quickly from management. You should treat the task of learning about your environment as requirements analysis for the NEXT iteration of th eprogram. This goes back to the previous conclusion, that you should expect to do a redesign.

Trying out things in a test (or sandbox, whatever term you prefer) is especially important to learn how to apply new concepts in the domain. Using a separate project for this work is key so you don't screw up prototype code with experimentation. To a certain extent the current prototype is experimentation code, but it is something to show your boss and should be treated as production-level code.

The faster you learn the capabilities of the new tool, the fewer redesigns you will need to do because of a lack of understanding about the project's domain. As your progress there will be less work needed to identify constraints and capabilities of the new tool. It is suggested that you spend much more time in the beginning doing many small sandbox projects to learn about various aspects of the environment, before you begin any project level code.

More work on the front end of the project in sandbox work means less program guts to destroy and better assumptions when work starts on the real program. If a task is annoying or common to deal with, you might be operating under undiscovered capabilities of the tool.

I finished the iPhone tutorial for the second time yesterday. I completed it as the first thing that I wanted to do, just to learn how to get code setup on the iPod touch, and then went to reading documentation. After doing a lot of reading, going back and doing the first tutorial again helped significantly. The first run was making sure I could get the example working, while the second immersion was to explore the different concepts more in-depth. Reading the Objective-C language documentation last night clarified many of the language concepts from the tutorial.

Context helps language learning significantly, especially if you do immerse yourself if the language and don't worry about exactly what it is doing. The important issue is that you understand the general concepts of what is going on. Just as is everyday human languages, you may not be able to represent the same concept using a one-to-one correspondence of smaller components. There may be some building blocks (cases of words, loop structures, etc.) which don't exist in the other language.

Reading the language and actually working to produce a step-by-step example provide a quick method to develop your intuition about the language. Proceeding without any preconceptions of how things are done is what allows children to develop language skills quickly. Thinking in the other language, rather than translating, provides the additional benefit of allowing you to develop new patterns of thinking that are orthogonal to how you do things currently, since it hides your normal way of doing things.

The second time I did the iPhone/iPod touch example, I added additional functionality on top of that provided in the tutorial. I added a button to change the label text to "How are you doing, [name]?" instead of just the provided "Hello, [name]." Also, I added a button to reset the name to placeholder text, and the label to the starting text, "I can say hello!". This predefined environment allows for exploration and play than starting from scratch. "I broke it by doing this, so I'll revert my changes and try something else." The Agile concept of always having a running demo helps us learn languages more quickly and more thoroughly through experimentation.

As seen in the images here, I added an uneditable text view showing the purpose of the program. Also, the "Reset", and "Ask" buttons are new from the tutorial, as is the support for horizontal, "landscape", mode was added. Not an award winning program, but I am proud of being able to extend the functionality of the original program and add some features I wanted. The learning experience was invaluable, but it is still only an initial step toward developing iPhone/iPod Touch applications.

iPod Touch/ iPhone Rotation

Rotation code for iPod Touch/iPhone. This is more of a thing you need to know that it exists, because it simply requires a few lines of code. This gets added to your UIViewController class which controls the View. Not very exciting except that it allows the program to be used in portrait or horizontal mode from any direction, even upside down. I still need to figure how to configure the view afterward, but at least the question of how it is done is answered. This is from the WhichWayIsUp app.

-(BOOL)shouldAutorotateToInterfaceOrientation:
(UIInterfaceOrientation)interfaceOrientation {
return YES;
}