The Old Blog Archive, 2005-2009

ObjectiveFlickr, a Simple Flickr API Wrapper

I’ve made a very basic Flickr API framework written in Objective-C. I called it ObjectiveFlickr and the project, including the source code (released under the New BSD License), can be found at its Google Code hosting site.

To build the demo app from the source code, you have to first check out the code (of course), and fill in your own Flickr API key and “shared secret” code in ObjectiveFlickrDemoDelegate.m ; if you don’t, there will be compiling stage errors anyway. :)

A pre-built demo app can be found here. In the Flickr authentication page, you’ll be asked to give read permission to an application called FlickrVanilla. And there you go.

The demo app is quite rudimentary but shows the basic steps: obtaining a “frob”, finishing the authentication process by visiting Flickr, then obtaining the token (with it comes the user information). After that we can do what we want. I use WebKit to display the photos. Aesthetically it still needs some brush-up.

Note that this is a step-by-step demo. OS X Flickr apps usually combine frob-getting and authentication into one step using a modal dialog box, asking users to come back as the browser window is being opened.

I actually haven’t built the framework into an OS X .framework–yet. Right now it only consists of one .h and one .m and two classes. FlickrRESTURL is the “URL factory” that packages the Flickr API URL scheme together with API signing. Whereas FlickrRESTRequest packages NSURLConnection and some XML unpackaging utilities. It follows the delegate design pattern and uses informal protocol to tell the delegate if an XML document is being received, canceled, successfully received and unpackaged, or if there’s anything wrong (Flickr error codes are processed here too).

These two classes make very basic building blocks. As for the XML unpackaging, so far I’ve only done the one for authentication token and photos. There are other Flickr data blocks that we have to take care of.

Using these building blocks–”low-level” in a way–we can go steps further, and come up with, say, “higher-level” encapsulations, such as synchronous calls, API calls as Objective-C methods, or simply returning every Flickr response as pre-unpackaged Foundation data structures (I love NSDictionaries).

So much for now. I plan to build more things with it and improve the framework along the way (building a real .framework will be an immediate to-do). There will be bugs to fix and some more testings. Oh, and the documentation work (currently none). But here I will give it a go, releasing it into the wild. Patches, comments, or even commit rights requests are all welcome.

Thanks!

(ObjectiveFlickr uses Andreas Meingast’s CocoaCryptoHasing to do the md5 signing, Danke Andreas!)

2 Responses to “ObjectiveFlickr, a Simple Flickr API Wrapper”

  1. on 29 Sep 2006 at 10:29 amMathieu Tozer

    I’ve been playing with your to-be framework, but am having a few problems. It would be nice if it were a clean framework I could just plug in (sparke-like), but in the mean time, can I just have the code as a folder in my project or something?? Because doing that worked fine for debug but linking didn’t work.

  2. on 29 Sep 2006 at 10:55 amlukhnos

    Thanks for the interest in this project.

    As you can see, this project is in its early stage, so there are still many rough edges. In the latest source revision, I’ve made a few changes so that the project file builds a .framework that we can link to our project. A Sparkle-like framework is what I’m working towards.

    Meanwhile, you can indeed simply copy the files required to your project folder. These files are: ObjectiveFlickr.h, ObjectiveFlickr.m, OFFlickrAPICall.m, OFFlickrXMLExtension.m, and everything under CocoaCryptoHasing

    And don’t forget to link to libcrypto.0.9.7.dylib (if you’re working on Tiger) to make everything work. Apple’s “zerolink” works quite magic but is also very lenient on dependencies, and that’s perhaps it didn’t work when you make it to the Release configuration.

    I’m eager to know your opinion on how this framework can be improved or fill in the gap. If you still have problems on building, please do also let me know. Thanks again!