iPhone development using standard web technologies

Fresh after giving my talk from BarCampBright4, I wanted to get my notes down from my session on iPhone development using standard web technologies. This all started when I wanted to do an iPhone application for my Latest Scores Twitter app. So I bought a book and made my way through it slowly, trying to decode Objective C before coming across the part I was really after, the UIWebView class.

What I ended up arriving at was the ability to load and render a HTML file with it's own resources imported such as CSS, Javascript and images. The real magic in Objective C is this:


NSURL *url = [NSURL fileURLWithPath:[ [ NSBundle mainBundle ] pathForResource: @"index" ofType:@"html" ]];
NSURLRequest *request = [NSURLRequest requestWithURL:url];
[webView loadRequest:request];


What this is doing is creating a URL with a resource on the path called 'index' with the file extension 'html'. Build a request from this URL and pass the request into the instance of UIWebView.

From that point, as long as all of the resources that the index page requires are bundled into the project, you can load the page and have that actually be the application.

So that's all nice if you have a certain type of application which doesn't require any device interaction. For example, if you had a blog/news site and wanted to make it into an application, you could just get the content and display. You can also change a few settings in a file called info.plist to set the icon image and application name.

That template project is available on GitHub, http://github.com/robb1e/iWeb

However, if you want device interaction you'll need a richer framework, and that's where something like PhoneGap.com comes in. With the abstracted Javascript file that works for iPhone, Blackberry and Android, functions are available to get access to the contact list, audio playback and other device features.

To play an embedded audio resource for example, you can write the following Javascript, provided you've included the PhoneGap.js file.


new Media('beep.wav').play();


With both of these projects there is one caveat with Xcode in that it wants to compile Javascript files. You have to make sure you set those files as resources to copy, not to compile. This can be done in the target list on the left hand side.

To extend the idea of using standard web technologies whilst not building web sites, this next example uses Adobe's AIR run time and the HTML, CSS, Javascript and image from the first example. This is also available on GitHub: http://github.com/robb1e/AirWeb

By creating the application.xml file, you can tell Air to launch a file as the initial content and that will be rendered using it's WebKit engine.


<content>www/index.html</content>


To run the desktop app, install the Adobe AIR SDK then run the command:


adl application.xml


This launches the application in debug mode. To create an Air file, you need to compile using ADT.

This has shown that using the same technologies and languages you'd use to build a web page can be used for both mobile devices with and without device interaction and client applications that are installed on a computer.

There are other ways of achieving the same result using Apple's web namespace tags in the markup with HTML5 tricks like offline storage. There's also other libraries like jQTouch, so check out what else is around too.

The "write once, run anywhere" idea may just be coming into reality .

Metadata Cloud Gaming

So, what the hell am I talking about? Let me give you a concrete example, and a personal wish list of mine for many a long year.

When I was growing up, one of the most capturing games was Championship Manager. This allowed the player to experience running a club, from transfers, tactics, training and more. However, the thing it always missed was being able to actually play the game. In terms of actually playing the game, when I was younger, the FIFA/EA Sports combo was hard to beat, although now I prefer the Konami Pro Evolution Soccer range.

I've always though that it'd be amazing to merge these two together, and I think now with Web2.0/Mashups/Cloud Computing and Web APIs this really should be possible. I could easily see a situation where as a gamer I could mash two of these together. For the tactical, and running of the game, I could use Championship Manager, and as a simulator for the actually games, I could use my game of choice. In this instance it really comes down to player stats. If I could load the game from Championship Manager, with the teams, players and 'stats' to boot, I could play out the game in my simulator and then upload the result along with accommodating stats into the cloud where my 'managerial' game could pick them up from, and vice versa.

Really, this is ripe for the picking.

The Great Twitter Camera Migration

I've just started a fun little side project called the 'Great Twitter Camera Migration', check it out: http://cameramigration.blogspot.com

XFM Bot

Just put together an XFM bot to scrobble the xfm.co.uk radio station recently played tracks and push that into Last.FM.

How compatible are you?

http://last.fm/user/xfmbot

Source code is here: http://github.com/robb1e/xfmscrobbler/tree/master

Vendor Driven Architecture

So, you have your off the shelf application driving some important business process, maybe it doesn't quite do everything you need so you think about altering the application through plugins, changing source code or otherwise. Some of these changes may drive you further away from that off the shelf's product road map, making upgrading later difficult and expensive. Perhaps you don't intend to alter the code, but you may think that later on there may be a better off the shelf product that suites the needs of the business and that changing solutions is the best thing to do.

Depending on how these tools are used really drives the way these tools should be deployed and designed into a business process. If you only have one client talking to this application, you probably don't need to think too hard about how to solve this problem. However, if you have multiple clients wanting to talk to this application, you may want to give it some thought. If you have multiple clients, accessing the application in multiple different ways, then you definitely want to think about this problem.

I'm not an advocate of big design up front, but what I'm proposing isn't that exactly. What I'm suggesting is capturing the data model and contract of interactions early and use this as a way of driving an abstraction layer between the off the shelf product and the clients using that product. By doing this, you've isolated the application, meaning you can upgrade easier even if there are breaking changes, and you can introduce additional application logic all behind the safely of a contract and data model. After you've done this, anyone who uses your abstraction layer, need not know what you're using underneath. The way it should be really. This also defines a contract for working against, meaning that applications who talk to the abstraction layer can be tested easier against known behaviours.

We can start to push the boat out a little here and start thinking about roles and policy for access. There maybe different types of clients and users who wish to use the abstraction layer, and they may have different permissions and access to different resources, so how can you control access and protect your resources? You may be able to control that at the application layer, but what if you've added plug ins or additional application logic layers? And what if you change the application which manages permissions, and how do you bind them to the resources at the abstraction layer? It may be better to think in terms of the abstraction layer and data model rather than what's behind the lines of the abstraction. This way, binding to resources will be easier to control. While we're dealing with authorisation, authenticaion doesn't stray far, you'll want a way to authenticate the clients and users attempting to use the abstraction layer, and you may want that authentication to come from multiple sources, say a database user store, or an internal directory service. This will make it easier for those users to gain access to the systems, and easier to administer access through roles and policies of clients and users.

What we now have is a platform. An off the shelf application with or without additional application logic, wrapped with an abstracted and understood data model which must be accessed via an authenticaion and authorisation mechanism. Put a bow on it, you're done.

Depending on your network security preferences, you could now expand this in two ways. For every off the shelf product you employ for different business processes, you could put an abstraction layer on it with an understood data model and give access to that abstraction via the same authentication and authorisation layer you've created for the first platform, or you could replicate the authenticaion and authorisation layer and have lots of self contained, secured platforms. It doesn't particularly matter which is employed, but what should fall out of this is a common data model across several platforms, with a uniform authentication and authorisation layer.

It does raise the question of why you'd want to be doing this in the first place, you are after all creating more work than strictly necessary. There is a temptation to say "if we're building this abstraction layer, we may as well replace the off the shelf component itself". Well, let's not get ahead of ourselves. We have to remember where the business value comes from, and that's generally in products and services, not business support and operational support systems themselves. However, by abstracting the applications used and exposing the data, the cost of integration, migration and maintenance is lowered. This model can be applied to internal exposures and for exposing data on the web.

I just want to close with what I believe is the most important aspect here, and this is the business case. There is a business case for abstraction, but it does come at a cost. What it brings is contractual interactions and can lead to common, agreed upon resource based exposure.