Tech Talk

Skip Navigation Links
1st Guard Home
iPhone Development
Corporate Web Services
Truckers Need iPhones Too
Credit Card Storage
SEO Optimization
Technorati Profile

iPhone Development - RSS, XML, ASP.NET and Generic Handlers

As soon as your boss gets an iPhone, he's going to be asking you how to get to your corporate data from the road. Good side is that you'll need to get both a Mac and an iPhone but then you need to make it all happen. We focused on delivering a solution quickly that was very simple, adjustable and quick to market.

Specifically for us, we have corporate statistics that our executives wanted to be able to view easily from the road without having to boot up a laptop, find wireless, login to our web app, navigate to the statistics page... you know the drill. Instead, they should be able to pull their iPhone out and push a 'stats' button. Boom! There are the stats.

Many people are searching for the golden sample iphone application that they can model and forget that there is back-end infrastructure required to feed that data to the requesting iPhone. To get that done, you're probably already thinking a nice web service feeding back XML. SOAP comes to mind but the current release of the iPhone SDK is light in support. This is where most people will direct you to using REST. REST is cool in that it is an URL based requestor but it takes a lot of work to set it up.

Remember that part of our goal is 'quick to market' so why not consider the generic HTTP handler that is in Visual Studio.

Here's what you do:

1. follow the sample for building an RSS reader and get it wired into your iphone. Follow it word for word and it will work great. Here is the link: [Click Here]
2. now in Visual Studio add a public generic handler. This will be a .ASHX file
3. in your SQL database, build a table that houses a user name to iphone ID relationship
4. edit the generic handler to take in two parameters -- one for the requested operation (in our case: stats) and one for the iphone ID.
5. if they are validated respond to them with the stats in XML using context.response
6. test this in your browser passing the correct parameters so you know it's
working before you start trying to hit it from the iphone.
7. now adjust your iphone app to use your new URL with parameters.

Once you get the basics working:

1. create a corporate db table that houses iphone ID to user Id relationships and check it as the first operation on the handler. This makes the handler extremely secure because you can't get past the front door without a valid iphone Id. BTW, we used UDID to get the addresses to be used. You have to do this for the ad-hoc provisioning anyway so you're doubly covered.
2. create a logging function that writes date, time, user, iphone and function to a table
3. enhance the iphone app to allow drill down capabilities (just another operation)

A couple of notes:

this is scaleable by way of the parameters passed.
you can adjust the output at the level instead of the iphone.
this is very secure in that only the registered iphones will get in.

Good Luck

Dan Ribar
1st Guard Corporation

Corporate Web services -- Connect by Disconnection

There will always be a need to give customers confidential and sensitive information from an Internet based Web Server & application. Historically all of this logic has resided on the web server, but there are new ways to disconnect the Internet from your sensitive information and still give the customer what they want.

One great way to protect your Internet website is to eliminate all of the business logic from the site and rely on a corporate web service that is further back behind the firewall security level.

If you’re not too sure what a web service is, consider it to be like a secure web page that has no user interface. So I can get to most web services to see what they have to offer by keying them into my browser, but daily operations are all in-band – no user interface.

One example of a web service might be to calculate a customer’s current balance. The old style would be to put the SQL statement as well as the communications parameters (including login and password) to get to the SQL server right on the website. Now, this is the outside website, so it has a bit more exposure to the dark side of the Internet. This is actually very common practice and fairly secure, but there is a better way.

On your internal web server, create a web service that has the needed function – in this case a function called ‘GetCurrentBalance’. Inside of that function and safe from the Internet are all of the SQL statements, connection strings and business logic that will give the correct answer back to the requestor.

Your customer website that is looking for a balance, now asks a simple question to the web service, and presents the answer. There are a lot of other steps – mostly authentication and security related, but bottom line is that all of the confidential and business critical information has been removed from that exposed web server.

One tangential benefit is that you don’t need high-end programmers to write pages that ask for a current balance [for example]. One line that asks the web service can be handled by most 9th graders, so you can apply a bigger resource base against your projects.

One other hidden benefit is that although you have to (or should) write wrappers for these functions within the web service, your code base will get homogenized and consolidated into a single set of class libraries – something that is typically problematic when you have multiple web servers / applications. Microsoft and the world will tell you to compile and distribute these libraries, but it’s a forced way of doing things.

Disconnect your website by connecting to a web service.

Dan Ribar
1st Guard Corporation