XML Blues with Android
blueBill Mobile reached more than 200 downloads, with more than 100 active installs. I'm getting a few positive feedbacks and - more important - I didn't receive more problem reports, so I presume that the application is reasonably stable (even though communicating with users is still a problem). Time to move on the next set of features...
... that is multimedia support, for helping the identification on the field. While I have already a catalog of images, taken from Wikipedia, that were part of blueBill Mobile for JavaFX, images present the problem of requiring pre-processing. While they are ok when rendered on a large screen, in may cases the subject get too small on the smartphone and the photo need cropping. I don't see anything else than doing the pre-processing by hand, and it will take some time. For this reason, for Android I decided to start with sounds. I've contacted the guys at Xeno-Canto, a large collaborative database of bird calls, and they told me that the terms of use are compatible with blueBill Mobile. So, there's a prototype working that looks like this:

Here comes the problem. Google didn't provide XPath support until the latest 2.2 - which is totally useless for me, as I'm targeting 1.5. I did some tries with various combinations of JAXP, Jaxen and Dom4J, but every combination has got a problem (triggering a specific JAXP but in Android when tests were fine with JSE, or directly failing in JSE). Maybe it's because of my inexperience with Jaxen and Dom4J, but some XPath expression that works in JAXP and other stuff didn't with Jaxen. I soon got bored of that, thinking that it's incredible that with a modern mobile platform in 2010 you can have problems if you try to handle XML at high level.
In the end, I resorted for abandoning XML. With a few hours of TDD exercising, I've prototype a simple marshaller/unmarshaller for RDF+JSON, that is serializing RDF triples over JSON. At least for my current needs, it wasn't hard - probably less than fixing the XML troubles, for sure funnier. In this way, I anticipated the use of RDF, that was initially planned for a further iteration. Basically, I'm pre-processing the xeno-canto pages, converting them in RDF+JSON and storing a separate data file for each bird species. In future, I'd like to have a real RDF store running on Android, even though I fear that it could be a hard task, given the troubles Android shows with XML. A further step will probably be to have blueBill Server to provide the translated RDF+JSON on-the-fly (it could do that right now, but I don't know how scalable is and how reliable my provider is, so I'll need lots of testing first).
| Attachment | Size |
|---|---|
| emulatorScreenSnapz004.png | 78.68 KB |
- Login or register to post comments
- Printer-friendly version
- fabriziogiudici's blog
- 1889 reads






Comments
Have your pie and eat it too
by kirillcool - 2010-06-23 23:46
You seem to contradict yourself:
If you're talking about a modern mobile platform - then yes, it provides the support you're looking for. If you're talking about targeting an API level that is four full releases ago, then you accept the API limitations.
1.5
by fabriziogiudici - 2010-06-24 02:50
Kirill, Android 2.2 was released one month ago and at the moment it covers possibly 1% of the market - sure, it will grow soon, but if you target a product at 2.2, you're basically killing yourself. Unless you just code for fun and are not interested in people using your code.
1.5 is still relevant in the market, and was released only one year ago. But even if I targeted any next version up to 2.0.1, which was released in 2010, I wouldn't have full XML support in the runtime. And I'm talking of stuff that is part of the regular JDK since a lot of years...