Phát triển ứng dụng cho iPhone và iPad - part 34 docx

// Create a node as a child of the attributed node
xmlNewChild (attributedNode, NULL, BAD_CAST “AttributedChild”,
BAD_CAST “Attributed Node Child Node”);

// You can also build nodes and text separately then and add them
// to the tree later
xmlNodePtr attachNode = xmlNewNode(NULL, BAD_CAST “AttachedNode”);
xmlNodePtr nodeText = xmlNewText(BAD_CAST “Attached Node Text”);
// Add the text to the node
xmlAddChild(attachNode, nodeText);
// Add the node to the root
xmlAddChild(rootNode, attachNode);

// You can even include comments
xmlNodePtr comment;
comment = xmlNewComment(BAD_CAST “This is an XML Comment”);
xmlAddChild(rootNode, comment);



// Write the doc
xmlChar *outputBuffer;
int bufferSize;

// You are responsible for freeing the buffer using xmlFree
// Dump the document to a buffer
xmlDocDumpFormatMemory(doc, & outputBuffer, & bufferSize, 1);

// Create an NSString from the buffer
NSString *xmlString = [[NSString alloc] initWithBytes:outputBuffer
length:bufferSize

encoding:NSUTF8StringEncoding];

// Log the XML string that we created
NSLog (@”output: \n%@”, xmlString);

// Display the text in the textview
[self.textView setText:xmlString];

// Free the xml string
[xmlString release];

// Clean up
// Free the output buffer
xmlFree(outputBuffer);

// Release all of the structures in the document including the tree
xmlFreeDoc(doc);
xmlCleanupParser();

}
XML and the iPhone SDK
❘
299
CH010.indd 299CH010.indd 299 9/18/10 10:01:33 AM9/18/10 10:01:33 AM
300
❘
CHAPTER 10 WORKING WITH XML ON THE IPHONE
The last thing that you have to do before running the application is add a call to generateXML to

viewDidLoad :

- (void)viewDidLoad {
[super viewDidLoad];

[self generateXML];
}
Now you are ready to build and run the application. You should see the XML generated in the
console and displayed in the TextView in the iPhone simulator.
Many other features are supported by
libxml . I strongly encourage you to visit the libxml web site
at
.
MOVING FORWARD
In this chapter, you have learned how to communicate with remote servers over the Internet using
the Cocoa URL Loading System. You implemented the
NSURLConnection delegate methods to
handle asynchronous loading of data from the Web. Then, you learned how to parse the XML that
you receive as a response to a remote method call. Finally, you learned how to generate dynamic
XML documents.
This chapter lays the foundation for integration with XML web services. The next chapter explores
communication with XML web services; you build a sample project that queries a web service and
then processes the response in an interesting way.

CH010.indd 300CH010.indd 300 9/18/10 10:01:33 AM9/18/10 10:01:33 AM
Integrating with Web Services
WHAT ’ S IN THIS CHAPTER?
Learning what a web service is and its usefulness
Understanding how to send data to an XML web service using the
POST and GET methods
Parsing the response messages from a web service and using the
resulting data from within an iPhone SDK application

Building location - based applications using the GPS functionality
in the Core Location framework and the mapping capability of the
MapKit framework
In the previous chapter, you learned how to ask for data from a web server by sending HTTP
requests. You also learned about XML and how to parse the XML that you receive from web
servers in response to your HTTP requests. In this section, you will take that knowledge a step
further by integrating your application with Internet - based web services.
In this chapter, you will learn about web services and how to use them in your iPhone and
iPad applications. You will also explore a couple of other interesting features of the iPhone
SDK, including MapKit and Core Location.
This chapter builds on the knowledge that you gained from the last chapter to integrate iPhone
SDK applications with web services. I will cover the use of the
GET and POST HTTP methods
to send data to a web service. You will then build a couple of sample applications that use web
services as an integral part of the program.
NETWORK APPLICATION ARCHITECTURE
When you set out to start work on a new project, one of your fi rst decisions involves designing
the architecture of your application and determining how the parts of your system will work
together. Most data - oriented applications will involve a database, and all iPhone applications
➤
➤
➤
➤


11
CH011.indd 301CH011.indd 301 9/18/10 10:04:34 AM9/18/10 10:04:34 AM
302
❘
CHAPTER 11 INTEGRATING WITH WEB SERVICES

will include a user interface. In order to get a better understanding of how to design applications
where the iPhone and database need to communicate, you will take a brief look at a couple of
typical network application architectures.
Two - Tier Architecture
The simplest network application architecture consists of a database and an interface. Architects refer
to this design as two - tier or client - server architecture. You can see this design in Figure 11 - 1. In this
design, the client application resides on the mobile device or computer, and implements the application
interface. Additionally, the client software includes the implementation of the business rules that
govern the functionality of the application. The server tier is generally an enterprise database such as
Oracle, SQLServer, or MySQL, which can share its data with many connected clients.
Server
Client
Client
Client
FIGURE 11  1: Two - tier architecture
You see this type of client - server architecture when you look at web servers, particularly web servers
that serve simple HTML web pages. The client in this design is your web browser and the server
is the web server. Many clients connect to the same web server to get data. The client web browser
hosts the user interface and the logic to display the HTML data.
This architecture is most appropriate for simple applications. However, as the business rules for
your application become more complex, you will likely outgrow this design. In order to maintain
encapsulation of functionality, the client should be responsible for displaying data and the server
CH011.indd 302CH011.indd 302 9/18/10 10:04:40 AM9/18/10 10:04:40 AM
for storing it. If there are minimal rules that govern the logic and data of the application, you could
implement them either in the database or on the client.
As the number and complexity of the rules that defi ne the functionality of your application increase,
you will need to decide where you want to implement those rules. You could implement them on
the client. If your client software were a “ thick ” desktop application, changing rules would mean
re - deploying your application to your clients. If the client is a “ thin ” web - browser based client, you
are constrained by the capabilities and performance of the browser and client - side languages such as

JavaScript.
As the business rules of your application get more complex, you will often need to add a third tier
to your application architecture. It is in this tier where the business rules reside. In this design, you
can decouple your business rules from both the display logic of the client software and the storage
system of the database.
Three - Tier Architecture (n - tier)
As you learned in the last section, you need to consider your application ’ s ability to maintain a
complex set of business rules in your design. As you design your system, you need to consider the
complexity of the rules that govern your application and the likelihood that these rules could change.
For instance, if you are building an order entry system, you need to consider the fact that customer
discount percentages could change. You may not want to code these percentages into the user interface
layer of your application because any changes to this data would require a redeployment of your
software. In instances like this, it is common for the designer to pull these business rules out of the
interface and place them in their own logical software layer. The client - server design then evolves into
a three - tier (or n - tier if more than one business layer is necessary) architecture (see Figure 11 - 2).
Application ServerDatabase Server
Client
Client
Client
FIGURE 11  2: Three - tier architecture
Network Application Architecture
❘
303
CH011.indd 303CH011.indd 303 9/18/10 10:04:41 AM9/18/10 10:04:41 AM
304
❘
CHAPTER 11 INTEGRATING WITH WEB SERVICES
In a three - tier design, the application architect moves the business logic in to its own logical and
perhaps physical process. You can therefore decouple the business rules from the user interface
and the database. This gives the designer more fl exibility when it comes to designing the database,

the interface, and the business logic. It also effectively encapsulates each of these important features
of a system. It is easier to manage the business logic of your system if you do not tightly couple
this code to the database or the user interface. This simplifi es making changes to any one of the
layers of the design without affecting any of the other layers. In this design, all of the rules that
govern what data can be added to the database and specifi c calculations that are performed on
that data are moved out of the interface layer into their own tier. Many commercial application
servers such as WebLogic, Apache Tomcat, and WebSphere perform this function.
Application Communication
Client applications need to be able to talk to the business tier or application server and the
application server needs to be able to talk to the database.
Typically, the application server and database reside on the same local network, although this is
not necessary. These two layers generally communicate through an interface layer that knows how
to call functions in the database. A common interface API for database communication is Open
Database Connectivity (ODBC). Most programming languages provide support APIs for connecting
to databases as well. The Microsoft .NET platform provides an API called ADO.NET while the
Java system provides JDBC.
For the client to business - tier communication, the designer can implement connectivity using a
variety of methods depending on the languages and operating systems used in the implementation.
In the past, designers of Windows systems would have used DCOM or Distributed Component
Object Model. This technology allowed components on different computers to talk to each other.
In a Java - based system, the designer could choose a similar technology called Java Remote Method
Invocation (RMI). In this system, objects running in one Java virtual machine can call methods
on objects in another virtual machine. CORBA, or Common Object Request Broker Architecture,
is another technology that enables remote machines to execute methods and share data with
one another. The advantage of CORBA is that it is language independent. There are CORBA
implementations for most major computer languages and operating systems.
A more current technology enables the designer to implement the functionality of the business tier
as a web service. With this technology, the designer can expose the business logic of the application
using a web server. Client software can then use well - known methods of the HTTP protocol to
access the services exposed by the application server.

INTRODUCING WEB SERVICES
When you use a web browser to visit your favorite web site, you begin by sending a request to the
site ’ s server. If all goes well, the server accepts your request and returns a response. The response
that you get is text in the form of HTML, which your browser renders into the page that you see on
your screen.
CH011.indd 304CH011.indd 304 9/18/10 10:04:41 AM9/18/10 10:04:41 AM
Consumers of the HTML that a web server sends are generally people that view the HTML using a
browser. Web services, on the other hand, respond to requests by sending back data that is intended
for computers to consume.
Typically, most web services default to returning response data to you using XML. With some
web services, however, you can request that your data be returned in other formats, such as JSON
(JavaScript Object Notation). JSON is a text - based format, like XML. Unlike XML, however,
JSON can be used directly in browser - based web applications that are backed by JavaScript
code. Coverage of JavaScript is beyond the scope of this book, as is using JSON in browser - based
applications. What you should know though is that there are parsers available to consume JSON
response data for many languages, including Objective - C.
In the previous chapter, you looked at a snippet of XML that could be used to add an address entity
to an address book application:
< address >
< name > John Smith < /name >
< street > 1 Ocean Blvd < /street >
< city > Isle Of Palms < /city >
< state > SC < /state >
< zip > 29451 < /zip >
< /address >
Here is the JSON representation of the same address:
{
“name”: “John Smith”,
“street”: “1 Ocean Blvd”,
“city”: “Isle Of Palms”,

“state”: “SC”,
“zip”: “29451”
}
Unlike XML, whose structure is defi ned by its users, JSON relies on data structures defi ned in
JavaScript. Specifi cally, JSON can use one of two data structures: the
Object or the Array . Because
these data structures are common in almost all modern languages, it is easy to convert JSON
messages into data structures that can be used in almost any language. The
Object consists of a set
of name - value pairs, and the
Array is a list of values.
Application architects can design web services to act as the application server for their particular
application. Third parties also build web services to provide specifi c services to their clients. In
this chapter, you will develop two applications that use third - party web services from Yahoo! to
implement some interesting functionality. The fi rst service allows you to submit queries and returns
the results based on proximity to the location of the search. The second service accepts a long string
of text and returns a list of the most important words in the text.
In general, web services provide a way to expose some complex logic by using the simple and well -
known interfaces of the Web.
For example, a designer can easily expose an external interface to a database by building a web
service that allows clients to create records or query the data store. Consider the product catalog
Introducing Web Services
❘
305
CH011.indd 305CH011.indd 305 9/18/10 10:04:42 AM9/18/10 10:04:42 AM
306
❘
CHAPTER 11 INTEGRATING WITH WEB SERVICES
from Part I of this book. You could build a web service that exposes an interface that accepts orders
and enters them directly into the back - end database. You could then build an iPhone order entry

application that uses this web service to allow your sales force in the fi eld to submit orders.
You can develop web services using many languages and frameworks such as Java, Microsoft.NET,
and Ruby on Rails. Because of the variation in languages and platforms available, building a web
service is beyond the scope of this book. This chapter teaches you how to integrate your application
with existing web services.
SOAP Messaging
There are two predominant protocols used for exchanging data with web services: SOAP and REST.
You will look at SOAP in this section and examine REST in the next.
Microsoft originally developed SOAP (Simple Object Access Protocol) in the late 90s and the W3C
standards body has standardized the protocol. The designers built SOAP to be platform - and
language - agnostic in order to replace technologies such as CORBA and DCOM. The designers
chose XML as the format for the messages in an effort to avoid some of the problems associated
with the binary - based messaging systems that SOAP would replace.
Unlike CORBA and DCOM, the designers of SOAP decided to send messages using the HTTP
protocol, which makes network confi guration easy. If users could see each other over the Web using
a browser, they could send messages to each other using SOAP.
SOAP messages share a common element with other messaging formats such as HTML in that
the message contains a header and a body. The header contains details about the type of message,
format of the data, and so on. The body holds the “ payload ” or the data that the user intends to
transmit.
One issue with using SOAP is the complexity of the messages. In order to transmit a little bit of
data, users of SOAP often need to transmit long messages. For example, here is the SOAP request
message that you would send to the eBay SOAP API to obtain the offi cial eBay time (from eBay.com:
using the eBay API to get the offi cial eBay time):
< ?xml version=”1.0” encoding=”utf-8”? >
< soapenv:Envelope xmlns:soapenv=” /> xmlns:xsd=” /> xmlns:xsi=” >
< soapenv:Header >
< RequesterCredentials soapenv:mustUnderstand=”0”
xmlns=”urn:ebay:apis:eBLBaseComponents” >
< eBayAuthToken > ABC 123 < /eBayAuthToken >

< ns:Credentials xmlns:ns=”urn:ebay:apis:eBLBaseComponents” >
< ns:DevId > someDevId < /ns:DevId >
< ns:AppId > someAppId < /ns:AppId >
< ns:AuthCert > someAuthCert < /ns:AuthCert >
< /ns:Credentials >
< /RequesterCredentials >
< /soapenv:Header >
< soapenv:Body >
< GeteBayOfficialTimeRequest xmlns=”urn:ebay:apis:eBLBaseComponents” >
CH011.indd 306CH011.indd 306 9/18/10 10:04:42 AM9/18/10 10:04:42 AM
< ns1:Version xmlns:ns1=”urn:ebay:apis:eBLBaseComponents” > 405 < /ns1:Version >
< /GeteBayOfficialTimeRequest >
< /soapenv:Body >
< /soapenv:Envelope >
This is quite a verbose message, especially considering that you are not even passing in any
parameters. Although the API simply returns a timestamp that represents the current time, it is also
quite verbose:
< ?xml version=”1.0” encoding=”utf-8”? >
< soapenv:Envelope xmlns:soapenv=” /> xmlns:xsd=” /> xmlns:xsi=” >
< soapenv:Body >
< GeteBayOfficialTimeResponse xmlns=”urn:ebay:apis:eBLBaseComponents” >
< Timestamp > 2005-05-02T00:07:22.895Z < /Timestamp >
< Ack > Success < /Ack >
< CorrelationID >
00000000-00000000-00000000-00000000-00000000-00000000-0000000000
< /CorrelationID >
< Version > 405 < /Version >
< Build > 20050422132524 < /Build >
< /GeteBayOfficialTimeResponse >
< /soapenv:Body >

< /soapenv:Envelope >
While SOAP offers far more functionality than simple method calling, you can see why developers
often mock the name “ Simple ” Object Access Protocol. Designers that simply needed to pass data
between application layers or make basic method calls found that SOAP was overkill. This led to the
development of a simpler messaging protocol called REST.
The REST Protocol
REST stands for REpresentational State Transfer. The designers of REST wanted to be able to call
web service functions using the simple and well - known methods exposed by the HTTP protocol:

GET and POST . The goal was to make it easy to invoke remote functions and provide response data
in a more manageable format.
REST uses a simple URI scheme to communicate with web services. Developers who are
comfortable using HTTP to make requests over the Web already know how to call REST services.
Typically, a client application can simply issue an HTTP
GET request to a URL to make a method
call. The developer can pass parameters to the call using querystring parameters as if simply passing
parameters to a regular web site.
Because REST is not standardized, it is possible that the client will receive response data from a
REST - based service in an arbitrary format. However, XML is commonly used. Typically, REST -
based web services can also return data using the JSON format instead of XML. This is preferable
if you are developing Web - based applications.
In order to be able to easily determine the intent of a call, the HTTP
GET method is used to query
for data, and the HTTP
POST method is used when you want to modify data such as in an INSERT
Introducing Web Services
❘
307
CH011.indd 307CH011.indd 307 9/18/10 10:04:43 AM9/18/10 10:04:43 AM
308

❘
CHAPTER 11 INTEGRATING WITH WEB SERVICES
or UPDATE to a database. This makes it easy to determine if the caller intends to simply query the
service for data or make changes to the data managed by the service.
It is very easy to build simple web services using REST. If you already know how to implement
server - side web scripts, REST implementations are typically straightforward. Both of the examples
in this chapter will call web services based on the REST protocol. All of the concepts in this
chapter are equally applicable if your application needs to call a SOAP - based service. The only real
difference is the format of the message that you are sending and the format of the response message.
EXAMPLE 1: LOCATION - BASED SEARCH
One of the great features of the iPhone and iPad 3G is the GPS. Developers are able use GPS to
determine the current location of the device and build applications that use this data to provide a
wealth of information to users. This leads to some very creative applications.
In the fi rst example in this chapter, you will take advantage of this capability of the device. You
will use the Core Location framework to determine the current position of the device. Then,
you will allow the user to input search terms into the application. You will then call a Yahoo! web
service using the REST protocol and the HTTP
GET method to obtain businesses that meet the
search criteria and are close to the current location. Finally, you will use the MapKit framework to
display the returned data on a map.
FIGURE 11 - 3: Completed
LocationSearch application
Don ’ t worry if you don ’ t have an iPhone. When you use Core Location with the
iPhone simulator, the simulator conveniently returns the latitude and longitude
of Apple headquarters in Cupertino, California.
The fi nished application will look like Figure 11 - 3.
Starting Out
Now that you have an idea of what the application will do and how it
will look, let ’ s get started. The fi rst step, as always, is to open Xcode
and create a new project. Because there will be only one view, you

should create a new View - based application. Call the new application
LocationSearch.
You will be using the Core Location and MapKit frameworks in this
example. These frameworks are not included in iPhone projects by
default, so you will have to add references to the frameworks to the
project. Right - click on the Frameworks folder in the Groups & Files pane
in Xcode. From the pop - up menu, select Add ➪ Existing Frameworks.
In the dialog that opens, select the
CoreLocation.framework item
and click the Add button. Repeat this procedure to add the
MapKit
.framework
framework to your project as well.
CH011.indd 308CH011.indd 308 9/18/10 10:04:43 AM9/18/10 10:04:43 AM