Now this evidently is not SimplePie or Magpie RSS or whatever feed reader library tickles your fancy*, but assuming the feed will never be malformed, it can save you lots of time! Isn’t that what php was meant for? :-P

At first it surprised me that it would even work–but it seems that the JSON module interoperates very nicely with SimpleXML objects. At the end you get an associative array in $feed_array which is a nice representation of the RSS 2 feed. It’s important to highlight the LIBXML_NOCDATA parameter, as it makes sure the CDATA nodes are read as text. Otherwise you would just get empty feed items, etc.

Obviously for this to work you need both the JSON and SimpleXML modules installed and enabled in your server. Since that’s something that always worries me, I wrote another quick script to test whether the hack would work on the server:

It should output something like…

Happy hacking! :-P

If you also want to add custom attributes, you need to define a namespace in the layout file that uses components with custom attributes. Something like this:

And in values/attrs.xml you’ll use myNamespace: instead of android: when listing the supported attributes:

Of course both can be mixed!

Then in your layout file declare your components and required attributes as usual:

We’ll read their values in the constructor which accepts Context and AttributeSet as parameters:

A note on getDimensionPixelSize: yes, you could be “brave” and use getString instead of getDimensionPixel Size, but you’d also have to parse the values and make sure both the values and the units are right, and take care of scaling the readings so that they would be appropriate for the display size in which the application is running.

But it’s evident that it’s way more comfortable to let getDimensionPixelSize do all that work for you!

For example, in an HTC Evo 4G, which is “high density”, getDimensionPixelSize for a padding of 10dip returns 15 pixels = 1.5 * 10, where 1.5 is the display density.

References and more information:

• Custom components
• Declaring a custom Android UI element using XML

you won’t get a tiled background. Instead, you’ll get the image stretched to the element size! Really horrible, if that’s not what you intended to do.

The trick is to create another XML file in the drawable directory.

This file contains configuration settings which describe how an image should behave when used as a tiling background:

Let’s assume you saved it as drawable/tiledBackground.xml. Now, in your UI element you just simply have to refer to this newly created XML file instead of referring to the background image:

It’s as if the XML file creates a virtual image out of the original image, except the new image can be tiled. In fact, what we are creating with this XML is a BitmapDrawable.

In the documentation for that class we can see that android:tileMode accepts the following values:

• repeat (the expected, intuitive tiling),
• mirror (which makes a non seamless pattern seamless!),
• and clamp (which repeats the edge colour).

It first occurred to me that this approach of having to create an XML file for defining tiles was a little over the top, but then I thought that maybe it’s very useful if you want to reuse the same settings across a large collection of items. For example, if you want to define your own collection of UI widgets. So I guess that in that context it makes sense…

… but I sadly discovered that the files generated with My Tracks do not work :-(

Looking for answers, I found an online application that supposedly converts the files into something that DDMS would accept, but apart from the fact that it didn’t work at all, it also required me to log in with my Google Account in order to use it (why?)

So I decided to write my own converter, in Javascript, and put it online, so that you don’t have to lose time as I did. It’s here. It’s free, it’s fast, it won’t pester you asking you to log in, and most specially, it works.

For the curious in you

Since reading the KML specification is about the most tedious thing I’ve ever done on a Friday afternoon, I ended up writing a working KML file by the classical method of deduction, trial and error. After all, they are simply XML files.

Also, it seems the DDMS plug-in only expects a series of Placemarks, and will list them once loaded, one by line, with the Longitude, Latitude, Elevation and Description columns–you can then select distinct locations in DDMS, and they are sent to the emulator via geo commands (I presume that this is a nice way of abstracting the telnet connection underneath). Having them listed is a way to debug and make sure you’re getting the proper data into DDMS :-D

The structure of a working KML file is as follows:

KML files generated by My Tracks have an insane amount of extraneous data and I won’t even bother to post them! Just trust me :-)

My script takes a very naive approach: when you paste the malformed KML into the textarea and press Convert, it will create and load an XML document with the data from the textarea, and then look for <coordinates> nodes using the good old getElementsByTagName node method. Therefore, it’s possible to get duplicated values (for example, the start and end markers are reported as separate placemarkers, although their coordinates are already included in the main path).

There’s something extra to consider: all the values must specify an elevation value. Otherwise, DDMS will not load the KML file. So when parsing the coordinates I’m splitting their values and making sure that they have three values; otherwise I add an extra default ’0′ for elevation.

One last thing. It’s been quite fun to do this with Javascript, but I’m quite surprised that it took me more time to find out how to create an XML document from a String, than actually writing the script! Finding about this line:

has taken me ages and dozens of tabs!

I would have expected that handling XML with Javascript would have been a solved problem by now, but it seems otherwise. There was a lot of people talking about AJAX and XMLHttpRequest (no wonder! XML was the X in AJAX), others solving everything with a use JSON! and some other people suggesting a certain XML() constructor which never worked, IE proprietary methods or even E4X which isn’t implemented in Chrome/Webkit. And it was so simple in fact! But so counter-intuitive…

Anyway, there it is. Don’t forget about it, kids: new DOMParser() is the answer :P

PS Oh I also used the new HTML5 placeholder attribute in the textareas. It doesn’t work on Firefox 3.6 but it does on Chrome, so it’s cool anyway.

I now only have to instantiate patterns, pattern entries and synth voices and send them that relevant data when loading. And adapt my old tracker-style playing routine to work with Renoise 2′s new philosophy (they got rid of the “speed” global song parameter which we were carrying on from the old-tracker era, but I was using that parameter in my player).

There’s not much to show yet, but anyway here’s an extract of the information the test program is outputting while loading a song:

So that you can see that I’m not slacking ;)