There is much dicussion today about whether companies should choose REST or SOAP to serve web service requests to their clients. In this post, I’d like to help formulate a clear picture of what each offers over the other.
A common question I see asked across the internet is “how can I specify server login credentials to a UIWebView automatically so the user doesn’t have to enter them. You could want this for multiple reasons. Perhaps you already know the login credentials of the user ahead of time, but don’t want to store them in the keychain. It’s also possible you’ve had them authenticate so that you can make calls on your networking stack of choice (I’m a fan of ASIHTTPRequest) and you want to open a web link on the same server in a UIWebView. We already know the credentials, but the web view doesn’t share cookies with the networking stack.
It’s more work, but working around it will provide your users with a better experience. That’s what mobile is all about, right? To implement, you’ll need to make the request with your networking stack. You’ll need the response body back as an NSData object. You’ll also need to remember the MIME type of the response. Once you’ve got these two items, call loadData:MIMEType:encoding:baseURL on the UIWebView and voila! You’re displaying page information without having to ask the user to authenticate.
In college, developers are taught to measure performance metrics. They are constantly checking test cases and measuring scalability. In effect, this is creating a mindset that values implementation over design.
All of those things are important. If an app doesn’t perform in a timely manner, no one will want to use it. At the same time, if an app is not visually appealing, no one will want to use it.
It’s difficult to find a balance between the two. This is what separates the good developers from the great ones. Which kind are you?
I recently came across a bug (one of mine, not Apple’s) in one of my applications where I was persisting an NSMutableString to Core Data. The information was being persisted as desired, but later I would find that the value of my property had changed. What made this seem even weirder was I found that reloading the object from Core Data fixed the issue.
It seems that the Android 2.3 emulator doesn’t respond to location updates. Hopefully this will keep you from pulling your hair out when you’re trying to test location features.
