Checked in some early test copies of the android-client to SVN over the past few days (working on some major fixes today as well). Doesn’t build on the G1, but it does in the 1.1 SDK. Need to resolve that rather soon, or it’s pretty much useless beyond being a rather cool proof of concept. My todo list:

  • i18n – check Google’s progress in native Android. Possible workarounds?
  • Make the cache work
  • Multiple wiki sources in prefs
  • User authentication
  • Make data available as a ContentProvider
  • Make page views actually attractive and usable (not just a proof of concept)

Looking around though, it might appear as I might not be alone in thinking about native clients (we need mobile editing!). Catlin, maintainer of the wikimedia-mobile code, is pondering doing the same thing for the iPhone. Only he’s looking at using the (admittedly very cool) Rhodes framework. This project is aiming at making a cross-platform mobile framework for app developers (it’s in Ruby). They’ve already got iPhone, Blackberries and some other devices. I think they’ve got Android now too. While this is pretty damn cool, I don’t know if it can really tap the full Android API. While a mediawiki client might not be the route to go with my android-client code, I can still be a ContentProvider, which I highly doubt Rhodes can provide.

With ContentProviders, you can make your data available to other Activities outside of your application. This is immensely useful for things like phone contacts, the Google maps API, and other shared-data information (my todo program interacts with my Google Calendar). It’s been a design goal of mine from the start that the android-client needs to be a data provider, not just a standalone app. Then I become useful not so much for being a client, but for offering an easy way to interface with MediaWikis anywhere, making more purpose-focused apps easier.