The Vostok blog

My name is Timo Taglieber, and I’m developing the Planetaki iPad App for Vostok. I came to Madrid just for this project, and it’s been great so far. In the following, I’ll describe some of my experiences here as a developer.

Before starting my ‘mission’ here at Vostok, I had a bit of experience with the C language, and felt comfortable with Python, Java and PHP. So naturally, it was time for something new. I had no contact whatsoever with Mac development, and took the opportunity to dive into it.

I recently bought an iPod Touch, so that at least the iOS and its user interface wouldn’t be completely new to me. Now it was time to go behind the scenes of shiny buttons and polished layouts: I started to build the iPad Application for Planetaki.com from scratch. Here are some of the obstacles I encountered.

Problems and solutions

• While the web version of Planetaki is rendered by browsers, we wanted to build a native interface. This means that some things you take for granted when web designing simply don’t exist on the iPad. Where you just scroll down in your browser window to read the content of your planet, I created a table view with customized cells for each blog post. Since there is no automatic rendering of flowing text (we can’t know the height of a post beforehand), a few tricks were necessary: The HTML content of a post is injected into a web view, and those objects are capable of determining their height with Javascript. This allows us to dynamically redraw the scrollable list of posts with correct proportions.
• Before testing on the actual device, we weren’t sure if the planet screen with its many web view objects would render fast enough. Luckily, it did. As soon as the loading of images in posts will be implemented, which is notorious for being slow on the iDevices, we will see how good this solution really is – Fingers crossed.
• Multithreading was another new thing I had to dig into. The user interface can’t be blocked while new posts are being downloaded, so this needs to happen in the background. After messing with notification sending between threads, and thinking about smart ways to design all that, I read some really good advice: One usually doesn’t need as much concurrency going on, as one initially thinks.. So avoid the traps of thread programming wherever possible (Thanks, SQLite.org!). Using a NSOperation and keeping it small and simple was the way to go.
• Memory management is tricky if you have to do it manually. There’s no garbage collection with iOS, so the retaining and releasing of your objects has to be balanced. Occasionally, you have to make sure there are no memory leaks in your code, and if otherwise, get rid of them. It can be done and you get used to it, but it certainly adds to the overall complexity.

Resources

A few words about the resources i’m using:

The IRC-Channel #iphonedev on freenode.net turned out to be quite helpful. Don’t be scared by a rude tone and people throwing ‘RTFM’ around, there are actually some seasoned developers how can provide new insights and perspectives. Sometimes, just not being alone with a problem is enough drive to keep going and eventually crack it.

Programming books (Objective-C, Cocoa) didn’t really do it for me. They seem to cling to successive example apps which they develop throughout the chapters, making them more and more complex. What I was really looking for were minimal examples, solely focused on one problem at a time with any other clutter removed. It sounds simple, but there are way too few of those around. I’m the type of learner who seeks those example to compose my own solutions bit by bit, instead of reading up on something for hours first. You might call this the ‘Google Generation’, but this method is quite efficient for technical things.

What’s next

As the project keeps growing, also does the overhead of maintenance and administration (probably true for most complex system). The cogs and screws of the machine need to be readjusted constantly. I’m happy that at this point the basic infrastructure works, and all basic problems are solved. You can see a schematic overview of the units of Planetaki for iPad below. The light gray boxes are external libraries, and PlanetUpdater is the background process mentioned before.

Now we ‘just’ need to do visual fine tuning, complete the communication with the Planetaki API, do some testing, and prepare for submission to the App Store. Stay tuned!

Written by Timo Taglieber