Adam Speakman

We had a customer at work recently who had a special requirement around multiple currency support in our Android app. They have cinema sites in multiple countries, and they want customers to see the correct currency symbol when viewing sessions for a site. Up until now, the app has only ever had to deal with single currencies on a per-customer (and hence per-build) basis.

While implementing this multiple currency support, I came across something of a problem - the Android Currency code doesn’t behave quite as you’d hope, and is inconsistent across versions. Sometimes you get a currency symbol where you’re supposed to, sometimes you don’t - and sometimes the symbol is a slightly different symbol in one locale to that which is in another (￥, I’m looking at you). I’ve now got a set of test cases which do a fair job of explaining the issue, as well as the solution we came up with which mostly works.

Ever used an open source library in your Android app? If you have, then you probably should have included a page with the license details for that library. If you did, great! You probably had the same question I did recently; how should you do that?

Adding a support library to Android Studio is a bit different to how it’s done in Eclipse. Where you’d add a ‘project’ in Eclipse, in Studio you add a ‘Module’ (which is a sub-project of your overall application - similar to Projects in a Solution, if you’ve done any .NET development). In this post I detail how to add the Google Play Services project, but you should be able to follow the instructions to add any support library.

A few days ago I finally finished the application I’ve been working on in my spare moments over the last month or two. It’s called Wookmark Viewer and it’s a simple little app that lets you browse the latest images saved on Wookmark.com (Wookmark is an ‘image bookmarking’ site, so there’s all sorts of images from all over the web that get saved there). This was an interesting project for me, as I got to use a few different open source libraries (including one I ended up almost totally rewriting), switched IDE from Eclipse to IntelliJ, and had to figure out some new Android features I hadn’t used before.

This post-mortem picks apart what I enjoyed building, what caused me troubles, and what needs changing - the app is far from perfect.

After converting a Windows Phone 7 application (What’s Shaking, NZ?) to Windows Phone 8, I noticed a few deprecation warnings around the Maps SDK. Converting the code to use the WP8 Maps SDK instead was fairly straightforward, but there were a few gotchas which I’ve covered in this post.

I’ve been trying to clean up the What’s Shaking, NZ? for Windows Phone 7 codebase recently, as there was quite a bit of duplicated code and plenty of room for problems (read: shitty code). I’ll be migrating it to Windows Phone 8 soon, and want it as clean as possible before I start.

I had an interesting problem today where I needed to scale the default zoom for the map view for my Android app, depending on the screen size. I’d previously hardcoded it to a zoom level of 6. This worked nicely on my testing device (a Nexus One) and looked OK (but not great) on a Galaxy S3 - but I saw it last night on a Nexus 7 and it looked ridiculous. My desire was to have the map view show the whole of New Zealand, filling up as much of the screen as possible. On the Nexus 7, the country was tiny.

There’s a lot of good information out there already on setting up Octopress on Github. The Octopress documentation covers the subject in depth, as do assorted blog posts. However, perhaps it’s because I was drinking while doing it, or perhaps it was because I missed something while reading the guides, or my poor mental model of how things were supposed to work, or even that it was late at night, but I had a lot of trouble setting up What’s Shaking, NZ? on Github Pages.