Here’s what happened in the previous episode…

A mild-mannered, unassuming web developer attempts to break into Obj-C/Cocoa dev territory by making an iPhone Warcraft Characters app. Also, JC Denton escapes, Babylon 5 is destroyed, and the princess ends up in another castle.

Version-that-does-things-right-this-time

Tabs on bottom and edit button were new additions.

After Characters v1.x was out for a few weeks and I enjoyed the high of having an application grow in popularity, I wanted to do another version to bring the product closer to what I felt it should be (you know, that original dream which made me make an app in the first place) as well as address features requested from users… And, *cough*, fix bugs.

The great thing about developing a second version is that you get to learn from previous experience: You see what could be done better, which patterns work, which should be rewritten, and what should be tossed out. Thanks to the first version, I was now a level 20 coder, instead of level 5.

I started the new version with a blank XCode project since I wanted to lay out structure differently. And when I say differently, I really mean better and more maintainable. The new version wasn’t just about a different look and internal tweaks – it was a brand new project that benefited from the mis-steps of my first try.

Let me illustrate that with this example: The first version had simple download classes. It would either successfully download a character, or it would fail. There were no options to notify the user how the download was progressing, more elegant handling of possible failure, or the ability to let the user browse around while different parts of their character info were being downloaded.

In the new version, Characters 2.x, these issues were addressed by adding a queue downloader class that handled prioritizing of approximately 40 downloadable items per character, notify views with progress so the user can still use the interface, and is much better equiped to handle and notify views of possible errors.

Hands down, my two favorite parts of making the second version were the improved code architecture, and tons of new additions to the user interface. More on this below.

Character view – now twice the awesomeness

The Character view was expanded with reputation and an items pane, and other panes were revamped.

This time, I used programmatically created progress bars, used for progressions, reputation, health, mana, and so on. This was officially the first time I dabbled into the CoreGraphics framework, and I got out of it alive. Every time I wanted to create a bar, I’d just call something like this:

[self drawBarInsideView:cell.contentView
at:CGPointMake(110.0, 10.0)
withStyle:[factionDetail objectForKey:@"barStyle"]
withLabel:[factionDetail objectForKey:@"barLabel"]
withValueAsPercentage:[factionDetail objectForKey:@"barValuePercentage"]];

Character sheet was cleaned up in this version, but no radical changes happened.

Compare this to calling a photoshoped image each time I needed to draw a bar. Yay for reusable code!

The Items pane brought the number of items needed to be download from 2 (portrait, stats) to at least 40! Each item download required the image, data file for name, and description window which I’d save as a local web page. Using web code from the Armory for item descrpitions cut development time to a few hours for the Items pane, which is huge time-saver.

Also, I couldn’t let the user wait for all items to download, so I set the download queue object to notify the item list every few seconds, leading to nice gradual population of list items.

Outside character view – revamped as well

New search feature took away the need to type in server name.

A character search used armory search page feature, which was a huge step ahead of having to type in a server name. I didn’t want to take too much time working on a prettier search list (such as class and race icons), so I pushed it to version 3.

Of course, I was much happier with this release. Feedback was mostly great, since I managed to add most of the features that were requested (items, rep, better stats, search). I said “mostly great” since I had requests for anything from talent trees (didn’t want to delay release for weeks just to make talent tree, as gorgeous they are) to 3D character model viewer (if I could make 3D model viewer at that time, I would be making an iPhone game instead).

The iPhone App Store – The Smallest Middleman You Can Get

Item list pulled info dynamically, so you could see it update real-time.

I love the iPhone App Store. When you’re a hobby developer, it’s great that all the work of distributing and deploying an app is taken off your shoulders. It’s also interesting to see how the App Store is growing and evolving over time, and I can’t wait to see what it will be like in a few years. All this, of course, with faith that it *will* get better – currently, many developers complain that it’s a mixed bag.

I did, however, have a review process snafu with it at one point: I made a minor update that added support for Death Knights and level 80 portraits when Wrath of the Lich King came out. While the actual update was minor, it had to get out fast so the users wouldn’t have issues with missing DK talent labels or new lvl 80 portraits. This update was rejected on the basis of ‘not adhere[ing] to the iPhone Human Interface Guidelines’ since the search view didn’t notify the user when a network connection was not available. Fair enough, but I wasn’t thrilled that this happened when a bug update needed to go out fast, especially when the previous 2 minor bug releases with exactly same search pane were approved.

Version 3 – where did it go?

Midway through developing version 3, I got the cease-and-desist letter from Blizzard, which signaled to me that their iPhone app was on the way. Oddly, this was a relief – it meant that a Warcraft app would come out with a *true* armory integration, and I was ready to work on something of my own.

Here are the few screenshots of the work-in-progress for the v3…

You can see placeholder icons for more rich search view.

New favorites option allowed bookmarking of guilds and items, as well as visual update on download progress. Planned to add icons later as well.

Point when C&D letter came in: experimenting with horizontal swipes to give more information without tab jumping (note right arrow on last block)

Why Characters?

Portraits were fetched and cached from Armory website. List of characters was also loaded from local cache - no network connection needed once saved.

The short version is that I wanted to:

• learn something new
• make something I’d use
• enjoy doing it

… and I had:

• a shiny iPhone
• zero experience with compiled languages
• a Loremaster-aspiring druid healer (before being a Loremaster was possible)

A Warcraft-related app was initially a suggestion of a friend of mine. I wasn’t too thrilled with the idea at first since I wanted to make something unique, and not piggyback on someone else’s creation. I warmed up to the idea eventually: It seemed simple enough for a first app, and I thought I’d get the opportunity to tackle quite a few things such as visual design, file storage and web requests to name a few… and nothing like it was on the app store. At this point, I didn’t even consider app store publishing. Besides, I always loved well-done character sheets on pen-and-paper RPGs, and this would give me a chance to do something similar on the iPhone. What was not to like? And off I went…

Firstborn iPhone app

Health and mana bar were pregenerated images made with Photoshop, the rest are Cocoa (native iPhone) objects.

Warcraft Characters was my first foray into Objective-C/Cocoa coding for the iPhone. My background is in Javascript (web dev, people), so the learning curve was steep – I was mostly banging my head against the wall for weeks almost every night. Bright side of this: I didn’t have to deal with Internet Explorer antiques.

Thankfully, I clicked with the Cocoa and Objective-C – most of my moments were ‘oooh, this makes so much sense!’ and ‘sweeeet!’, and after a month, I had my very first Cocoa object displayed on the screen. Note: iPhone dev kit includes Interface Builder, but as a perfectionist I prefered to add objects manually by code. This paid off later, too.

The App itself was a simple combination of Cocoa objects (table view, labels, background images), which fetched armory data and saved it locally. ‘Saved it locally’ was one of key points: I wanted character sheets to be viewable anywhere regardless of network connection.

Design, if you can call it that

Background image was predrawn in Photoshop, and region picker was hastly added after users requested it. This part of the app was least polished.

I wasn’t fond of Characters’ look in the first version, but then again, I rarely like what I did a few versions ago…

Here was my design process:

• draw mockup in Photoshop
• place single image app on the iPhone
• pretend the image is actual running Characters
• repeat until ‘yea, this is it!’ feeling appears

Images, such as health and mana bars, were pre-generated in Photoshop. A more proper approach would be to generate gradient images programmatically and just apply color, but I didn’t get into CoreGraphics until the second version. The Photoshop solution was less elegant, but *much* faster.

Portrait images were fetched and saved directly from the armory server. It’s easy to figure out address for each once I got the naming pattern: gender id plus race id plus class id. So, male (id 0) tauren (id 6) druid (id 11) has image file named 0-6-11.gif. Since this character is level 80, file name is prefixed with /wow-80/ path.

Biggest hurdle

The most painful and almost deal-breaker issue? Getting character data off the Armory. Here’s a snippet of XML data when viewed with web browser:

<defenses>
<armor base="4877" effective="4877" percent="24.25" petBonus="-1"/>
<defense decreasePercent="0.00" increasePercent="0.00" plusDefense="0" rating="0" value="400.00"/>
<dodge increasePercent="0.00" percent="19.48" rating="0"/>
<parry increasePercent="0.00" percent="0.00" rating="0"/>
<block increasePercent="0.00" percent="0.00" rating="0"/>
<resilience damagePercent="0.00" hitPercent="0.00" value="0.00"/>
</defenses>
</pre>

Perfect, right? Even humans can read this! However, downloading this same exact URL with the iPhone resulted in this:

<li class="staticTip" onmouseover="javascript: setTipText("<span class='tooltipTitle'>Defense 400</span><span class = 'tooltipContentSpecial'>Defense Rating 0 (+0 Defense)</span><span class = 'tooltipContentSpecial'>Increases chance to Dodge, Block and Parry by 0%</span><span class = 'tooltipContentSpecial'>Decreases chance to be hit and critically hit by 0%<br/><span class = 'myGray'>(Before diminishing returns)</span></span>");">events={ mouseover=Object mouseout=Object }handle=function()
<span>Defense: </span>
<i>400</i>
</li>

That was bad. I wanted clean readable data, not the garbled final page in HTML format! Why was XSLT tranformation applied already? Wasn’t iPhone just supposed to download raw data I saw in the browser?

A few weeks and 1,000 unsuccessful attempts to figure out the issue, I found the solution in this line of code:

// fake that iPhone is Firefox browser to get XML file from the armory
[request setValue:@"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0" forHTTPHeaderField: @"User-Agent"];

You see, if the Armory server thinks you’re a Firefox browser, it will send you data as XML, which is what I needed. Faking that my calls were sent from Firefox saved the day.

Cleared for launch

Old icon in v1. I spent most of the time trying to get W in with no success.

Icon for next version. Looks much better when I went with the flow rather than forcing W in it.

With the above combination of head-banging and ‘aha’ moments, as well as a dash of Photoshop, Characters v1.0 was born.

When the app worked well enough, it was natural to post it on the App Store. I didn’t have high expectations for it – while I was thrilled to get something out that worked, it wasn’t nearly as good as I wanted it, and on top of that, I was wary of copyright issues that might reject Characters from the start. Still, I did it for two reasons: test the waters, and ship something that works. As a perfectionist, I could work on an app forever, so I started the project determined to actually have a finished version I could possibly improve on later. That’s well summarized in this quote: “Real artists ship”.

After waiting about two weeks for Apple to clear Characters for the app store, I woke up to find 40 emails in my inbox from people who downloaded the app; mostly about asking for Characters to support EU servers. I can’t describe how exhilarated I was to get feedback from users!

For those of you working on your first apps and are unsure of yourselves, let me tell you that the learning experience and feeling of having your creation live is well worth the time and effort. You’ll have nights of frustration thinking ‘this #@!& just isn’t working!’, and that’s fine – persist through it, and results will show.

I rushed off to make an update that supported all international servers, and submitted it a few days later.

Extra credit for devs: Cocoa goodness

Since Characters was my first contact with Obj-C/Cocoa, you won’t find any secret Cocoa tips, but what first coding for iPhone did for this web developer:

• great introduction to designs and patterns: With interpreted and loosely-typed Javascript, you can do things the right way or the wrong way, and it will usually work. Cocoa framework, on the other hand, almost forces you to follow certain patterns. For example, if you used UITableController object, you have used Model-View-Controller pattern. I could read about MVC forever, but actually using it is what made the light-bulb go on for me. This drastically affected how I wrote my future Javascript code in a positive way.
• different ways to organize data: dictionaries, sets, arrays, Core Data. This was a good stepping stone from lenient Javascript to less forgiving C. I didn’t actually start to tackle pure C on this project, but Cocoa was a good crutch as I transitioned into it.
• in the first version of Characters, my subclassing skills were less than ideal, and AppDelegate was overwhelmed with methods. I did better in the next version *grin*.
• I simply love Cocoa method naming convention – it’s easy to read and is self-explanatory. Here’s what methods are called once Characters was initialized:

  [self setupApplicationDataWhenLaunched];
  [self updateCharacterListFromSavedXMLFiles];
  [self setupApplicationUIWhenLaunched];
  

  Quite readable, isn’t it?

• Writing my own FileDownloader class was fun since url request API on iPhone didn’t support file downloads. It was my very first singleton class, too! I did away with singletons later, but it was fun experiment to make one.

That’s all folks! Feel free to contact me if there’s anything else you’d like to read. More about Characters v2 in next installment…

Fascinating and sometimes frustrating thing about design is that there is no one true answer. I can keep working on one template layout for days, just to come up with a better one in few minutes when inspiration hits. Thankfully, I’m quite happy with the way current WordPress theme has turned out.

I started with yellow-to-blue ray header, but final result felt too bland.

Clear header cut-off was progress, but now header looked too generic.

I really liked this nebula image, but overall site look was too dead.

Finally! Bold header image, well defined body, orange-blue color scheme I like.

“Hello World”, and welcome to my blog.

I’m Rudi, and I’m a “geek, JS/CSS acrobat, love to dabble into XCode, Photoshop, RPGs” (direct copy from current twitter bio).

I intend to write mostly technical-related posts on this blog as I dive into them, whatever they might be at the time. As a very curious generalist (aka, I specialize in everything), I’m only sure that the thing/tech/concept I’ll obsess in the next few months will be new, interesting, and different than what I tried before.

This blog is fine example of that: you’re looking at my very own WordPress theme. If you’d like to use the theme, let me know, but please note: it’s ongoing work in progress.

My very own announcement image? Sure, why not...

Technicalities

This WordPress theme was built from scratch, using the Starkers nude theme as a guide of what role which PHP file has. Coding was done in BBEdit and Coda, FTP file transfer via Transmit, and graphics in Photoshop. Header image is from NASA. Site is hosted by webfaction.com, which I highly recommend.

Finally, big thanks to people who were there for fantastic feedback, questions, or encouragement: Aaron, Chris, Dan, Mike, Pete, Rachel, Rale, Sam, Staša, Surajit, Zephyr.

Oh, and happy Thanksgiving to the US folks, and last weekend of November to the world!