Niklas Saers' blog

Like many of you, this morning I went on the Apple Store online and ordere my iPad 2. I’ve had a chat with many shop keepers today, both Eplehuset, Elgiganten and Humac. What seems to be the genereal consensus is that less than 10% of the iPads they had asked for have been delivered. So there is a major shortage. My idea was that Apple would prioritize their own channels, but my order from early this morning when they opened is scheduled for delivery in more than a month! So I guess I was wrong, and just like so many others I’ll just have to wait…

I’ve been developing apps for the iPhone since the early betas of iOS 2.0, and one of the things I’d like back then was to use SOAP services. Back then, Apple had an old, half-implemented command-line program called wsmakestubs that you could use to generate some stubs that half worked. That program has not been updated, nor has any more SOAP support been added to iOS itself.

What has changed, though, is the eco-system. First off all, we can talk about it and share experiences. Secondly, people have made and shared interesting stuff. One of my favourites is SudzC. It’s very interesting, but has been stuck in alpha for a while. Commercial offerings such as WSClient++ are also interesting, but what I’ve found is that, for the most part, I don’t need all this support I was looking for.

Hand-crafting the XML is easy enough. Just grab SOAP Client and fire of a request, then get the raw request and modify that XML. Likewise, check out the raw response and use XPath to grab the parts of the answer you need. Fire off the request with ASIHttpRequest just to make it easier. All in all, getting hooked up to your SOAP service shouldn’t take long.

For examples of using XPath, check out this example at Stack Overflow.

So back to the topic, the state is that it’s not well supported, but it doesn’t need to. Doing it yourself has become easy with great supporting frameworks for requests and XML handling in the iOS eco system.

The kind of errors I hate the most are the ones you cannot even find in the documentation. When you get no compiler warnings, and even an incentive from your preferred auto-completion tool to go straight into them.

Todays such error is the following:

byte[] buffer = /* something that fills the buffer with the contents of a string*/;
String stringBuffer = new String(buffer, Charset.forName("UTF8"));

What’s wrong here?? Compiles fine, looks fine…. let’s read the doc… fine. Except, as it turns out, for long buffers, it will truncate the string and add a trailing …. So you need to do something like this instead

String stringBuffer = new String(buffer, 0, lengthOfBuffer, Charset.forName("UTF8"));

That gives you a correct string, not truncated and not with a … at the end. *sigh*