Anyonecanedit.org

This is just awesome. To quote the author, “Greasemonkey on steroids for Android.”

I really haven’t had the time to delve into the source yet, but the premise is what’s intriguing me. Typically, rich apps can only go but so far in interacting with the user’s computer unless you start using Java. This is doubly true for smart phones. Especially with newer models, we’ve got devices that are fully capable of rendering whatever Javascript and CSS you throw at us (WebKit ftw!). However, we’re not able to tap the potential just yet of these devices. Imagine clicking “upload a picture” on a web site and having the camera kick in for a quick take-and-upload session. OilCan seems able to do this. The built in demo shows an Amazon search page where you’re prompted to scan a barcode in directly from the camera; OilCan comes from the same developer as CompareEverywhere (the app where you can scan the barcodes and it searches for other places you can buy it).

There’s also a similar project called Mosembro that I haven’t touched yet. Although, it seems to be more about reading your web pages and finding data that it can attach handlers to (auto-linking to maps, contacts, that sort of thing).

Most end-users don’t think about user agents, but to a web programmer, they’ve been both a blessing and a bane of our existence for years.

Anyone who has used more than one browser over the years will know that web pages sometimes don’t show up exactly the same in one browser or another. A margin will be a little wider here, or an image will be shifted slightly over there. This is normal, and stems from the fact that there’s no standard implementation of HTML; it’s up to each web browser to handle it the best they can (and some are certainly better than others). Part of the reason web pages show up differently is due to the little quirks between rendering engines. The other reason is due to developers trying to work around these quirks. 

Checking the user agent is one way that developers use to know if they need to use a workaround. However, as more and more browsers have entered the market, the number of user agents has grown. Nowadays, between all the various desktop and mobile browsers, it’s an impossible feat to try and do anything relying on user agents. Not only are they highly varied, they tend to be highly varied for no major reason. Three different browsers that all use WebKit could very well report different user agents. Not to mention the fact that several browsers have the ability (through plugins) to change the default user agent to something you’d like.

In comes Android to make the job a whole lot messier. They’ve got a method called WebSettings::setUserAgent() which allows you to set the user agent to 1 of three things (god forbid if they’d made it free-form):

• Android user agent–the default. As far as I can tell, this is something to the tune of “Mozilla/5.0 (Linux; U; Android 1.1; en-us; dream) AppleWebKit/525.10+ (KHTML, like Gecko) Version/3.0.4 Mobile Safari/523.12.2″
• What it calls a “desktop user agent.” Haven’t tried it yet to find out what exactly this is.
• iPhone user agent

Whoopie. Three different user agents, all for the same rendering engine :-\ The first one is the best–although I was pretty sure the browser on Android is supposed to be more like Chrome, I guess they haven’t added it to the user agent yet. The second one makes a little bit of sense, actually. Android is cross-platform, so being able to request a desktop-like user agent might actually be useful in some scenarios. I don’t know why the hell we should pretend to be an iPhone though.

As if it’s not bad enough that there’s no uniformity to user agents, and that end-users can tweak them in some browsers, Android has now given its developers to choose user agents in their applications. Thank you Android: you just made user agents a little less useful.

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.