Last night Apple missed their fortnightly update to the iPhone OS 4.0 beta program. Apple has managed to hit this schedule for the past 2 months since the announcement of 4.0. Earlier yesterday I speculated around whether or not we would see an update:

“I wonder if Apple will hold back another beta for iPhone OS today and release at WWDC to intro new hardware APIs?”

I may be completely wrong on this one, but let’s look at the facts (ahem rumours). Apple are probably 95% going to launch the ‘iPhone HD’ or whatever they want to call it at WWDC next week. Based on the lovely Gizmodo leak, the device has a front facing camera. John Gruber has also speculated (and various rumours appear to confirm) that the device will also house a “HD” screen.

Both of those would require software/API changes to utilize. Firstly, the front facing camera would require an update to the iPhone UIImagePickerController API which currently enables applications to hook into the camera on the back to capture image and video. Somehow, Apple would need to change that so you can select which camera you want to use front or back – perhaps both?? Who knows?

Potentially though, Apple could release the new hardware without having the front facing camera accessible through developer APIs at this stage. It’s unlikely, but could happen.

In addition to this, the new ‘HD screen’ has the potential impact on 3rd party applications. Unknown yet is how Apple would scale up current standard definition applications for previous iPhone devices. They could use the iPad method of scaling up, however as a developer I’m really concerned by that approach, as in many cases it turns out pretty ugly.

More likely is XCode and Interface Builder are updated to support this new resolution, so you can rebuild your app’s UI. Perhaps going forward we will build to the new resolution, and the older phones will scale down? That’s certainly my preference…

Anyway, suffice to say with WWDC being 1 week away it seems logical that Apple would hold back any update to iPhone 4.0 beta until Monday 7th June. After all, there are potentially other software additions for the new device that go beyond just hardware that have the potential to have APIs. It would make sense to have all of that “available now”, as Jobs finishes his keynote.

More importantly though, let’s hope that ‘iPhone HD’ is available now.

Ajax is a wonderful technology that is heavily used in many places nowdays. Ajax is run in the browser using javascript to call a URL, and usually receive data back. One of the key restrictions of using Ajax to get data from a remote URL is that you cannot make cross-domain calls. This meaning, you cannot make an ajax call to domain1.com from domain2.com because of browser security restrictions. The workaround, is to make the cross domain ajax calls from your web server rather than the browser, and all is fine!

That was, until the introduction of JSON, and more importantly JSONP which allows you to make ajax calls to 3rd party domains from within the browser itself. What this means for you is that you can get data from JSONP supported APIs from within the browser itself, rather than telling your web server to do it for you.

This is also important for Twitter API usage. One of the key restrictions with the Twitter API is that any client IP address can only make x number of API calls per hour. If you’re making these API calls from your web server (which obviously only a static IP address), you could quickly use up your hourly allocation on a busy site. Twitter does allow you to “whitelist” your web application to give you a better hourly rate, but here’s a better way:

Use the clients, ie your users, to make the API calls from their browsers.

Admittedly, my example below is for any API calls that do not require authentication, however what it does enable you to do is to empower your user to make Twitter API calls in the browser using jQuery. So without further ado, here’s the code snippet:

$.getJSON("http://twitter.com/statuses/user_timeline.json?screen_name=SteveReynolds&callback=?",

function(data){

$.each(data, function(i,item){
$("#tweets").append(item.text + "<BR/>");

});

});

What the code above assumes is that you have a <div id=”tweets”> or something where you can append the results, in this case the object in the JSON response “item.text” which is the tweet itself. You could for example, get “item.user.name” which would return the username for each tweet (which is useless as you know it’s all my tweets ) – but you get the idea. You also need to make sure you have previously called the jQuery library.

The other important factor of the code above is the URL we are using to call Twitter. We have appended “&callback=?” onto the end of it. This is to allow the jQuery call to pass the returned data to a callback function, which in this case is simply called “data” for the returned data, and “function()” for the callback.

Download the code here.

So, that’s it. It really is that simple. In my next tutorial I will show you how to do the above, but ajax it back to your server and save it to your database – in effect getting your users to do a lot of the hard work for you in the browser, and simply sending back the relevant results to your database.

In my previous jQuery tutorial I discussed how you can authenticate against the Twitter API to retrieve personal data. However, what we didn’t do is show you how to POST data back to Twitter, like tweeting. It’s actually very simple, and can be done by quickly updating your cURL script in PHP.

cURL POSTFIELDS

<?php

$username = "yourusername";
$password = "yourpassword";
$twitterHost = "http://twitter.com/statuses/update.xml";
$yourStatus = "Hello - I am Tweeting from my custom script!";
$curl;

$curl = curl_init();

curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($curl, CURLOPT_HEADER, false);
curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_USERPWD, "$username:$password");
curl_setopt($curl, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
curl_setopt($curl, CURLOPT_POSTFIELDS, "status=". urlencode(stripslashes(urldecode($yourStatus))));
curl_setopt($curl, CURLOPT_URL, $twitterHost);

$result = curl_exec($curl);
$resultArray = curl_getinfo($curl);

if ($resultArray['http_code'] == 200) {

echo "Success!"

} else {

echo "We have failed... oh no!";

}
curl_close($curl);

?>

This script is very very similar to the last one we discussed. All we have changed is the Twitter API url, and added an additional cURL statement to add POSTFIELDS to the cURL call. Very lovely!

Conclusion

That just about wraps up my 3 part tutorial on how to work with the Twitter API with PHP and jQuery. I hope you enjoyed the set, and please feel free to add your own feedback and comments below.

Further Reading on this topic…

Developing the Twitter API	Practical Web2.0 with PHP	PHP Web Development

In my previous post on this subject I spoke about making a simple call to the Twitter Search API to return some results every 30 seconds using jQuery and ajax. This time over I am going to discuss a similar process, however this time our API calls are authenticated with our Twitter credentials (to return your favorites in this example). So here goes…

PHP and cURL

Again I am going to use PHP with cURL to communicate with the Twitter API as well as return the XML. Here’s the code – create it in a file called getFavorites.php :

<?php

$username = "yourusername";
$password = "yourpassword";
$twitterHost = "http://twitter.com/favorites.xml";
$curl;

$curl = curl_init();

curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($curl, CURLOPT_HEADER, false);
curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_USERPWD, "$username:$password");
curl_setopt($curl, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
curl_setopt($curl, CURLOPT_URL, $twitterHost);

$result = curl_exec($curl);
curl_close($curl);

header('Content-Type: application/xml; charset=ISO-8859-1');

print $result;

?>

There’s alot here, the key parts being the first 3 variables, your username & password, and the API url. There are alot of cURL bits involved here, I won’t go into them, but you can read more about them here.

The jQuery

The jQuery part is actually pretty similar to my last article, all we’re going to do is change the XML node names for this particular API call… Create this in a file called controller.js :

$(document).ready(function() {

getFavorites();

});

function getFavorites()
{
var results;

$.get("/getFavorites.php",  function(xml){
$('status',xml).each(function(i){
var title = $(this).find("text").text();
results = title + "<BR>";
});
$("#container").html(results);
});

}

All I have really changed is to iterate through each <status> node, and get each <text> child node from that. The <text> node holds the text of your favorite tweets. We’re also posting the results to a #container DIV again.

The HTML

This is actually exactly the same as the last tutorial, but i’ll re-post it here just for fun!

<HTML>
<HEAD>
<script src="http://jqueryjs.googlecode.com/files/jquery-1.3.1.min.js"></script>
<script src="controller.js"></script>
</HEAD>
<BODY>

<DIV id="container"></DIV>

</BODY>
</HTML>

There we go – done! Authenticating successfully to the Twitter API via PHP, with our jQuery happily rendering the XML returned via a GET ajax call and posting it back to our HTML document. The jQuery involvement is very loose in this example, as it really actually isn’t needed – but you get the idea on how you can integrate the ajax calls and build on up form there to do really cool things!

As always, here is the code to download to try it yourself

Tools to help you learn:

Learning jQuery	Amazon Kindle 2	jQuery Reference Guide

So for today’s blog post I am going to show you how you can use jQuery, PHP and a little ajax to connect up to the Twitter API and return results. I’ll cover off unauthenticated calls today to the search API, and follow up with the authenticated piece a little later, so watch out for that!

PHP using cURL

So, in order for us to talk to the Twitter API, we need to use cURL. This isn’t a hard and fast rule, but it sure does make our lives easier. The cURL library should be installed as part of your PHP installation, but do check.

cURL allows us to make a simple call to the Twitter API, and grab some results back if necessary. I’ll be using XML to return results for this demo, but you can use JSON if you want. Anyway, without further ado, here is a nice piece of PHP code to talk to the Twitter Search API – so create a file called getSearch.php :

<?php

$query = $_POST['query'];

$curl = curl_init();
curl_setopt ($curl, CURLOPT_URL, "http://search.twitter.com/search.atom?q=" . urlencode($query) . "&amp;amp;amp;rpp=10");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);

$result = curl_exec ($curl);
curl_close ($curl);

header('Content-Type: application/xml; charset=ISO-8859-1');

print $result;
?>

So, lets quickly explain this. The PHP script will take POST data, in this case a query, and send the query to the Twitter Search API. The Twitter API is also taking an rpp parameter, which is the number of results to be returned. It will then return XML, and also print it out as a valid XML document. Job done. Obviously there is no error handling, this is the bare bones – I will let you deal with all of that!

The jQuery

The jQuery side is also pretty straight forward… It’ll do an ajax post call to our PHP script, and go through the XML returned and paste it into a location in your DOM HTML. So, create a controller.js file and put this code into it:

var timer;

$(document).ready(function() {

getSearch();

});

function getSearch()
{
clearTimeout(timer);
var results;
var theQuery = "stevereynolds";

$.post("/getSearch.php", {query: theQuery},  function(xml){
$('entry',xml).each(function(i){
var title = $(this).find("title").text();
results = title + "<BR>";
});
$("#container").html(results);
});

timer = setTimeout('getSearch()', 30000);
}

So this code sets the query parameter to “stevereynolds”, makes an ajax post to our getSearch.php file, and then runs through the returned XML. It firstly searches for the “entry” node, and then the “title” parameter as part of each “entry” node in the XML. Lastly, it applies the results to a container in your DOM called “container”. This function also runs every 30 seconds, see the setTimeout for that part.

Putting it all together

So, putting it together is pretty darn easy. Create an HTML page in the same directory as all of the above, with the following:

<HTML>
<HEAD>
<script src="jquery-1.3.1.js"></script>
<script src="controller.js"></script>
</HEAD>
<BODY>

<DIV id="container"></DIV>

</BODY>
</HTML>

Thats it! When you load your HTML it will call the controller.js -> which in turn will call the javascript function getSearch() to return Twitter Search API results every 30 seconds.

Feel free to download this code and reuse as you want. As I said, it’s very simplistic – so go ahead and adapt this with lots more jQuery lovelyness! Feel free to share back your fine work! Also see my new article discussing making authenticated calls to the Twitter API.

Further Reading:

Learning jQuery	Amazon Kindle 2	jQuery Reference Guide

Scary news out of Twitter HQ this week, they’re limiting their API access for whitelisted application to 20,000 calls per hour! This is very bad news for developers of 3rd party applications, especially if they planned on the masses embracing their apps.

The requests are restricted to an IP/User, so I guess we have 2 scenarios

1. Application is on a device (iPhone / PC)
2. Application is on the web

I imagine device applications would be ok. Clients are restricted to 100 API calls per hour though, but all the API calls would be coming from different IP addresses.

Web applications are likely going to be a different story. What if all your API requests come directly from your one web server? 2000 users * 10 requests in an hour isn’t much! Especially if your application is aggregating data in the background which also uses the API.

Twitter really need to focus on this limitation, and try and give developers more. They’re struggling to monetise the site as it is, so restricting 3rd parties from using their product isn’t an ideal scenario for your potential future paying customers.