Sunday, 16 January 2011

GitHub

Git has been my favourite tool for a long time. It feels right to respond to code questions with a little gist or even a whole repository.

Here's one I built to roll up some stackoverflow answers and subsequent patch posts.

Friday, 14 January 2011

Bit Twiddling

The Android Notification system is a real blast from the past.

Last time I has to "or" bits into bit fields to make things happen is was writing an embedded controller for a medical pump.

It would be OK if the flags names made any sense, but it's taken me 2 hours reading the documentation and a few testcases to figure out WTF the really mean, come on guys give me a sane object API please.

I've still not got the lights going. It's not like these are memory mapped bits that actually make the hardware do things, that can be the only excuse for bit twiddling IMHO. I'll check the AOSP, I bet some other programmer has to "and" all my bits out one by one to actually make any sense of it.

I do like the attempt at being able to set the LED RGB colour though. I'm going to have to make a colour picker for that.

Tuesday, 4 January 2011

Android Themes and Styles

Changing the attributes of a UI in code always ends up looking ugly. In HTML I tend to factor out these attributes into stylesheets. In Android you can use styles and themes.

Using CSS always takes a little time, as CSS is not one of my core skills, however it always ends up feeling like a simple design. This was also true of my first stab at using Android styles and Themes.

Again android themes and styles have a hierarchical nature so I can tweak existing styles. I can also using logical names for things like colours which change depending on the theme.

I used this approach as hardcoding the colours would not work with the different themes out there. E.g if you've got a bright theme, then text to white will make it invisible. On a dark theme, setting it to black would do the same.

Now that I'm using styles correctly people with different themes will be able to use my app.

Saturday, 1 January 2011

PubSubHubBub Content Distribution without charset encoding

I'm having an issue with feeds that don't declare their content
encoding in the XML processing instruction.

The content distribution defined in the PSHB spec (7.3) doesn't appear
to allow specification of a character encoding. The Content-Type is
defined as "application/rss+xml" or "application/atom+xml".

This would not be an issue if the feed XML specified the encoding in
the XML processing instruction however not all feeds do.

For example, Google Alert Feeds:
http://www.google.com/alerts/feeds/08979446703162538414/13217883862269731888

I simply HTTP GET a Google Alert feed as the HTTPResponse reports
"Content-Type:text/xml; charset=UTF-8". This allows me to decode it
correctly. However as part of a Content Distribution I don't have this
information.

The HTTP standard http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
states (in 3.7.1) the default should be ISO-8859-1. So my Java
HttpServletRequest reader appears to be defaulting to this content
type, which means I can't decode the stream correctly.

Simplest thing would be to get some Googler to fix the Google Alert
XML ;-)

Or could we consider specifying that HUBs replicate the charset from
the Fetch through into the Content-Distribution?