Do you have an idea for an app but lack the programming knowledge to begin building it? In this weekly blog series, I will take you, the non-programmer, step by step through the process of creating apps for the iPhone, iPod touch, and iPad. Join me each week on this adventure and you will experience how much fun turning your ideas into reality can be! This is part 33 of the series. If you are just getting started, check out the beginning of the series here.
So far in this series, with the iAppsReview project we have always retrieved and stored data directly on the iOS device (or Simulator) using Core Data. However, we eventually need to retrieve and store data on the web so we can read other users' online reviews, and post our own reviews to the web. Accessing data on the web is definitely not trivial. That's why I've waited to introduce the subject. We'll take it slow and in this post I'll provide an overview of the concepts before we begin diving into some real code in the next few posts.
Why Access Data on the Web?
In general, there are a few reasons why you may want to access data on the web from within your apps.
First of all, accessing data from the web allows your app to get the most up-to-date information. For example, think of the built-in Weather app. It's important that this app retrieve the latest weather information from the web in order to provide the most up-to-date information. Another great example is the built-in Stocks app. Getting the most recent information is critical when dealing with stock prices that change frequently.
 |
| Figure 1 - The Stocks and Weather apps retrieve their data from the web. |
Another reason to access information from the web is when you are creating apps that are an add-on to existing business apps. Many of my business customers have asked me to build iOS apps that augment their existing business apps (which often run on Microsoft or Linux platforms). When these business people are away from the office, it's important for them to be able to access some subset of information from their business system in an iOS app via the internet.
A third common need for web access is multi-player online games such as the popular Words with Friends or, on the other end of the spectrum, Call of Duty Black Ops Zombies. These apps use the web for communication between players.
Introducing Web Services
One of the primary tools used to access data from the internet are web services. A web service is a piece of software that runs on a web server and usually provides access to a large, underlying software system. As shown in Figure 2, an app on an iOS device can request data from a web service. In the simplest of architectures, the web service can read the data directly from a database and then send a response containing a list of data back to the app which can then be displayed in a table view. For example, in the iAppsReview project, we need to request a list of reviews from other users to display in the Online Reviews scene.
 |
| Figure 2 - A request is sent to a web service, and it responds by returning data. |
It's important to note that web services are a two-way street. You can also send information to a web service (this is still considered a request) that can be stored for later retrieval. For example, in the iAppsReview project, we need to pass our review to a web service to be stored on the web so others can access it.
Web Services as Black Boxes
One of the key features of a web service is that it is a "black box." As a consumer of a web service, all you know is what information a web service accepts and what it returns to you. This black box approach shields your app from having to know the details of the underlying technology. Is the web server running Windows or Linux? Is the database Oracle, SQL Server, or MySQL? With web services you don't need to know (and ultimately, you don't want to know!)
What you do need to know is which one of the standard message formats the web service communicates in, such as:
- JSON - JavaScript Object Notation
- SOAP - Simple Object Access Protocol
- XML - EXtensible Markup Language
Once you determine the message format used by a web service, you send it messages in that format and the web service does the rest. You don't need to know the web server platform, the type of database, or other infrastructure details. It just works.
Although you may not be given a choice when working with pre-existing web services, the easiest message format to work with in iOS is JSON, and that's the message format I'll be using in upcoming posts.
Business Controllers and Web Services
In the iAppsReview project when we retrieved and stored data directly on the iOS device, we used business controllers to encapsulate the Core Data logic. As shown in Figure 3, the view controller passed a request for data message to the Review business controller, which in turned passed the message to the managed object context which worked along with other Core Data objects to retrieve data from the SQLite database. This data was returned to the business controller, which in turn passed it back to the view controller. All of this happened relatively instantaneously. This is indicated by the dotted lines pointing back from the SQLite database all the way to the view controller.
 |
| Figure 3 - The Core Data message flow |
When retrieving data using web services, we will take the same architectural approach and encapsulate the call to web services within business controllers. However, due to the latency of the web (the delay between when a request is made and when a response is received), we need to take a slightly different approach to sending and receiving responses from the business controller. In Figure 4, the cloud shape represents the internet. The view controller passes a request to the Review business controller, which in turn passes a request to a web service. The time that it takes the web service to respond is variable and unknown.
 |
| Figure 4 - Web service message flow |
Since we don't want the view controller (the user interface) to be unresponsive while the web service request is being processed, the view controller needs to give the business controller a method to call back when it receives data from the web service. Basically, it's saying "call this method on me when you get a response back from the web service." This is similar in concept to when you call a customer service help line and they offer the option to call you back when a representative becomes available, rather than waiting on the line. This frees you up to do other things while waiting for a response.
To handle this sort of callback, I've made a few changes to the mmBusinessObject class we have been using, and I'll introduce these changes in my next post.
Conclusion
Incorporating calls to web services in your apps is a big leap that requires additional knowledge of web technologies, and an understanding of the things that can go wrong when you make a web request. In my upcoming posts we will tackle these topics and explain them in a way that you can understand how it all works. When you come out on the other side, you will have an extremely important tool available to you that is critical in creating real-world apps that contain all the functionality users have come to expect.
