Another interface between Flash and Flickr
This page provides an introduction to an interface I am writing between Flash and the Flickr API. It’s something I’ve been thinking about for a while but which got stuck on the back burner. Seeing inspiring stuff like Flickr graph from Marcos Weskamp has made me decide that I should try and get this out there.
After writing this page I’ve realised that it has ended up much longer than anyone probably wants to read… If you aren’t interested in my motivation then skip down to the example and if it looks like something you might be interested in then you can check out the documentation as well – although that’s maybe even longer.
But there are already (at least 2) Flash interfaces to the Flickr API! Why would we need another one?
I started out using flickr api and found it useful. Then I came across a method on the Flickr API which hadn’t yet been implemented in “flickr api”. So I implemented it myself. But doing this I became frustrated and decided there must be an easier way…
I wanted an API which could give me variable type checking on all the things I was passing to Flickr and which would do any necessary XML parsing for me without me having to think about it.
I also wanted it to run in the Flash Player 6 (mamata’s “flickr api” could be fairly easily adjusted for this). And ideally to have things in place like a queue so I didn’t need to worry about waiting for one request to complete before sending the next one.
Another aim was to have good documentation so that someone could sit down with this system and by writing minimal AS2 code could have an application that interfaced with Flickr. The long term aim of all this is to be able to sit down and write some cool applications using the Flickr API… But first things first.
So how does my interface work? See the documentation for the gory details. [sidenote – I did the docs with Natural Docs – pretty cool actually!]
Basically there are two core classes: com.kelvinluck.flickr.Flickr and com.kelvinluck.flickr.FlickrResponseListener. The idea is that you create a Flickr object which you can then call methods on. This ensures that type checking can be done when making API calls to Flickr to catch author time errors. You then have an instance of FlickrResponseListener which listens for the responses from the Flickr API. By itself that isn’t much good for you – it just logs some messages (thanks to Colin Moock’s Logger application). But the idea is that you would either subclass FlickrResponseListener or would create an instance and override the methods that you are interested in.
I assume that this approach to this type of problem has been used before and has a name but I’m afraid I don’t know it. It’s kind of like an Java style interface in that I am describing what I expect the function you will write to accept as arguments although the compiler obviously won’t enforce this. You will, however, have the documentation and an argument list for your function so it should make it fairly easy to write the code…
Here is an example of my interface (damn – I need to come up with a more catchy name!) in action. Basically the drop down lets you pick from the functions of the API I have programmed (so far flickr.contacts.*, flickr.people.*, flickr.tags.* and flickr.test.*). Then the two text fields are the two (optional) arguments to the function you are calling. Your call and response are logged to the big TextArea. You can change the severity of the messages logged with the ComboBox at the top of the screen.
The relevant code in this example application is very simple:
var _flickr:Flickr = Flickr.getFlickr();
_flickrResponseListener = new FlickrResponseListener();
_flickr.apiKey = "YOUR_API_KEY";
// and on the event handler for the "Go" button
But where is the code? I’m going to release it when it is a little bit more finished. I wanted to show the docs and example at this stage to try and gather some feedback on the general approach.
Do people think my approach is useful – would you be more likely to use this library than one of the existing ones? What do you think is good/bad about this way of approaching the problem? Have you got any suggestions for a better way of structuring the code given the requirements?
If someone can convince me that another approach to the problem is better then they will save me the time I’ll spend adding the rest of the API calls to the library. If people like the approach it might give me the kick up the arse I need to get round to completing this… So – feedback of any sort appreciated! Use the comments form below or email me – kelvin at kelvinluck dot com :)