What a long strange trip it's been over the late spring and early summer in 2011. Thankfully, everything is up and going in the world of MonoTouch. This is the
latest article in what is a series of articles on iPhone development for .NET/C# developers using MonoTouch. To get up to speed on MonoTouch, check out
my first article from the April 2011 issue of DevProConnections,
"Guide to Building iOS Applications with MonoTouch for the .NET/C# Developer."
Article Overview
Data is what makes applications go. It could be a Twitter search, a running game score where you are playing against your friends, sales data, or any
other type of data that users want to base decisions on. In this article, we're going to look at presenting tabular data to users in a UITableView. The
UITableView has a number of visually attractive default styles that you can use. After we're done looking at these, we'll look at creating a custom
UITableView layout. Along the journey, we'll look at some optimizations we can do that will give the user an improved experience. After we're done with
this, we'll look at some strategies to get at various data sources, such as Representational State Transfer (REST), Windows Communication Foundation
(WCF), SQL Server, and the on-board SQLite database.
Limitations with Data Apps in iOS
I would be remiss if I didn't mention some of the problems you may run into when using data in the iPhone. These data limitations have very little to
do with MonoTouch and much more to do with the general limitations of mobile as well as security issues that you need to be aware of.
First off, the iPhone has a watchdog timer. The timer is "watching" your application. If the timer thinks that your application has locked up in any
way, such as locking the UI thread for too long, iOS will kill your application. What does this mean? If your application makes a network request that
takes a long time, your application has a good possibility of being killed by the system. This can happen if you make this web request on the UI
thread. You want to make requests on a separate thread.
Second, if you make even small requests on the UI thread, you are making a request that can result in "jerky" responsiveness to the user. Your users
won't like this. Third, using WCF services in MonoTouch is different from just adding a reference in MonoDevelop to a service and calling methods on
the proxy. iOS limits an application's ability to dynamically create code at runtime. As a result, calling WCF is slightly different in iOS. We'll walk
through what you have to do there. Finally, when we get to the section on working with SQL Server, I am in no way, shape, or form suggesting that you
open up your database server and its associated ports to the public Internet. I view using SQL Server as merely an option for an internal company
application to be used on its private network -- say an iPad tablet application used to show inventory levels. Even then, you will want to work with
your IT group to discuss the risks.
UITableView
The UITableView is the basis for presenting data to users. This data can come from any source. As long as the data is readable, we can display it to
the user, as the example in Figure 1 shows.
Figure 1: Displaying data using UITableView
First off, let's do the basics. We'll open up the .xib file in a basic project. Then we'll drag a UISearchBar and a UITableView into our window design
surface. In my example, I've created a couple of outlets. The UITableView is searchTable, and the UISearchBar is searchTerm. Now that you have created
these, save and close XCode.
At a high level, let's look at my code for wiring this up in my controller class, shown in Figure 2. With this code, we've created a new TwitterSearch
object and will be using it to perform searches against Twitter. The search object will perform the calls asynchronously.
When the user clicks on the search bar to perform an actual search, the StartSearch method is called. Inside the StartSearch method, the call to the
Twitter Search API is made asynchronously. The code inside my search class looks like that in Figure 3.
Once the data is returned asynchronously, we then call ProcessRestXMLLinqHttpResponse, which will process it using LINQ to XML to create the necessary
objects. Both of these methods are used to make the call and process the results and should look familiar to .NET/C# developers.
The next high-level step in the process is to create a data source object. On my searchTable object, I will set the DataSource property and then call
the .ReloadData() method. For ASP.NET Web Forms developers, this is very familiar. We do the same thing when binding data to a GridView, where we set
the .DataSource property and call .BindData() on the GridView.
Now, let's jump into the iPhone-isms. The first obvious one is InvokeOnMainThread(delegate). We have to remember that we are running on a non-UI thread
when we are making asynchronous calls. If we want to write to a UI element, we need to do it from the UI thread. This is done via the
InvokeOnMainThread method. If we don't use InvokeOnMainThread to write to the UI, we will either get an error, or we won't get anything to happen.
Note: If you are using threading in your MonoTouch application and nothing happens, you probably need an InvokeOnMainThread method call somewhere in
your code.
Let's dig into our data object that we are going to bind against. Figure 4 shows the object that I've created. The result of running this code looks
something like the screen shown in Figure 5.
Figure 5: Twitter search results
Congratulations, you've now got a query running against the Twitter Search API. You are pulling the data back, binding it to the UITableView, and
displaying some data to the user. This is a good first step, but it's just a first step. Let's look at some of the more interesting things that we can
do.