krawaller

Update: As Tradera finally saw sense and ported the eBay app, we're pulling the Auktionera app from the App Store! One has to choose one's battles... 

As Jacob wrote the Livetanium post 2 months ago, I remember us vowing to keep up the pace in the content flow to this blog. That was, as stated, two months ago, and this place has been tumbleweeding ever since. Epic fail, as the kids (erroneously) say these days! 

One of our excuses is a pretty intense development of an iPhone app for the swedish auction site Tradera, which is now released to the App Store! Here's a shop link, and we also created a little support site with some more information (in Swedish).

Functionality

The app is a pretty standard auction site app, much like the eBay one. You can peruse auctions, bid, create your own auctions, save favourite searhes / users / auctions, check seller history, etc.

(download)

Click here to download:

releasing-auktionera-a-tradera-iphone-app-ItBjeFqdGnhGEbvbsdwz.zip (406 KB)

Made with love and care, but pretty boring, in other words. This was also our approach as we entered the project. We weren't really intrigued by the technical challenges, but thought this had a good chance of selling well. This mainly because there already was an app in the store, selling better than our Systemet in spite of being rather crap. 

This competing app is getting flak because of two different things:

• It is, as stated, rather crappy, being very prone to crash. Also some functions have ceased to work after the latest iOS upgrades. 
• It relies completely on Tradera's official API, which for whatever reason is missing some vital functionality, such as checking out a seller's previous history. This is, naturally, something that an auctioneer want to be able to do, before taking the plunge and risking those hard-earned dimes!

Our tactic was therefore a mirror image of this list:

• Make sure the app doesn't crash and burn!
• Complement the official API functionality with some YQL scraping on the side.

Sounded easy enough, but it turned out that none of the above was as straight-forward as we thought..

Titanium stability

After a lengthy development cycle in Titanium and the emulator, we did a first reality test on an actual device. We weren't really worried, as the app flowed very neatly in the emulator. But, as we fired it up on the phone, we discovered to our dismay that we had managed to copy the very fickleness we wanted to avoid! The app would crash in random places, not leaving any definite clues as to why. 

Not until we ran the app in an emulator next to the activity monitor did we find out why. It turned out that Titanium did some things rather inefficiently, which would eventually cause the phone to run out of memory or processor juice. The same thing happened in the emulator, but there it wouldn't hit the ceiling as soon, as the computer has much more resources. 

So, what were these inefficient things that Titanium did? Well:

• First off - don't handle XML in your app, unless you can avoid it. XML is of course painful in and of itself, but Titanium's garbage collection somehow cannot clean up after xml parsing. Try it: open a new window, parse some XML, then close that window (using the back button, for example), and watch the processor usage spike, never to drop again. 
• Be careful when doing advanced table creation. Use the best practices detailed in the documentation, and test your table generation with the Activity indicator running. For some combinations of table gymnastics, the memory usage will be intolerably high, eventually making the app crash.
• If you have a large data structure, prefer a sqlite database to just keeping a big object in memory. This might be obvious to the rest of the world, but took us a bit off guard - intuitively, we thought it would be more efficient to keep a single object and query that, skipping the overhead cost of a database. However, some testing proved us very wrong indeed - the sqlite database is quicker and uses far less memory.

So we learned some specifics, but the main lesson for us was this: do frequent reality checks on an actual device. Titanium is still a young framework with many rough edges, and some of those edges will not cut you in the emulator since that does not correctly emulate the hardware limitations. 

YQL + Tradera = somewhat true

We also had a rough time with the intermingling of official functionality and our home-brewed YQL-fueled queries. There were several authentication and authorization models involved; the Tradera API requires an App-Id, the user must be authenticated through the API, and also through the official site for our scraping to work. 

When starting off, we had all this in a spaghetti-bowl of code in the app. Lots of moving parts, lots of things that could break at any time. Not until we isolated all of this to a PHP-bridge did the different parts fall into place. This is of course what we should have done from the beginning - separations of concern is something we frequently preach to others. But somehow we fooled ourselves into thinking we'd already done this, as we has lots of logic in the YQL OpenTables. The lesson: you can always abstract your code one step further. :)

API design IS an artform

The biggest challenge, however, was actually using the Tradera API. I now realize that I've taken usability and intuitivity for granted in the API:s that I use, not thinking much of it. It's like appreciating your mom doing all the household chores - you don't, until you move out. I had no idea that designing a good API takes work, until I used a bad one.

Now, you shouldn't bite the hand that feeds you, but the Tradera API is pretty horrid. There seems to be no general rule for naming functions (camel casing, lower case, it's the wild west in there). The same property names mean different things in different functions. Documented properties are sometimes populated, sometimes not, depending on the weather and alignent of planets. Functionality between functions overlap, but never so much that you can ignore one function and just use the other.

And, most jarringly - there are several spelling errors in the API! When first creating our infrastructure to make calls, I tested it using the most simple function "GetOfficialTime", requiring no parameters and just returning a flat data object. It didn't work. Several hours later of reading SOAP specs and going through the code, I found the error - I needed to spell it "GetOfficalTime", note the missing "i". Fast forward a few weeks, and the same thing happened again when we tried to filter out used goods with the search parameter "ItemCondition". It was supposed to be "ItemConditon", again note the missing "i". 

In Tradera's defense, the misspellings are also present in the documentation, and they offer free support for developers using the API, which we found very helpful. But still, it made me better at appreciate good API design. And more on my guard when using them.

The result

In the end we feel pretty proud of the result! This in spite of entering the project with little heart, and being in some serious stability trouble mid-journey. So, now to the boring side of things - pushing the app, spreading the word. As previously lamented, this is not what we do best.

Anyhow, hope the Swedish speakers among you will check the app out! Next up, Jacob will do a (less chatty) write-up on his neat method for deploying app builds to testers, right, brother? The pressure is on!