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:
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
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 asp.net level instead of the iphone.
this is very secure in that only the registered iphones will get in.
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
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.
1st Guard Corporation