The Old Blog Archive, 2005-2009

Archive for the 'tekhnologia' Category

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

Learning from Others How They Do It

Caterina Fake taking notes from FOO camp. My experience at WWDC 2006 actually allowed me to see much of my under-preparedness. This reflected in my note-taking skill and the fact that I didn’t manage taking as many as I imagined I could.

Note-taking is a craft to be learned. It is also a lot of homework and preparation.

Before I wrap up my summary of WWDC Day 0-2…

It’s really taxing one’s strength to be able to keep one blog in two languages. I’ll try to come up with the English version of the WWDC Day 0-2 summary. For those of you who can read Chinese, here is the notes I’ve taken for the sessions on the Day 2 (within the terms a WWDC attendee is able to express).

OpenVanilla at WWDC 2006: Day -1

This is my first WWDC and second time visiting San Francisco, so while everything is for me fresh and anew, I’m also feeling kind of awkward walking around in a unfamiliar city embracing an equally unfamiliar event to come.

That being said, I’m very glad to be here. Sunday was the day before WWDC, and one can sense–if he or she happens to be a Mac developer, or a gadget fan–the gathering of the Mac herd in town. Sunday was the first official check-in day (although I knew a friend who’s already got his badge on Saturday), and you could see people coming out of Moscone Center with their souvenir laptop handbag. In fact, you could easily spot one carrying that in downtown San Fransisco. You could also see them coming in and out of the Apple Store just three blocks away. Inside Moscone the atmosphere was jolly. Indeed a party is coming.

I am never a Mac fan. It is true that I care about Apple products and latest development, but it is because Apple makes a tool that I happen to love using. And I don’t even own an iPod till today (just ain’t the music type). I’ve become an OS X software development by accident, but I enjoy making useful things and that what we at the OpenVanilla Project do helps people.

People seem to have high expectations for this year’s WWDC. Since the Intel cat was let out of the bag last year and Intel Macs have been materialized way ahead of schedule, what comes next is now really hard to say. I for one don’t see how much more dramatic this year can be than the Intel transition last year, but a cheaper/smaller MacBook Pro and built-in virtualization support will fall into my sweetspot. Maybe I should just bring along with the Apple bingo game card with me, too.

Today has been a long day and tomorrow will be even longer (reasons below), so here’s a quick summary of my WWDC Day -1:

  • Apple Asia has held its own reception this evening and has gathered close to 100 people here. According to them, this year we’ve seen a larger number of developers coming from Asia. This year the number is close to 200 (among 4000+ total conference goers). Among those I have met today, Professor Wenjun Zhou leads a group of nearly 20 students from Shanghai Tongji University (Prof Zhou has even made a guest appearance in the Developer Testimonials, and that’s how I came to recognize him at the reception party). A number of them are doing NLP-related work and Steve Van der Hoeven is the mastermind behind DialKeys–the technology used by Microsoft’s UMC (its formal codename, Origami, seems to be more well known and more liked).
  • I’ve asked specifically when I shoulde show up in line for entering Moscone West‘s main hall, in which Steve Jobs’s keynote speech will run. The answers varied, but on average it seemed that standing/queueing in line around 6:30 AM will be wise, 7:00 adviced, and anything after 7:30 AM will make you be at the disposal of fortune.
  • Which also means tomorrow is going to be a long day.
  • Although the schedule is already there, some sessions are not yet announced. For the time being I’m interested in topics related to WebKit (on which OV might eventually rely heavily), development tools and UNIX-related technology, and some little CoreImage/computer graphics thing as distraction.
  • I had been to Apple Store San Francisco and it was quite a store, with tutorial workshops running continuously–some of them of great quality and helpful tips–and very crowded genius bar. Although once again I ran into this sorry-sir-but-your-AppleCare-data-ain’t-found-in-our-database episode (last time it was in France; dear Apple Taiwan, please pamper your users more!), finally I had got my dead power supply replaced.
  • A latest news (totally unrelated to WWDC) for those who had spent their childhood in Taiwan: 7-Eleven Taiwan is announcing the return of the Slurpee, 思樂冰, or translated back literally into English, the “think happy ice.” Not that I was particularly fond of Slurpee, it’s just that I didn’t know if was called so if wasn’t the news, I noticed it in 7-Eleven’s here, and gugod had made a comment on that too… (N.B.: Perl knowledge required).
  • One last thought, the conference is huge. Tons of sessions and thousands of participants. I have to say I’m totally inexperienced and have no slightest idea of what the social dynamics will be. Still, I’ve made a list of the issues that OpenVanilla has run into so far, and the issues of East Asian text processing in general, and some issues of my personal interest–such as when, if ever, will Apple make an open-source version of CoreFoundation’s C++/Objective-C equivalent? Will Apple keep an eye on the Objective-C++ feature that wasn’t pushed into GCC 4.0 last year?

It’s 11:00 PM (and I’m into this AM/PM habit now that I’m in the US…), and so much for today’s update.

Thanks again for everyone who has supported OpenVanilla and made this trip possible. Orcas & family have sponsored my accommodation and Apple Asia has helped much in the visa application and trip preparation.

Some of my WWDC photos will be available at flickr. I’m travelling light this time and may not find much photo occasion, but if I run into someone’s flickr set that’s interesting, I’ll bring it up here too.

Blog entries in the series are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 License. (All other entries in this blog remain their “all rights reserved” status though, unless specified like this WWDC 2006 series.)

Adium and gaim talk off-the-record (OTR)

Now it’s clear that Adium and gaim use the same off-the-record (OTR) library, and can talk to each other with no problem. Great for people who need a little more privacy. Whether this otr library (libotr) is strong enough remains to be tested. It’s better than nothing (MSN and other instant messenger protocols are in clear). Still, a false sense of security is no security, and is actually worse. So use it with discretion (in every sense of that word).

For Adium users, OTR module already comes with it.

For gaim users and Linux/FreeBSD savvy, look for the following packages: libotr, gaim-otr, gaim-encryption.

« Prev