What is the best way of connecting to a remote server/database to retrieve data from the IPhone

Question

I am currently writing an app which will need to access a remote server/database to read/write values. What is the best technology to use? I've heard that there is no support for XML Webservices...does this mean a ASP.NET Webservice will not be easy to access?

Thanks.

Answer 1

There is no explicit support for webservices but you can still 'roll your own' using the NSURLconnection and NSXMLParser classes.

Its not exceptionally difficult to use these technologies but it can be time consuming writing the code for every web-service you want to access.

Answer 2

It's not true that there's no support for XML Webservices, so a webservice is definitely the easiest way to do this.

Obj-c's XML parsing stuff is quite hardcore, so hit this link for a couple of neat libxml2 wrappers:

http://cocoawithlove.com/2008/10/using-libxml2-for-parsing-and-xpath.html

Answer 3

Do you have to use SOAP? I can understand that for legacy reasons and/or if the iPhone is not the only client to an existing Web Service provider, you may have to use SOAP-based Web Services however we have apps that communicate with various services (server-side components) using our own XML schemas. In this, we use the standard NSXMLParser.

Answer 4

Or, you could use MonoTouch.

Answer 5

http://ODBCrouter.com/ipad (new) now has XCode client-side libraries, header files and Objective C objects that let your apps do multi-threaded ODBC using server-side drivers.

That lets you use regular SQL or call stored-procedures instead of separately maintaining SOAP/REST services which is pretty frightening to do after you have a large number of live users. The ODBCrouter stuff is not free, but it is always cheaper than the manpower cost of developing SOAP/REST services and the Cocoa Touch side, little known maintaining it.

The whole prior alternative scheme, XML, was okay for transferring static configurations to mobile devices "every once in a while", but it was really only designed for exchanging data between batch-jobs or companies in a "server environment" (power cords and air conditioning) and is definitely not efficient for frequent database queries coming in from n-copies of a mobile app. Aside from the higher network overhead and battery power the mobile CPU will draw with XML, it will also make you buy more RAM and CPU power on the back-end server faster than just using ODBC. That said, make sure your queries are laser efficient (try to use only stored procedures and/or triggers and only select columns you need --avoiding wildcards and limiting result sets to only what's likely to be useful to the user).