Chris Aniszczyk's (zx) diatribe

Since we have a plug-in available to exercise the Facebook API (see Part 1), the next step is to create a ‘org.eclipse.facebook.ui’ plug-in that will exercise that API. What I generally do when testing some new code in Eclipse is to create a simple view. In this case, I’ll create a stub view with a hyperlink to launch some Facebook login wizard (along with some other test hyperlinks):

Now that I have the basic code infrastructure in place, let’s get our Web 2.0 on by using that Facebook API! In Eclipse land, to take advantage of another plug-ins’ classes, you need to express a dependency on it. So in order for me to use the Facebook API plug-in I created in Part 1, we need to depend on it. We can do this in the plug-in manifest editor by going to the dependencies page and adding a dependency for the ‘com.facebook.api’ plug-in:

After reading the Facebook API in detail… it seems the API for logging in is straightforward albeit a bit tricky for a deskop-based application. In essence, you have to point to a special URL given to you by Facebook to login… once a user logs in, you need to capture a token that you use to create a REST client for Facebook API access. Ok, translating this into Eclipse terms, I figure all I need is a popup dialog and an SWT Browser widget with a clever listener. So here it is:

All this code does is create an embedded browser within a popup dialog and fishes for a particular authentication token from Facebook. If it finds the particular token, it will create a session with Facebook, if not, it will keep the dialog open until the user properly authenticates.

I was initially having trouble logging in to the service because I was stupid in how I was parsing the authentication token. I didn’t solve the problem until I enabled some tracing information. One interesting way to allow tracing for your Eclipse-based applications is to use the Platform debug facilities.

The basic gist is to create a .options file in the root of your plug-in. Here is how the ‘org.eclipse.osgi’ plug-in .options file looks like:

Pretty simple right…? Now, when you go to launch Eclipse applications, there is a tracing tab that allows you to tweak this options on and off to see what type of tracing information you would like:

I basically enabled this tracing ability within the facebook plug-in:

I then peaked at the console after I logged into see some tracing output:

So there, now I have a simple little framework to enable configurable tracing within my Eclipse-based applications.

That’s it for Part 2. In Part 3, we will cover things like separating core code from user interface code, Eclipse Forms and amongst whatever else pops up in my head.

Lessons Learned

• Start simple and iterate as you make progress
• A simple view provides a good way to test code
• Trace early, trace often
• Platform debug tracing provides a simple way to enable configurable development time debugging

Thanks for listening.

So, the first thing I do when I write an Eclipse-based application, or any application for that matter is set a quick baseline of what I want done. For my first milestone, I decided I simply wanted to be able to log into Facebook. I figured, this would be a good start… it would require me to use the Facebook API in some fashion. This would force me to create a plug-in for the Facebook API which I would reuse when I started to do things like update my status from Eclipse. So my first stop was to look at the Facebook Java APIs since that would make life easier for me.

I found a cool project hosted at Google Code that contained some Java APIs. The only problem was that it seemed you needed a million jars to use these APIs. As an Eclipse plug-in afficiandio, I knew how to handle this… I’ll create a new plug-in! I downloaded all the jars and then launched the ‘New Plug-in Project from Exisiting Jars’ wizard which allows me to quickly create a plug-in by pointing to those existing jars.

To give my newly created plug-in some polish, I’ve decided to do a couple things. First, I’ll only export the packages that my consumers will need to work with the Facebook API:

In the Eclipse and OSGi world, Java packages are the unit of modularity. My consumers shouldn’t care about the other packages and I don’t feel like supporting those packages downstream so I won’t expose them. Since I don’t expose them, my consumers won’t be able to use any classes from those non-exported packages. This provides a nice way to keep your API really “internal.” For my next magic trick, I will make sure to set the Bundle-RequiredExecutionEnvironment (BREE) for my plug-in to J2SE-1.5:

BREEs are a way of telling Eclipse and OSGi that your plug-in at a minimum, requires Java 5.0 to run. This is cool because the Eclipse runtime won’t activate your plug-in if it’s running on Java 1.4… only Java 5.0 and above. The runtime will also give a message out stating that the plug-in can’t activate because the mininum BREE hasn’t been yet… also cool!

So with my new Facebook API plug-in setup and polished to my liking, we can go and start exercising that API in interesting ways. The first way will be finding a way to log-in to Facebook and that will be discussed in Part 2.

• Lessons Learned
• Start simple and iterate as you make progress
• Use the ‘New Plug-in Project From Existing Jars’ wizard to package your dependencies
• Don’t forget to set BREEs, they can save your consumers some heartache!
• Export packages from plug-ins that consumers are only interested in

If you like this type of material, let me know. If there’s a good response, that’s usually motivation for me to do things faster.