I’m making a living developing Java applications, and the current turmoil around Java worries me somewhat. Hopefully Oracle will learn from its recent mistakes that upset a big part of the community, and Java will continue to thrive. However, I’m actively looking at languages and technologies beyond Java, so as not to put all my eggs in Oracle’s basket.

I’m using several bits of Apple hardware: a home MacBook, a work MacBook Pro and an iPod Classic. Both laptops are running Mac OS X, and I haven’t hacked the iPod either, so there is definitely a strong link to Cupertino. However, I just couldn’t bring myself to buy an iPhone, when Android started catching up.

This brings us to the next West Coast company I’m relying on: Google. I have three Google accounts (two personal, one work), all linked to my Android phone. Although I do have a fairly up-to-date offline backup of my mailboxes, a disturbingly significant part of my online communication and identity relies on Google not being evil or not screwing up.

I could go on and mention Microsoft, Facebook, Twitter and all the rest, but I think I have made my point. Part of me thinks it’s amazing, that we have all these great companies and services we can use to learn, communicate and create in ways previous generations would have never imagined. On the other hand it’s somewhat unsettling to think of the implications of placing so much of our data, money and career in the hands of executive committees thousands of miles away.

Getting the source

You can get the source code from GitHub, or you can simply download this ZIPped Eclipse PyDev project. Either way, the first step is to put the files in the addons folder of your XBMC installation. The location of this folder depends on your operating system:

• Linux: ~/.xbmc/addons
• Mac OS X: ~/Library/Application Support/XBMC/addons
• Windows: C:\Program Files\XBMC\addons

Using Git

Creating a new folder called plugin.audio.tutorial, and run git checkout from there. The repository location is: git://github.com/zstorok/xbmc-soundcloud-plugin.git.

Using the ZIP file

If you are using the ZIP file, you can simply extract it in the addons folder, since it already includes the plugin.audio.tutorial folder.

Testing with XBMC

Although the location of the addon folders should be unambiguous, it’s best to make sure and check if XBMC actually finds the newly added plugin. Launch XBMC and go to Music | Music Add-ons to see if the plugin is picked up by XBMC. You should see an XBMC Plugin Tutorial item in the list, just like in the screenshot below. Go ahead and explore the tutorial plugin to explore what it does.

Importing into Eclipse

The next step is to get the code into Eclipse. Go to File | New… | PyDev project and give the new project a name. Uncheck the Use default checkbox under Project contents, and browse for the plugin.audio.tutorial folder in your addons folder. Set Grammar Version to 2.4 and Interpreter to Default, and also make sure to uncheck the Create default ‘src’ folder… checkbox. See the screenshot below for how it should look on Mac OS X; other platforms will only differ in the directory location. Click Finish to accept all the other defaults.

Next, right-click on the newly created project and select Properties. Go to the PyDev – PYTHONPATH property page and add the project folder as a source folder, like it is shown in the screenshot below.

Exploring the files

Now you’re all set to begin working with the code. The newly created PyDev project contains the following files:

• addon.xml (the plugin metadata descriptor)
• default.py (and the actual Python code)
• icon.png (plugin icon, 256×256 PNG)

addon.xml

This XML file contains various bits of metadata about the addon, for example: name, version, author, dependencies, etc. The XBMC Wiki goes into the syntax and purpose of this file in detail.

default.py

This is where the meat is: the actual Python code. I will go over the main sections of it in detail, and I suggest keeping the XBMC Python module documentation handy to quickly look up the relevant API classes and functions.
One thing to keep in mind is, that the code is run by XBMC every time you enter a directory in your plugin. As you will see, the usual practice to pass information (subdirectory location, query parameters, etc.) between subsequent invocations is to encode them as query strings in the list item URLs. On each invocation, the URL is provided as a command line argument in sys.argv, which is then parsed to obtain the parameter names and values. This will make a lot more sense once you see it in action, so let’s dive into the code.
First we import the three XBMC modules, sys for handling command line arguments and urllib for encoding and decoding parameters in URLs.

import sys
import xbmc, xbmcgui, xbmcplugin
import urllib

Next we initialize some constants, you will see how these are used a bit later.

# plugin modes
# plugin modes
MODE_FIRST = 10
MODE_SECOND = 20
 
# parameter keys
PARAMETER_KEY_MODE = "mode"
 
# menu item names
FIRST_SUBMENU = "First Submenu"
SECOND_SUBMENU = "Second Submenu"
 
# plugin handle
handle = int(sys.argv[1])

Next up are two utility functions: the first is for converting URL parameters to a Python dict, the second one is for adding an item to the directory listing in XBMC. The latter contains the first truly XBMC specific code. First it creates a ListItem, then calls xbmcplugin.addDirectoryItem(…) to add it to the current directory listing. Also, it encodes various parameters we want to pass on to the next invocation of our plugin script into the directory item’s URL. Remember, default.py is run each time you select a list item in the UI, and we need to pass on some information about where we are in the menu structure.

# utility functions
def parameters_string_to_dict(parameters):
    ''' Convert parameters encoded in a URL to a dict. '''
    paramDict = {}
    if parameters:
        paramPairs = parameters[1:].split("&")
        for paramsPair in paramPairs:
            paramSplits = paramsPair.split('=')
            if (len(paramSplits)) == 2:
                paramDict[paramSplits[0]] = paramSplits[1]
    return paramDict
 
def addDirectoryItem(name, isFolder=True, parameters={}):
    ''' Add a list item to the XBMC UI.'''
    li = xbmcgui.ListItem(name)
    url = sys.argv[0] + '?' + urllib.urlencode(parameters)
    return xbmcplugin.addDirectoryItem(handle=int(sys.argv[1]), url=url, listitem=li, isFolder=isFolder)

Now we are getting to the part where the root menu and the two submenus are created. These functions make use of the addDirectoryItem(…) function defined above.
The show_root_menu() function adds two folder items, and specifies the mode associated with the item via the parameters argument. Since it’s a dict, you could put any kind of information here, but to keep it simple, this example only sets the mode. After the two items are added, it calls xbmcplugin.endOfDirectory(…) to indicate, that we don’t want to add any more items to the list.

# UI builder functions
def show_root_menu():
    ''' Show the plugin root menu. '''
    addDirectoryItem(name=FIRST_SUBMENU, parameters={ PARAMETER_KEY_MODE: MODE_FIRST }, isFolder=True)
    addDirectoryItem(name=SECOND_SUBMENU, parameters={ PARAMETER_KEY_MODE: MODE_SECOND }, isFolder=True)
    xbmcplugin.endOfDirectory(handle=handle, succeeded=True)

The show_first_submenu() and show_second_submenu() functions simply create and insert a few dummy items into the submenus. Note that these are not folder items, so in a real plugin these would be the actual media files (images, audio and video clips). Of course you can create a menu structure of any depth, but in this example I kept it as simple as possible.

def show_first_submenu():
    ''' Show first submenu. '''
    for i in range(0, 5):
        name = "%s Item %d" % (FIRST_SUBMENU, i)
        addDirectoryItem(name, isFolder=False)
    xbmcplugin.endOfDirectory(handle=handle, succeeded=True)
 
def show_second_submenu():
    ''' Show second submenu. '''
    for i in range(0, 10):
        name = "%s Item %d" % (SECOND_SUBMENU, i)
        addDirectoryItem(name, isFolder=False)
    xbmcplugin.endOfDirectory(handle=handle, succeeded=True)

The last part of the code is the most important: this is where the parameters encoded in the URL are parsed to decide which function to invoke to display the expected menu.
If sys.argv[2] is unspecified it means that we are at the top level, so the root menu should be displayed. The actual submenus have a mode associated with them, which is encoded into their item URLs when they are added to the root menu.
If you want to follow what is happening when running a plugin, you can take a look at the XBMC log. In this example, the mode is printed into the log at each invocation.

# parameter values
params = parameters_string_to_dict(sys.argv[2])
mode = int(params.get(PARAMETER_KEY_MODE, "0"))
print "##########################################################"
print("Mode: %s" % mode)
print "##########################################################"
 
# Depending on the mode, call the appropriate function to build the UI.
if not sys.argv[2]:
    # new start
    ok = show_root_menu()
elif mode == MODE_FIRST:
    ok = show_first_submenu()
elif mode == MODE_SECOND:
    ok = show_second_submenu()

This is all that’s required to have a simple, executable XBMC plugin. Of course currently it’s not very useful, since the items are not tied to actual media files. In the next part I will show you how to connect to the SoundCloud API and stream music directly in XBMC.

However, I prefer learning by doing, so after a while I started thinking about a real-life problem to solve with Python. Being a fan of the XBMC cross-platform media center application — which can be extended with Python scripts — and the SoundCloud music sharing website — which exposes a nicely designed RESTful API — I decided to develop a music plugin for XBMC to access music shared on SoundCloud.

In the first post of this multi-part series I will provide an overview of the documentation and tools available at the time of writing. Stay tuned for the next parts, where I will go into more detail and post some actual code. The outline of things to come:

• Part 1: Documentation and tools
• Part 2: The anatomy of an XBMC plugin
• Part 3: Accessing public resources on SoundCloud
• Part 4: Putting it all together

SoundCloud API

A quick glance at the SoundCloud API page on GitHub revealed an existing Python API wrapper, but unfortunately it wasn’t compatible with XBMC’s built-in Python 2.4 runtime. This meant that I had to roll my own, which proved to be fairly easy once I hunted down the required third-party dependencies, like simplejson, httplib2 and oauth2. I haven’t had the time yet to dig into SoundCloud’s OAuth-based authentication, so for the first version I decided to provide access to publicly available resources only, and implement authentication, favorite tracks, followed/follower users, etc. in a future iteration.

The SoundCloud API documentation is very detailed and well-structured. SoundCloud even provides a web console with plenty of examples for experimenting with the API to see how it responds to various requests. This is just awesome, every RESTful web service should provide one of these; it is a lot more tangible than API documentation, and easier than firing up curl or a full-fledged web browser and copying example URLs from the documentation. After hacking together a quick and dirty Python command-line client, I was ready to integrate it with XBMC.

XBMC Plugin Development

The XBMC plugin development HOW-TO is not very well organized and is missing some details. I had to do a fair amount of googling and bookmarking to get a complete picture of how plugins hook into the application and what the best practices are. The most helpful resources I could find were the following:

• The single most important resource is the Python module documentation, which is unfortunately not very easy to find. Here you can find all the classes and methods exposed to Python scripts and plugins by XBMC.
• Since I was using PyDev for development I was very happy to find this excellent tutorial on how to debug XBMC plugins with PyDev.
• When preparing for this blog post I stumbled upon a PyDev script, which provides content assist for XBMC modules. This is necessary, because the XBMC modules are implemented in C++ and are exposed directly via the Python runtime in XBMC. This means, that PyDev has no .py files to work with when trying to determine the contents of a given module. I will try to get it working and update this post accordingly.

While I was digging into the idiosyncrasies of XBMC plugin development, the XBMC community started to prepare for the upcoming Dharma release, in which they made some changes to the add-on infrastructure, and extended the add-on developer documentation on their Wiki. I decided to target the upcoming release with my plugin, which turned out to require creating an addon.xml file and some minor tweaking of the code itself, but I will get to that in Part 2.

This concludes the first part of the series. In Part 2 I will go into more details on how to develop an XBMC plugin, provide some advice to prevent common pitfalls and show some simple code snippets.

First the source code, then some explanation.

// generate EPackages from schemas
XSDEcoreBuilder xsdEcoreBuilder = new XSDEcoreBuilder();
Collection generatedPackages = xsdEcoreBuilder.generate(schemaURI);

// register the packages loaded from XSD
for (EObject generatedEObject : generatedPackages) {
    if (generatedEObject instanceof EPackage) {
        EPackage generatedPackage = (EPackage) generatedEObject;
        EPackage.Registry.INSTANCE.put(generatedPackage.getNsURI(),
            generatedPackage);
    }
}

// add file extension to registry
ResourceFactoryRegistryImpl.INSTANCE.getExtensionToFactoryMap()
    .put(MY_FILE_EXTENSION, new GenericXMLResourceFactoryImpl());

The first step is loading the schemas and generating EPackages from them. XSDEcoreBuilder provides a convenient method which does both. The return value is of the type Collection<EObject> as opposed to Collection<EPackage>, so the next step is iterating over that collection, casting the items and registering them in the global package registry. This ensures that the generated packages will be available in the whole application. Finally, if your XML files have a custom extension, add that as a key to the resource factory registry, with an GenericXMLResourceFactoryImpl instance as the value. By doing that you make sure, that EMF will know which resource factory to use when loading or saving files of this type.
After that you can load you XML files like you would normally do:

ResourceSet resourceSet = ResourceSetFactory.createResourceSet();
Resource resource = resourceSet.getResource(xmlURI, true);
resource.load(Collections.EMPTY_MAP);
EObject root = resource.getContents().get(0);
...

If you want to compare the contents of two XML files you just loaded, you can use EMF Compare’s fairly easy and clean API:

MatchModel match = MatchService.doMatch(model1, model2,
	Collections. emptyMap());
DiffModel diff = DiffService.doDiff(match, false);

For more details on how to use the API, see the EMF Compare FAQ.

Looks like it’s easier than ever to get started with Android development in Eclipse, I will have to try that for myself this weekend…

Eventually I found a very interesting and extremely detailed StackOverflow response regarding the Android application lifecycle and why it is different from desktop applications and more similar to web applications. Another thorough explanation of what is happening with applications in the background is presented in this video by an Android team member:

Another interesting thing caught my eye while browsing for Android related bits and pieces: apparently there is a lot of activity regarding OSGi on Android. Apache Felix and Equinox were both successfully patched to run on Android, and ProSyst released their free OSGi runtime for several major mobile platforms, including Android. Neil Bartlett, one of the developers experimenting with Equinox on Android talks about this activity in a video interview with Michael Coté:

I really like programming in Java. However, after all the time I spent learning various aspects of the language itself and numerous useful third-party libraries, I would like to broaden my horizons. After looking around on the web I found a great summary of various methods to measure the popularity of programming languages. Out of the methods mentioned there, I liked LangPop’s approach the most, since it combines different sources into a normalized comparison. You can even modify the weights assigned to the data sources, if you feel that for example the number of projects using a specific programming language on Google Code is more relevant than the job listings on Craiglist. See the chart embedded below for the most recent normalized popularity comparison.

Github was not considered in the comparison, but the website has a page with statistics on the most popular programming languages:

Python is quite high on both of these charts, and I’ve already read some online tutorials about it, which left me quite impressed. I have yet to try the Eclipse tooling for Python, but Pydev seems to be a mature project, so I have high hopes in that regard. JavaScript is obviously very popular and one of the de facto web programming languages, so it comes as a close second on my list. Scala is an interesting one: not really popular, but apparently a very good choice for parallel programming on the JVM. Again, this is something I’ve never tried but seems to gain lots of momentum with the widespread adoption of multi-core processors.

I will try to find some time to dig into these exciting new technologies, it will be interesting to learn new approaches and paradigms beyond what Java and OOP taught me.

Screenshot of the unofficial StackExchange Eclipse client plug-in

Actually, I was somewhat surprised, that there is no built-in support for notifications in Eclipse, but allegedly the Mylyn implementation will be migrated to the main Eclipse Platform code base sometime in the future. However, there is a short and sweet example of how to implement a notification popup widget from scratch,which I plan to use for this pet project.

Since the RESTful client capabilities of ECF are quite new I struggled a bit with learning how to do things, but I managed to get the hang of it by dissecting the relevant JUnit tests. I might have gotten some things wrong, or just not so pretty, but it worked for the demo. I created an Eclipse Labs project to host the code, and I will continue to work on it in my spare time. Hopefully this example code will help someone to learn the ropes of ECF Remote Services, and maybe eventually people might even want to use it to stay connected to StackOverflow.com even in their IDE.