Shared by manginiToday, we’re pleased to announce our new orkut Java client library!
OOOOHHHHHH! At last!
CreateAlbumTx createAlbum = albumsFactory.createAlbum(
"College Days", "The best days of my life!");
Album album = createAlbum.getAlbum();
albumsFactory.shareAlbumWithFriends(album);
byte[] photo = captureImage();
photosFactory.uploadPhoto(album, photo, ImageType.JPG, "My Best Buddies");
GetScrapsTx scraps = scrapFactory.getSelfScraps();
for(int i = 0; i < scraps.getScrapCount(); ++i) {
ScrapEntry scrap = scraps.getScrap(i);
if(myFriends.contains(scrap.getFromUserId())) {
scrapFactory.replyToScrap(scrap, "hey, thanks for remembering me!");
} else {
scrapFactory.replyToScrap(scrap, "wanna be friends? [:)]");
friendsFactory.sendFriendRequest(scrap.getFromUserId());
}
}
Dropbox, the free, web-based file backup service, has rolled out a new API that gives developers a way to access, edit and save any file in a user’s Dropbox account.
The Dropbox API works a bit like an Amazon S3 storage bucket except that you, not the application in question, have control over your uploaded files.
The Dropbox API uses familiar tools like JSON, OAuth and OpenID, so web developers can essentially offload their user’s storage needs to Dropbox. For users, the usual risks of tying your web app to a cloud storage mechanism are mitigated by the fact that Dropbox keeps a local copy on your hard drive.
While the potential for integration with web apps is very cool — imagine if all your Flickr uploads automatically synced to the Dropbox folder on your hard drive for an instant backup — the first place you’ll likely see the Dropbox API in action is on mobile devices.
Storage limitations and, in the case of the iPhone/iPad, Apple’s imposed restrictions, mean that it’s difficult to build mobile apps that can access local files, let alone read, write and sync.
That’s the basic problem the Dropbox API seeks to overcome — using the Dropbox API means there’s no need for local files on your mobile device and everything is automatically synced back to your PC. The only catch is that you need an internet connection for the syncing to work.
Dropbox has already worked with a number of developers to integrate the new API prior to the launch. For example, Air Sharing, GoodReader and QuickOffice can now tap into your Dropbox account to edit and sync your Dropbox files. The new API ships with client libraries in Objective-C (pretty much required for the iPhone/iPad), Python, Ruby and Java. To create an application you’ll need to register with Dropbox and then, once you have access, you can grab the client library of your choice and check out the online documentation.
See Also:
Occasionally I write more geeky posts that I don’t expect all my readers to understand. I’m going to start prefacing those with “Geeky:” so you can know to ignore them in the future. This is obviously one of those, so if the title doesn’t make sense to you, I don’t blame you for skipping over it all.
I have started playing recently with Facebook’s new Open Source Javascript Client Libraries. It has actually been quite fun to work with, in that they separate all the code out in a manner that’s easy to access, read, and understand how it works. Also, if I ever choose, I can host the Javascript files themselves on my own servers and reduce that potential failure point were Facebook’s servers to go down. (granted, you’re still relying on the Facebook API for them to work fully) I can also contribute to the source in the event I feel something might work better (via my own Github fork).
One problem I’ve come across with the new libraries is that they have simplified the Javascript session cookies so that rather than 5 or 6 separate cookies all getting set and needing to be parsed on the client in order to identify the authorized user, only one cookie is set, and can be parsed using simple URI string parsing functions. This is actually a bonus in that there is less work to be done to authorize the user. However, it means any old server-side clients that parse those cookies the old way will also need to be modified. If you don’t modify your server-side client library to recognize the new cookies, your libraries will not be able to authenticate or authorize the user properly.
I needed a solution for the server side that worked well with the new format. The specific code I’m writing is in PHP so it made sense to go with Facebook’s default PHP libraries, and I created a version of facebook.php that worked with the new Javascript SDK. To set it up is simple – just take this file, unzip it, and replace the facebook.php in your default PHP Facebook client library install with the one you just unzipped.
Unfortunately, the file isn’t backwards compatible, so you will need to choose between either the new Open Source Javascript SDK or the old Facebook Javascript Client libraries. This is because if you use the new Javascript SDK when you log the user out it only deletes the new format of session cookie. Your PHP Client Libraries will set the old format if you don’t replace them with the version above.
There may still be a way to make all this backwards compatible, but for my purposes I haven’t had need to look into it. Also, I’ve only tested this for my own use-cases, so there may be bugs. Please send me a patch if you find any bugs and I’ll update my own version of the file. As soon as it’s possible hopefully we can get this into the Facebook version as well. I’m going to also update the Github Wiki for the new Javascript SDK so others can benefit.
Let me know if anything needs to be updated. You can download the zipped facebook.php file here.
Geeky: PHP Client Library That Works With the New Facebook Javascript SDK
- Rob Diana
Cloud computing is big right now, but the sheer number of options, and the lack of interoperability, can be an issue for developers. Vendor lock-in reduces the options available to those working on cloud computing initiatives, while the variability between APIs inevitably leads to many hours spent pouring over documentation when comparing cloud service providers.
There are a number of projects that can reduce, or even eliminate, some of these problems by exposing the functionality of a number of cloud service providers through a consistent interface. Here is a list of 7 such projects.
Just as with the growth of these cloud APIs and platforms, there are more libraries and abstraction initiatives all the time. Feel free to share any others we missed in the comments.
