While most people keep on screaming, you might find it reasonable to keep on watching out and understanding what's happening; and wait before deciding to support one of the two parties. These two articles are interesting in my opinion:

• Q&A: What's Oracle-Google Lawsuit All About? Maisie Ramsay interviews Al Hilwa from IDC.
• Is Android Evil? by Andreas Constantinou

The latter post is from the past April, so it was written long before the war inception, and the title might appear misleading (Andreas clearly says in the article that Android is not evil). It's not a partisan post, but a detailed insight about how Google controls Android. In the end, both articles should give you some ideas about the fact that there's no battle against or pro open source (as Google wants us to believe), but the two corporates are just making their own interests, trying to grab as much control as they can on the technologies that will make money for the next decade.

If you look at the current scenario, there are lots of patent and copyright wars going on, involving almost all the big corporates. I must say that I'm finding it really stressing, especially when powerful sound waves from the battlefield strike us (just to say the last one, Google backing out of JavaOne and the continuously running debates in the mailing lists and forums, often giving no good contributes).

Waiting for the things to clear up, there's a thing that can be said about Oracle. I find it stressing the complete lack of communications aimed at the community from a high level perspective. In the past months there have been long periods of uncertainty about the roadmaps of the many FLOSS products that Oracle inherited from Sun. For instance, after the reassuring announcements in January, NetBeans missed for several months a roadmap. In the end, it has been published. I reckon that delays could have been caused by the internal reorganization of the company and probably the communications for each specific product (with the notable exception of OpenSolaris, which we understood has died by inferencing the lack of communications from Oracle) are on the way of normalization now .

But the same can't be said for the general strategies. I mean, the Java ecosystem is a scenario with many players - Oracle, Google, other corporates and the community - where costs and profits can be partitioned in different ways. The key point is the way they are partitioned. It's clear what happened in the past: most costs were upon Sun and most profits flew to other corporates and to the community. This was not sustainable and it's clear that Oracle's plans for the game are different. More profits will go to Oracle and possibly less to the other partners (of course, the game is more complex than a simple zero-sum equation). As a community we must accept this, while we can't accept a situation in which Oracle is the only one to make profits. Until the equilibrium point is clearly spotted, at each move of a big actor we will overwhelmed by over-reactions. In this scenario, initiatives such as Gosling's t-shirts pledging for keeping Java free can't help much, as the message is not clear (and if the community just means to keep things as they were under Sun, well, this is just unfeasible).

Larry Ellison said that he wouldn't like the blogging attitude of Jonathan Schwartz. So, in the end, nobody is explaining us what the general strategy is - and some areas, such as the future of Java 7, inherited the uncertainty that already started under the last years of Sun management. Larry Ellison is supposed to speak at the forthcoming JavaOne, and I think that at this point it's convenient for us to wait since there are only three weeks ahead. But one/two high-level communications per year are not enough as they leave too room to speculations, fears, doubts and eventually disguise from other parties. In the end, Oracle would be the first to gain from a good communication; unless they just don't care of the community, of course.

Well, yesterday my app passed 1,000 downloads and I'm happy. But I'm less happy in seeing that the percentage of active installs is going down since ten days: after having been steady at 45/46% for a couple of months, it dropped to 38%. The strange thing is that in the latest ten days I've released two new versions with new features and bug fixes. The few users I'm in touch with are saying thumbs up. There could be worrying reasons (the most obvious ones) or not worrying ones (for instance, the app has been talked about in some forum of birdwatchers from geographical areas that are not supported yet, and they realize after installing the app).

So, it's really frustrating for some aspects not being able to know what's going on - especially when I think that Google has got all the statistics about why users are uninstalling my app (for people not knowing the Android Market: whenever you uninstall an application downloaded from the market, the smartphone asks why you're doing that).

So, the Android Market is much more open than the Apple Store, it is also open since it allows competitors, but it's not as open as one would want.

In my previous post I said that the new Oracle vs Google war might have bad as well as good effects on the community. As usual, most people are screaming about the possible bad effects. I'd like to share an hypothetical scenario where the effects are good.
Please note: it's not a forecast. I'm not able to do that. Maybe things will be really bad. In my scenario there is for sure a considerable dose of wishful thinking. Take it just as a mental exercise to demonstrate that there are at least chances for a happy end.

What could happen is:

1. Oracle and Google come to a deal, so Google licenses Javaâ„¢ and Oracle gets a share of the Android revenues.
2. Google might even be convinced to have JavaFX on Android - thus JavaFX Mobile is suddenly resuscitated (there are smart and dumb ways to integrate JavaFX on Android, and I'm not talking of them now). BTW, this point is not relevant for the rest of the scenario.
3. Oracle and Google distribute also on Android a compatibility layer for running most of the current JME applications. At the same time, Oracle announces that it won't develop JME further and that it will assist its customers to migrate to pure Android. In this way, the move won't erode the number of pure Android developers, instead it will bring in a massive amount of the current JME developers. To make Google feel safe, the JME compatibility layer could have a limited lifespan (e.g. two years), enough for migrate, but too short for some people to still consider JME strategic.
4. Android in the end becomes Javaâ„¢, supported by two big actors and not only one.
5. Nokia and RIM find themselves in the most complete isolation. Either they try to keep JME alive by themselves (difficult, because Oracle might legally prevent this from happen), or they try to survive with their own SDKs, or... they understood that it's better to migrate to Android.
6. At the end of the games, the mobile world ends up with 70% of Java and 25% of iPhone. Google definitely wins the mobile war, even though it has to share the glory (and the money) with Oracle.
7. We as a community win all the same, because we get with a defragmented Javaâ„¢ on the mobile and Javaâ„¢ is the winner technology of the mobile world, relegating the competition to a niche, just like the old good glorious times of JME.

This would make sense on why Oracle didn't announce anything serious on JME and JavaFX Mobile in the past months. They probably waited for Android to surpass iPhone (it could be not a chance that this happened in the same days in which the complaint was made public) to ante up.

So, today's big scoop is Oracle suing Google for a number of alleged patent infringements with Android. Doomsday announcements are spreading all over the world, as you might expect. So, are we going to die with loud screams?

Follow my advice: stay cool and go on as usual. Keep yourself informed (and before anything else have a read at the Oracle Complaint that is attached to the URL I've linked above). Don't listen to the screaming crowd. Don't believe that Oracle really wants to shut down Android. The Complaint is not what Oracle wants to achieve, it's just the weapon to achieve something else. Let's track how the legal things go on, let's see how Google reacts and let's wait for some developments before deciding whether things are going to be worse or better for us (both things could happen).

For sure with Ellison we won't get bored, even though I must say I don't have problems in finding interesting things in my life and I would have avoided this.

The crash report feature collects unexpected exceptions from an Android apps and delivers it to the Development Console where the app author can analyze it. It is only available on Android 2.2, which is not yet widespread, so until today I've never seen a crash report. This morning I received one. It's a trivial error I made since the very first version of the application, with no effects on the application, but that triggers an exception starting from Froyo.

It's nice to see this kind of diagnostics (it would be even nicer if one received also the last ten lines of logging, in any case I suppose that this can be done with some explicit coding).

... make sure you have a working mobile connection and take your laptop to the garden, where you can enjoy some wonderful landscape. In case you don't get the desired efficiency, you'll still enjoy the landscape.

20100731-0374-1080p from Fabrizio Giudici on Vimeo.

 

2010731-0010-1080p from Fabrizio Giudici on Vimeo.

You know that I've moved to Maven more than one year ago and I don't regret. I think I would be unable to manage the number of projects I'm managing on my own without it (or at least without an effective artifact repository).

But Maven needs a proper and clean environment. Maven experts are constantly advising about that. One of the most important pieces of the environment is the artifact repository. You can create a cheap one with a plain webdav resource, or you can install a specific tool such as Nexus or Artifactory. A plain webdav resource is simpler to manage and might sound as a good solution for simpler cases, while a specific tool is more powerful but more complex to setup and administer. It's your choice: the important thing is that everything is under your control and properly managed.

Hear what's happening to me since a couple of days. Before going on, I'll recap a couple of Maven concepts. When you have a multi-repository project (unfortunately it frequently happens, as some libraries you might depend have their own repo), Maven searches for artifacts in all of them - what typically happens is that the first repo responds with an HTTP 404 - Not Found and Maven searches on until it finds what it needs. Then it stores a metadata XML file to recall where it has last found the artifact. In this way it can avoid constantly polling for things and it's faster.

Now, I have still a few remaining messy things in my projects. When I made the switch one year ago, I thought that a webdav repo was ok for my stuff and used the webdav facility at Kenai. Later I realized that Nexus was worth while, and in any case I was able to deploy most of my stuff to the free Sonatype Maven hosting. But I have still three projects relying on Kenai's webdav. I planned for moving them sooner or later, but I didn't so far because I didn't touch them for some months.

Now, a couple of days ago, Kenai started randomly responding with a small text page saying HTTP 500 - Internal Server Error instead of the HTTP 404 when you ask for a non-existing resource - but the status code is set to 200 so Maven and Nexus, that clearly aren't much smart sometimes, instead of treating this as a "not found", are accepting the resource that is served with the error. The resource, of course, is a small HTML page with the text "Internal Server Error" etc... Of course, storing this as an artifact, a POM, or a metadata XML file isn't good at all and breaks the build. In a couple of days, the error literally poisoned all my repositories, both Nexus and the one on my disk, and all my builds are broken. Now I'm compelled to fix the thing ASAP - and I'm forced to postpone my next release of blueBill, since this week will be focused on the required clean up.

Clearly, it's not entirely a Maven fault (even though that silly way of handling HTTP 500 is crying out loud); the problem originated from Kenai and a messy situation in my software factory. With Maven, you must be very precise and accurate. You can take this as an annoyance - on the other hand it's also a stimulus for setting up things properly.

I do hope that the next release of the Maven tools, anyway, will have this sort of silly bugs fixed.

Yes, there is quite a bit of topics in the title, and they are all involved in the latest prototype of blueBill Mobile.

In case you don't have read my previous posts on this track, I'm going to give a bit of context. I'm referring to an Android application of mine, blueBill Mobile, aimed at providing a number of field tools for birdwatchers. The core of the application is a database of species, which is very complete for given geographic areas, that users can browse and operate upon. The relevant part for this post is the 'fact sheet' section, where for each species one can pick a description, some information and a collection of related media. A key concept of blueBill Mobile is that information aren't provided by a “closed” publisher (such as the portfolio and the knowledge base of a single coprorate, as it happens for other birdwatching applications in the market), instead the app is able to aggregate information available on the web, when the terms of use are appropriate. Data can be still reliable (there are reputable organizations providing vetted data), so this open approach can be extremely powerful, as huge quantities of quality information can be made available to users.


Semantic technologies

Semantic technologies (I'm not talking yet of the Semantic Web) have been involved since the beginning in the design of my application, as it is based on a RDF store - that is a way that I find very convenient to represent heterogeneous information (I've blogged a few times in the past about this). The retrieval of data, until the past week, was only implemented by non semantic means, as the first data provider that I aggregated (xeno-canto, a large database of bird calls) just exposes HTML pages. Thus, web scraping was needed - a cumbersome approach that is also brittle, as it easily breaks when the website changes something in its look and feel. This is a critical point: you don't want that your app all of a sudden stops working because of a change that you can't control, nor you want to be forced to publish an update in a matter of hours. The solution I've implemented for this scenario is an offline scraper that produces RDF triples that are later bundled with the application in N3 notation. This means that I also have to provide a way to update these files (without necessarily updating the whole app). In the end this approach works, but with additional complexity (of course, for sites that only provide HTML I have to live with it).


The Semantic Web and the BBC Wildlife Finder

The Semantic Web has been designed exactly to solve this problem and have a specific way to integrate data from multiple sources. There are more and more RDF-enabled websites and a very interesting one for my purposes is the BBC, as it is - among other things - a very active producer of nature video footage of excellent quality and known all over the world.

As a personal note, “The Living Planet” series of documentaries by sir David Attenborough has probably been one of the most influential things of my boyhood - for both my interest in nature and my development of an aesthetic sense for imaging (furthermore I remember that when the series was broadcast in Italy I had just bought my first serious music synthesizer and I was practicing on it trying to reproduce parts of the soundtrack by Elizabeth Parker).

Recently, the BBC has done a huge amount of work to make available many pieces of its footage about nature by means of a web interface, the BBC Wildlife Finder (this is part of a larger initiative that makes available also other productions, such as news and sports). Information is both available in HTML for a traditional desktop navigation and in RDF+XML for other uses (subject to a specific syndication license). For understanding the difference, click the two links related to the Greater Flamingo:

• http://www.bbc.co.uk/nature/species/Greater_Flamingo
• http://www.bbc.co.uk/nature/species/Greater_Flamingo.rdf

As you can see RDF+XML is rich of information and links to external RDF resources and it can be easily parsed and manipulated, even on Android. Thus it has been easy to integrate it with blueBill Mobile, as the screenshots and screencast below demonstrate.

 

As you can see, for usability purposes I reorganized the different pieces of information provided by BBC to make them available in different sections of the fact sheets (and they are and will be seamlessly integrated with other data sources, each one tagged with its credentials and terms of use).

I must stress the point that, unlike other anticipations of blueBill Mobile features, this prototype is experimental and needn't to be actually available in the next release; unlike the xeno-canto resources, that are available under a Creative Commons license, I need to understand if my usage is really compatible with the BBC terms of use - this post has been also written to submit my app to BBC's attention for a feedback.

Political issues with the integration

There are political issues when you reuse chunks of information provided by a third party (not under an open license) and present them to end users with your own UI. For instance, some time ago an independent developer, Dave Johnston, published a free application (beebPlayer) for playing the BBC video footage from an Android smartphone, but BBC took it down because it was not compatible with the syndication policy (Dave explains the details on his blog). In short, BBC is developing its own app (iPlayer with an Android port) for accessing their contents, for a number of reasons ranging from quality control to the possibility of placing ads. This is understandable, as we can't pretend that every content provider in the world works with open licenses.

That's why I didn't even try to integrate a video player in blueBill Mobile, but when a footage element is picked the original BBC web page is open in the navigator - a thing that, in practice, is not meaningful as the website has not been optimized for rendering on a small device. So, when the resource I want to integrate is not available under an open license, and usually it comes with its specific app such in the BBC case, it seems there's a conflict between the desire of delivering to users a smooth way to access the integrated data and the need to respect the terms of use.

Now, Android sports a great way to integrate different applications together, by means of the Intent / Activity paradigm. In short, you can pass a message (Intent) from an application to another and create a seamless sequence of screens that are rendered by the two applications in turn. Hopefully BBC will provide a public Intent for iPlayer, so I will be able to launch it instead of opening the web page, providing to my users an immediate access to the resource, while the BBC would completely control the way it is rendered.


Some specific comments to the BBC service

There is just another couple of points that are worth to be mentioned:

1. iPlayer for Android will be Flash-based. Unfortunately, this means that only a subset of Android 2.2 mobile phones will be able to run it. This is not a constraint due to technical reasons: for instance, iPlayer on iPhone is already available and, clearly, it doesn't use Flash; furthermore, Dave Johnston demonstrated that the BBC clips can be rendered on Android in an alternate way. While I understand that delivering on multiple platforms is hard and expensive, I really hope that BBC finds a solution for supporting older Android versions, because a long time will pass before 2.2 significantly spreads.
2. Opening iPlayer from my desktop navigator a message appears, saying that video contents are available to UK only. I think it is a deliberate choice (a paragraph in the BBC Syndication Policy explicitly says “BBC content may only be distributed for consumption within the UK”)... but this sounds really anachronistic in MMX, doesn't it? I really hope that this restriction will be lifted in future.

Conclusion

I'm stopping here for now. Beyond the details that specifically involve my app, I hope that this post is giving you some good hints about how the Semantic Web (and its related technologies) can be profitably used to create applications which provide rich contents to end users by means of a smartphone app.

I'd also like to stress again that the Android architecture (in particular, the Intent / Activity paradigm) is very powerful to allow the inter-app collaboration that is required when you can't directly integrate third parties' contents for licensing reasons, still delivering a good user experience. As far as I know, it's a feature that competitors, such as iPhone, don't offer, thus dramatically reducing the possibilities that we developers can exploit and - in the end - reducing the things that end users can enjoy.

Last but not least, all of this can be jeopardized if content providers forget to implement some apparently minor details - such as the support for a public Intent in iPlayer, as I explained above.

A couple of days ago I did a massive refactoring in a couple of components of blueBill Mobile; the ones related to the management of fact sheets (e.g. bird calls with metadata) that I was talking about in a previous post. The first implementation (in the latest release) was based on RDF triples and used an ad-hoc implementation of a RDF+JSON serializer; now I can say I'm successfully running some modules of OpenSesame, so I got rid of a bunch of my own code and - above all - I'm able to generate and parse RDF+XML and RDF+N3 too. BTW, the RDF+N3 parser seems to be much faster than RDF+JSON, thus I probably don't need the latter any longer.

Googling around one can find traces of people trying to use an RDF store on Android - so far I've mostly found people talking of Jena ports. What I like of OpenSesame is that it's released in many small and self-consistent modules, that made really easier for me the integration of what I need so far (and I'll be probably able to incrementally integrate other parts).

At the moment I'm not using any backing database, but the simplified in-memory Graph object together with a few serializers. I'll investigate about the backing database after the next release (end of July). I didn't have to change the sources of OpenSesame, but needed to do some patching to work around some XML problems with Android (as usual: missing stuff).

This is just a teaser since I didn't find the time so far to post a more comprehensive article: expect one soon here or at DZone.