The Old Blog Archive, 2005-2009

Archive for September, 2006

ObjectiveFlickr: One note on callMethod:arguments: method

A quick note there. You may have noticed the callMethod:arguments: method in OFFlickrAPICaller class takes an NSString and an NSArray. Normally you’ll pass make the keys and values into an array and pass it to the method. There is one thing that ObjectiveFlickr has done for you.

For those who have played with Flickr API, there are some API arguments that take a list of photo id’s (flickr.photosets.editPhotos comes to mind). Now, we all love using NSArray to store those photo id’s. But to concatenate them into a comma-delimited string is a pain. So ObjectiveFlickr has done that for you. Simply call:

NSArray *somePhotoIDs; // let’s say 123, 456, 789
[apicaller callMethod:@"flickr.photosets.editPhotos" arguments:[NSArray arrayWithObjects:@"photoset_id", myPhotoSetID, @"primary_photo_id", myPrimaryPhotoID, @"photo_ids", somePhotoIDs, nil]];

And ObjectiveFlickr will expand somePhotosIDs into “123,456,789″ for you. Automatically!

Objective-C-native flavor will also work:

[apicaller flickr_photoset_editPhotos:nil photoset_id:myPhotoSetID primary_photo_id:myPrimaryPhotoID photo_ids:somePhotoIDs];

Note that since Flickr API is case-sensitive, you may want to be careful about the cases in the method signature above. In the future I might add some error checking to prevent debugging hell caused by typos.

ObjectiveFlickr: ContactsBrowser Demo



ObjectiveFlickr: ContactsBrowser Demo

ObjectiveFlickr is an OS X framework now. The project file that resides in its Google Code respository now builds the whole things into a nifty ObjectiveFlickr.framework. You can then in turn incorporate it into your own Flickr desktop application.

Currently the project file also builds two other demos. FlickrBasics is what I have done two weeks ago, using the basic “building blocks” (OFFlickrAPIContext, a URL generator, and OFFlickrRESTRequest, a HTTP request wrapper). Another new demo, ContactsBrowser, is a very simple table view that lists all of your contacts. A separate login sheet now guides the user through the interesting Flickr authentication process. That component should be able to be reused in your project, too.

A few notables things happening around the source code.

First of all, a whole new class called OFFlickrAPICaller. This is the “higher level” API wrapper that I’ve been talking about in the last few posts. Now it’s there. Once you have created your API context object (which handles API Key, Shared Secret and your obtained Authentication Token), pass it to your caller object, and then it’s done. Use the callMethod:arguments: method to perform any Flickr method–it takes care of the authentication and signing for you, so just pass the needed arguments. Some Flickr methods behave differently when authenticated, if you want to do that, pass an “auth” argument with any parameter, for example:

[apiobj callMethod:@"flickr.photo.search" arguments: [NSArray arrayWithObjects:@"tags", @"mac", @"auth", @"yes", nil]];

Which behaves slightly different from:

[apiobj callMethod:@"flickr.photo.search" arguments:[NSArray arrayWithObjects:@"tags", @"mac", nil]];

Secondly, OFFlickrAPICaller accepts two flavors of callbacks. One is to use the plain-vanilla set of delegate methods:

- (void)flickrAPICaller:(OFFlickrAPICaller*)caller didFetchData:(NSXMLDocument*)xmldoc;
- (void)flickrAPICaller:(OFFlickrAPICaller*)caller error:(int)errcode errorInfo:(id)errInfo;
- (void)flickrAPICaller:(OFFlickrAPICaller*)caller progress:(size_t)receivedBytes expectedTotal:(size_t)total;

When you receive the message, you can use the userinfo (by calling [caller userInfo]) to retrieve the state information you’ve given prior to the calling.

But, it’s always nice to have more than one way to do it. We can use a designated method for a given call, so long as the handler method matches the signature “- (void)foo:(OFFlickrAPICaller*)caller bar:(int)errcode blah:(id)data”:

[apicall setSelector:@selector(handleFrob:errorCode:data:)]
[apicall callMethod:@"flickr.auth.getFrob" arguments:[NSArray arrayWithObjects:@"frob", aFrob, nil]];

So for different Flickr API calls you can have different handlers respectively, instead of cramming everything into a single flickrAPICaller:didFetchData:.

Thirdly, since we are using Objective-C and Objective-C has this nifty thing called categories, we can use it to convert an XML document into a dictionary:

- (void)handleGetContacts:(OFFlickrAPICaller*)caller errCode:(int)errcode data:(id)data
{
// error handler…

NSDictionary *d = [data flickrDictionaryFromDocument];
}

The conversion follows the convention set by BadgerFish. I didn’t handle namespaces though.

Finally–and I’ll call it a day after this–you don’t really have to use the callMethod:arguments: to perform a Flickr API call. Instead, you can do this:

[apicall setSelector:@selector(handleFrob:errorCode:data:)]
[apicall flickr_auth_getFrob:@"foobar" frob:aFrob];

But I didn’t implement all of Flickr’s API calls (there are 95 of them!), but instead used Objective-C’s method dispatching mechanism to do the magic for me. Pass any unknown method to any OFFlickrAPICaller object, and it translates the method into a proper Flickr API call. Pass anything as the first argument, and it will become your userinfo. So the above snippet is the equivalent of:

[apicall setSelector:@selector(handleFrob:errorCode:data:)]
[apicall setUserInfo:@"foobar"];
[apicall callMethod:@"flickr.auth.getFrob" arguments:[NSArray arrayWithObjects:@"frob", aFrob, nil]];

The compiler will complain the receiver may not handle flickr_auth_getFrob. I’m still looking for ways to turn it off.

But, so much for today. There are still other works to be done, esp. more documentation, code comment, and more example. I’d be eager to hear if this framework is helpful in building real apps. As always, comments and feedbacks are always welcome!

Update on ObjectiveFlickr: New Build System

If you’re tracking the subversion repository of ObjectiveFlickr, here are some highlights of the past week’s update:

  1. A new “build system” is there. I have spent some time rearranging the Xcode project file. Now it builds ObjectiveFlickr.framework along with some demo apps that I’m working on. The framework works fine either in /Library/Frameworks or as embedded framework.
  2. ObjectiveFlickr itself is completely rewritten. I have separated application context (API key, Shared Secret and Auth Token) from request-related tasks.
  3. Use some svn:ignore property magic to reduce commit annoyance. There is still one file that is not ignored by svn. That’s because svn can’t ignore files already under version control. :(
  4. More works ahead, including some more mature demo app, and some “application-grade” classes. Right now the framework is still very “low-level”. With OFFlickrApplicationContext and OFFlickrRESTRequest, you still have to handle the URL perparation and payload extraction on your own. Another wrapping layer should reduce the pain.

So much for the weekend. Enjoy. :)

ObjectiveFlickr with Uploading Feature



ObjectiveFlickr with Uploading Feature

Originally uploaded by lukhnos.

After a weekend of trial-and-error, a very rough version of FlickrUploader class is added into the ObjectiveFlickr project. It follows the delegate pattern. Once the upload process begins, upload status will be reported to the delegate until the whole thing is done (or interrupted because of user cancel or Flickr error).

Once again, the latest demo can be downloaded here, and the source code can be found at Google Code hosting.

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!)

Friday Night Usher (Fiction)

(r and I were playing this silly word game and suddenly this short piece got its own shape. The last time it flowed out so naturally was in 2001. So here it is.)

I used to be a Friday night usher when I was an exchange student in Tokyo. There is a Japanese saying that goes, “Only those without boyfriends work as Friday night ushers.” How true.

The theater was located in a shabby apartment in the hustle-and-bustle district of Shibuya-ku. It specialized in gay porns, or “pink movies” in Japanese. As for why such a theater needed a girl usher remained a mystery. I was 15 then. It is hard to find a decent baito, or a part-time job, when you are 15, unless you want to do McJobs greeting customers with McIrashaimase‘s. It is especially hard when you are a gaijin. I was young, fearless and curious about the world. So when I was offered the job I was happy to take it. And anyway I could watch films for free, even if they were gay porns.

Sekuhara, or sexual harasssment, was not a problem in such a theater. There was really only one downside about this job, and it was that, sometimes the theater would rerun the same film so often, that eventually I could recall every line of, say, “Harajuku High School Student Sprees” (there weren’t that many lines, anyway). But I could reassure you, the actors therein were well over 18, that no sane person would ever believe those were really high school student sprees. Still, what is theater (or film) if you don’t have faith in things not real?

Sometimes there were porns that were obscure. Some of them were trying to be arty, and some of them really were. Occasionally there was one film that had a plot like those of Kieslowski’s La double vie de VĂ©ronique or Shunji Iwai’s Love Letter. There was even a film noir porn that was probably made in the late 1950s, with all the montage techniques that you could find in Battleship Potemkin, but had a plot set near the end of the Edo Bakufu era and colored by some chanbara scenes here and there! And if you still believed what I said, you would suspect if those were really gay porns. I had to say I was bewildered, too, when I was watching that very film, e.g. one nude 40-something aniki engaged in chanbara fights with a juicy (relatively so in that era) late 20-something. Perhaps the film tried to work on the level of metaphor. I just didn’t get it.

At this point you might wonder how I reacted to the scenes in the theatre. You know what I mean by that. I wouldn’t say I didn’t see anything, but I didn’t care much either.

There weren’t many young people that frequented such a theater. Pink movies were already in decline when I was in Japan. Naturally I didn’t expect to get to know anyone either. There was once, though, that I met a university student (claiming he studied at Waseda) there. He was totally out of that place, as he didn’t seem to blend in well the toilet scene there. He visited there a few times and eventually we exchanged snail mail addresses.

I worked there as a Friday usher for around 4 months. Later a fellow exchange student referred a Lawson job to me. I had memorized enough film lines, and the timing was good for a change. For some unknown reasons, I still wrote New Year cards to the university student. I never received his card in return until last Christmas. Then I received a beautifully printed card. It was a wedding invitation, with his name on it. With a woman.

There was no point to go to the wedding, as I didn’t really know him. Still I wrote him a thank-you card, thanking him for inviting me and wishing them well. Writing that card, somehow I felt a little sadness inside, as if I missed or lost something.

Ah, atashi tachi no fiaresu na seishun jidai (we girls’ fearless youth).