Lots of platforms, same core codebase, best strategy?

Question

I am developing a small web app. There isn't any advanced functionality, just basic queries from a database.

The website itself allows log ins via usual means and Facebook Connect, it then has some CRUD functionality.

I will be creating a 'native' Facebook app for it, aswell as an iPhone application and an Android application.

My question is, what's the best way to maintain the codebase?

I have done this before where I created a basic API that allowed me to add, edit and delete database records, and I then used HTTP POSTs to the API across all platforms. This made it extremely easy to maintain the codebase, fix bugs, make updates, etc, as I only had to update one place. The individual apps themselves only really had some skinning and then some cURL requests. Although this worked great for the mobile apps (iPhone and Android), it did make unnecessary http requests on the website and Facebook app.

What is the best way to approach this situation? Should I create 2 websites (Facebook and normal website) and an API? This would make it more difficult to maintain, but much more stable and faster. Just an API, which would make it easy to maintain?

The codebase is PHP in CodeIgniter with MySQL as the database.

Answer 1

I think you should create an API with php classes, and then have a HTTP API wrapped around it.

PHP class API:

<?php // myproducts.class.php

class MyProducts
{
  static function addProduct($name, $price)
  {
    // add the product
  }
}

And then your HTTP API:

<?php // api/products.php

// read HTTP POST and decode it as json
$postParams = json_decode(file_get_contents('php://input'));
if (!$postParams)
  throw new exception("Could not decode POST data, invalid JSON.");

// run the desired action
$classMethod = $postParams['action'];
$arguments = $postParams['arguments'];
$result = call_user_func_array(array('MyProducts', $classMethod), $arguments);

// print result as JSON
print json_encode($result);

With this, you can easily write an obj-c class to talk to the HTTP API. It might look something like:

NSData *postData = [@"{\"action\": \"addProduct\", \"arguments\": [\"Foo\", 42.00]}" dataUsingEncoding:NSUTF8StringEncoding];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:API_URL cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:60];
[request setHTTPMethod:@"POST"];
[request setHTTPBody:postData];
NSHTTPURLResponse *urlResponse = nil;
NSError *error = nil;
NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&urlResponse error:&error];

NSLog(@"response: %@", [[[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding] autorelease]);

Obviously you'll want to find an Obj-C API for encoding/decoding JSON. I am using TouchJSON

Answer 2

We have been using Kohana since January. We moved from Codeigniter, and it is quite lovely. The cascading file system makes it easy to organize your code.

An example of multi-platform use is Android. We've pushed a majority of the logic into php, then we pull that into an Android WebView, with some helpers for connectivity and speed, and it displays like a native app.

With Kohana, just create a JSON view for API calls. You can check the request to see if it is AJAX to decide whether to use a JSON or other view.

To decide between browser or mobile app, we set a user agent string unique to our mobile app, then test for it php-side. Also, we have a view hierarchy that lets us have a few different layout files. There is one for mobile requests, one for the web application, one for a certain type of user, etc.

Overall, Kohana is more flexible than Codeigniter, and a great base to build a web application and API on.

The downside to Kohana is that the documentation is rather poor. However, once you start using it, you will understand it quickly. The codebase is clean and easy to read through.

Sorry if I went on about Kohana to much, but, if you want to use php and have the flexibility you seem to crave, this is the place to start, IMHO.

Answer 3

I would take an N-Tier approach. Treat the "mobile" (iOS and Facebook) apps as the highest level tier. They spend most of their time displaying data and getting input from the user. Through a healthy dose of AJAX, they work with the PHP app, who serves as the "Controller" handling business logic and dealing with persistence & concurrency. Yes, there is a lot of data flying around, but don't optimize prematurely. As you develop your app, think of where you can cache data, and as you find excessive requests, optimize in later versions. Unfortunately, there is really no entity-relation manager that crosses the Javascript/PHP boundary, so it's roll-you-own for awhile.