Whereoscope 1.2 For Android

January 8, 2011

We’ve just released Whereoscope 1.2 for Android. 1.2. Get it here (Market) or here (AppBrain). 1.2 has a few new features that we’ve been asked for ever since we released 1.0, but it also includes an important bugfix that I want to talk about for a moment.

The bug that 1.2 fixes is actually not our bug — it’s a bug caused by some manufacturer’s* builds of the Froyo (Android 2.2) code. You can find some detailed discussion of it here. In short: every Android phone has a unique device identifier, which we use to distinguish between data sent from different handsets. The problem is that on some models of phone, this unique identifier is not, in fact, unique: for these models, every single handset will report exactly the same identifier as every other (9774d56d682e549c). What this means is that we’re unable to distinguish between requests sent from actual individual handsets — they all report the same ID, so they all appear to be the same physical device to our servers.

The fix we’ve put in place is to detect these handsets (we can do this by checking to see if they report this particular errant device ID), and instead of using the hardware device ID, we use the “IMEI” number instead, which is also supposed to be unique to the device. We’re aware that using the IMEI number is not a perfect solution: Wikipedia’s article on IMEI numbers quote a BT Cellnet spokesman who claims that around 10% of IMEI numbers are not unique. The reason we went ahead with the IMEI number is that it is one of the few numbers that will not change if the phone’s subscriber changes. This means that if your phone were to be stolen, Whereoscope would continue to function even if the thief changed the SIM card. Of course, if they wipe the phone, then Whereoscope will no longer run and you will not be able to locate the device, but we want to give you the best chance we can to recover the handset.

The last thing to say about this is that in order to do this, we had to ask for the “read phone state” permission. This means that this version of Whereoscope will not automatically update itself if you had previously configured it for automatic updates. I want to be clear that we are only using this permission to get this IMEI number, not any of the other data it allows us to access. To upgrade, you’ll need to manually go to the Marketplace and confirm the update yourself.

With that out of the way, Whereoscope 1.2 also fixes a bug we’ve had since 1.0 where the notifications we sent out all had timestamps in Pacific time. As of 1.2, we will send you notifications in whatever timezone your phone is configured for. We’ve also added some enhancements to the map: you are now able to select satellite view from the option menu, and we also show blue circles around locations to show how accurate the location fix is.

We’ve also added a couple of server enhancements to coincide with 1.2, some of which you may already have seen. The two main ones are that we now show entries on the “family list” page for family members who are currently logged out. This solves a long-standing issue where it was impossible to know which web-only users were in the family — since web-only users had no location data, they would not show up in the app. You’ll also be able to see if someone in your family is logged out at the moment, meaning that you won’t be able to locate them. The other server change of note is that we’ve lowered the accuracy threshold location samples need to pass to be displayed on the map. This is in response to feedback from a number of our Android users that they prefer to use their phone with the GPS hardware disabled. Whereoscope will run just fine using only network based location, but the accuracy was often too low for that data to be useful, so we didn’t show it on the map. It’s still the case that network derived location is often inaccurate, but at least this way you’ll have that data, and with the error circles, you’ll be able to make an informed decision as to how much you should trust that data.

We’ve been really pleased with the uptake of Whereoscope on Android, and we’re deeply grateful for how much help we’ve received from our users in finding and helping to debug issues like the duplicate device ID bug. So thanks guys! As always, be sure to let us know if there’s anything we can do to make Whereoscope better — we’ve been loving all the great feedback so far!

[*] The affected handsets that we know about are:

  • Motorola Droid 2
  • Motorola Droid X
  • HTC Desire
  • HTC HD2
  • LG Optimus S  LS670

There are certain to be others, so 1.2 is a strongly recommended upgrade for everyone. You will need to logout and log back in again for everything to start working.

Merry Christmas from Whereoscope

December 23, 2010

It’s that time of year again: sleigh bells are jingling, and ring ting tingling and so forth, and here at Whereoscope HQ, we’re as excited about the holidays as any little kid (possibly more so — we can drink red wine!). But before we get to all that, we wanted to take a minute to offer a sincere thankyou for all the support we’ve received this year from wonderful users like you. I am not exaggerating one bit when I say that we could not have had as successful a year as we’ve had without you believing in our product enough to give it a go.

It’s been a huge year for us! Let me give you some of the highlights: we now have 13,000 users, translations to 12 languages, versions on iPhone and Android, and just last week, we released our next app: DriveTime. DriveTime is a great tool for anyone who wants to keep track of how much time they spend at home, at work, at the pub or, pertinently for the season, Christmas shopping. It’s built on the same solid platform that we’ve built up with Whereoscope. Check it out, we really think you’ll like it.

Christmas is a great time of year to try Whereoscope if you haven’t been using it much lately. Tell your relatives to install it so they can see how far away you are on your way to visit, or use it to help coordinate travel plans. And regrouping after NYE celebrations — how many times have you wished you could just press a button to find your friends. We’ll be around over the holidays, so we’ll be more than happy to help out if you get stuck.

We’re super-excited about the coming year. It’s going to be huge! There’s more coming than I could ever hope to fit into one message, so I’m not even going to try. Instead, let me say that we at Whereoscope HQ wish you all a very, very Merry Christmas, and a happy and prosperous New Year. Stay safe, stay healthy and stay happy, and make the most of time with your family and friends. Thanks for reading!

Whereoscope 1.1 for Android — Android 2.1 Support!

December 15, 2010

We’ve just released version 1.1 for Android!

Get it here (Market) or here (AppBrain), or scan this QR Code on your phone:

We’d planned to just make this a bugfix release while we wait to hear what features people really want on Android, but we got some of that feedback much sooner than expected, so this update is a bit bigger than we’d planned. Here’s what’s new:

  • Android 2.1 support! — we had no idea how many of you were still on Android 2.1. Whereoscope is now fully functional on Android 2.1, with two exceptions: it cannot respond to remote location update requests, and it can’t receive notification messages about arrival or departure. It does do always-on location updating in the background, can request a location update from an Android 2.2 phone or an iPhone, and will let you explore you and your family’s location, along with a history of your movements.
  • Improved handling of network errors — bottom line: this version is more reliable than its predecessor.
  • We fixed our icon — it now appears correctly in Android Market and AppBrain, and on low-res screens. Thanks to everyone who wrote in about this!
  • Now remembers the email address used for login — we know, it’s easy to forget which one you used.
  • Sounds, vibrations and lights on notifications. 1.0 sent messages to you about people arriving at or departing places, but they just silently went into the notifications bar where you wouldn’t see them unless you looked. 1.1 will flash the phone’s light blue, make a sound and vibrate. We hope this means you’ll see notifications sooner and that they’ll be more useful because of this. Let us know what you think of this.
  • Login improvements — there’s now a bit more explanation about what’s going on instead of the stark “login or signup (or else!)” screen. We hope it’s a bit less frightening.
  • Log battery level to server — this should be invisible to you, but will help us to monitor what effect we’re having on your battery and improve it over time.

The response to the Android release has exceeded our expectations; we’re very happy to see everyone jumping on board. As with our iPhone version, we monitor GetSatisfaction very closely for questions, comments and suggestions, or you can always email us directly — just hit “reply” on any of our emails (we read every single response), or send an email to support.

Android vs iOS: A Developer’s Perspective

December 7, 2010

Since its inception, Whereoscope has been an iPhone-only shop. The genesis of this iPhone-fetishism goes all the way back to the very first iPhone: in a way, it was the potential that device tantalizingly dangled before us that pushed Mick and myself to pick up our shovels and give this whole entrepreneur thing a go. I still believe that the iPhone is a truly paradigm shifting device; that by releasing it, Apple fundamentally and irrevocably changed the course of computing. But as the song goes, “the times they are a changin’.” Android has made considerable gains on iPhone in terms of functionality, polish and mind-share. The time had come for us to put aside our prejudices, and actually put together an app to see what would happen. What could possibly go wrong?!

“I hate this thing!”

We were lucky enough to score a couple of developer handsets from Google, through Y Combinator (we’re YC S2010 alumni). I took them home, unwrapped them, and started playing with one of them (a Motorola Droid). About ten minutes later I was on the phone (my iPhone — no way was I going to be gracing this thing with phone-calls) to Mick saying “I hate this thing!” I just didn’t get it. My iPhone had always seemed so intuitive, but on Android I had to shift my mental model: I had always assumed that the buttons on the bottom of it were optional extras, in much the same way that you can generally use the phone with just the touchscreen and not worry about the trackball thing. It definitely took some getting used to, and even now when I show Whereoscope on Android to iPhone users, I need to explain the basics of navigating an Android phone to them before they can use it.

The good news is that things definitely got better from there. Whilst I still think that Android’s initial user experience needs to be improved (it works well, but I really feel like they’re going to lose so many people in those first 30 seconds of use), I have to say that developing on Android after having worked on iPhone is a bit like waking up from a vivid nightmare — the kind where your dog, Fluffy, is being chased by killer robots who are having a bad hair day — and realising that actually, things are ok.

Garbage Collection

iPhone doesn’t have it. Seriously, Apple: What The? Various luminaries have waxed geeky on why garbage collection is so great, so I’ll keep this brief. Basically there’s two reasons it’s awesome: I really don’t have time to learn the rules of memory ownership and when to free, and all that stuff for yet another language. Secondly, I just can’t think of another language feature that accelerates development as much as garbage collection. Android has it, and for anything not pushing the envelope in terms of what the hardware can do (ie, almost everything), it works really well. I might have understood why Apple didn’t include it in the first couple of iPhones — it does come at a computational premium — but they really don’t have an excuse any more. It’s a big enough deal that I would advise the first-time mobile app developer to start on Android for this reason alone.


Android has really great documentation. And I don’t mean superficial interface definitions and the like, I mean the really meaty stuff. Part of this is that the Android approach is fundamentally to expose everything to the developer, rather than try to hide important stuff on the (somewhat condescending) assumption that the platform developer knows better than you. I won’t go into details, but it is absolutely no exaggeration to say that we’ve spent weeks devising and performing increasingly peculiar experiments to figure out how to get iOS to do what we want. We’ve implemented hideous — and I really mean that — hideous hacks on iPhone to achieve what is trivial and well documented on Android.

I think this is what people mean when they say that “Android is open.” I don’t know if that’s a fair characterisation or not, but there’s something to it. I think it might be fairer to say that Android is very explicit in its communication with the developer. iOS swaps that control and communicativeness for presumptive simplicity. There’s reasons for both approaches, but to my mind what this means is that both platforms make the mundane easy, but Android makes the difficult possible, while iOS makes some difficult things easier, but does so to the exclusion of use-cases unimagined by Apple.


Somewhere inside Apple, there’s a guy who is receiving untold, nay, unspeakable pleasures by inflicting on the development community a kind of suffering that is as acute as it is pointless. That pain comes in the form of a series of hoops that one is forced to jump through in order to turn your phone into a development handset. There’s provisioning profiles, ad-hoc builds, certificates, and countless screens that I clicked through, not really caring what they did, because they brought me closer to being able to run my code on my phone. On Android, you check one option in preferences. That’s it.


Having been battered and abused by the iPhone Appstore review process, it came as a bit of a shock to upload my binary to the Android Marketplace and have it appear only seconds later on my phone. In a way it was a bit anti-climactic. Despite the palpable sense of relief at my realisation that clicking “Publish” really is the last step, I’m actually not sure if this is a good thing or not. Broadly, I think that being able to rapidly get new versions to users is a good thing, but looking around the Android marketplace, my observation has been that the software is of lower quality, on average. I can’t back that up with hard numbers, but I think the argument can be made that Apple’s process, for all its warts, does encourage better software. I know we have spent time making sure things are “just right” on iPhone, where I think we might not on Android; it’s a lot easier to think “we’ll just push another version tomorrow.” I’ll be interested to see how this plays out.

IDEs, Simulators, The Usual Suspects

To develop on iPhone, you need a Mac. This sucked, as it meant that the first step on my journey to iPhone fame and fortune was to drop $2K on a computer that I didn’t really want (I still view it as a bit of a toy. However, you’ll have to pry my Thinkpad from my cold, dead hands). iOS development uses XCode, which some people love. I can tolerate XCode, but at the end of the day there’s something I can’t quite put my finger on that just rubs me the wrong way about it. It might just be that I haven’t had that epiphany that so many Mac owners seem to, where they just can’t imagine using anything but their Mac. Anyway, Android development is done in Eclipse (you can do it other ways, but Eclipse is the recommended path). I have to admit that I expected to hate Eclipse (Vim is my weapon of choice), but I’ve found it surprisingly good. The Java UI toolkits are still a bit weird, but overall it’s actually fairly pleasant to use, assuming you have enough RAM to use it (in fairness, my Mac has twice as much RAM as the Thinkpad I do Android dev on). And you don’t need a Mac to run Eclipse.

The emulators provided by both platforms are also kinda interesting. The iPhone developer platform ships with what they call a “Simulator” — it’s basically a build of the iOS runtime for 64-bit Mac OS on Intel. To run your code in the simulator, you actually have to build a separate binary, and the code all executes basically at the full speed of the host computer. We’ve actually been bitten by this before, because it’s really easy to believe that your code is crazy fast when your main interaction with it is on a quad-core Core i5 chip, instead of a single-core ARM chip. The Android dev kit takes a different approach: they actually use qemu to emulate the whole system — you make a disk image, and it boots up, and you’re actually running Android inside a virtual machine on your computer. You use the same binaries in the emulator as you do on the phone. Except that you don’t: because it’s a full emulated environment, running stuff in the emulator is crazy slow, so you end up running all your code on a phone all the time. Which I think is wise — you’ll know exactly how fast your code can be expected to run in production that way.


In an attempt to vindicate our decision to develop for Android, I wandered into an AT&T store the other day and had a chat with the sales assistant there. She said to me that they sell about 1 Android handset for every 3 iPhones. For her, Android was still a bit of a fringe platform. But you add to that all the carriers in the US that don’t have iPhone, and even anecdotally, that’s a lot of units. Despite quipping at the start of this article that we have somewhat of an iPhone fetish, the truth is that we go where the users are (as any entrepreneur worth their salt will). There comes a time when it would be ok for Android development to be 5 times harder than iPhone, but you’d still do it because without that, you’d fail. I don’t know if we’re at that point yet, but the equation for me was surprisingly tilted in favor of Android thanks to the simplicity of developing for it. Having gone through the process, I have a clearer understanding of Google’s strategy: I think they hope to win because their platform is so much more developer friendly. It’s a strategy that Google knows well, because that’s what the web is: it is dramatically simpler to prototype a web application than it is to hack something up in C++ (especially Visual-C++, which taught me that there is a reason they’re called “compilers” and not “compliers”). And y’know, it really could work. It’ll be interesting to see how this all ends up.

Whereoscope is available on the Android Marketplace (tap here if you’re reading this on your Android phone). It’s free for now, so get it while it’s hot!

Whereoscope is available on the Android Marketplace (tap here if you’re reading this on your Android phone).

If you use AppBrain you can download it from here.

You can also download Whereoscope from the iPhone App Store.

Download Whereoscope

It’s free for now, so get it while it’s hot!


December 5, 2010

Do you like Android and knowing that your kids got to school safely? Man, have I got a deal for you!

We’ve just uploaded our first release of Whereoscope for Android to the Android Marketplace. First up, here’s some sceenshots to whet your appetite:

Just like the iPhone version, you can add places that you want to get notifications about, and invite your family over email. Once you’re setup, you’ll get notified whenever anyone arrives at or departs from one of those places. Whereoscope for Android is also our first release to be built on our version 2 server platform — what does that mean? More flexibility in terms of accessing your data, and better security.

To get it, tap “Market” on your Android 2.2 phone, tap the search button and type “Whereoscope”, tap the row that says “Whereosocpe”, and then tap “Install”:

This is our very first Android application, so we’re still learning what it is that makes an application great on Android. That said, we’re pretty proud of this release — a few weeks ago, it was just a bullet point on our TODO list. If you like it, be sure to leave positive feedback. And as always, if you run into any kind of problem, let us know! We love hearing from our users, and have been known to distribute fashionable where-o-shirts to users who have gone the extra mile in letting us know what they think of our work (both good and bad).

Whereoscope Android is available with a free lifetime membership for a limited time. We thought this was only fair, since we did this for our iPhone users while we were figuring out the bugs in our iPhone client.

Happy Whereodroiding!

James Gregory,
CTO & Co-Founder.

Database Upgrades!

September 29, 2010

Over the last couple of days, we’ve been working hard to improve the reliability and performance of Whereoscope — on the Web, on the phone, everywhere. This is a big deal, because we know that if you can’t trust Whereoscope to be online, all the time, then you really can’t trust it at all.

The piece of the system that has been letting us down the most, as regular readers will know, is our database. There’s been a bunch of things go wrong with it, so we decided that enough is enough, and took fairly drastic steps to overhaul it. The technical explanation of what we’ve done is to implement “replica sets”. Without going too far into the details, the way we were operating previously was akin to driving a car and carrying a spare tire: if a tire goes flat, you can get back on the road, but you’ll need to pull over, swap the tire over, probably inflate it, curse and swear a lot and so on. It takes time. Replica sets are more like having 3 complete cars driving around with you (a bit like the President!): if one of them gets a flat, we leave it by the side of the road and jump into the next one. We then call up our local dealer (or Secret Service outpost) and ask them to have a new car waiting when we get there: that is to say, there is little to no delay in getting back up and running in the case of a flat tire. Importantly there is also no delay when any other kind of failure occurs. This is important because every time Whereoscope has gone down, it has been because of something we didn’t anticipate; relieving us of the responsibility to foresee failures is probably the single best thing we can do for reliability. Computers are much better at failing than we are at predicting how they’ll do it.

So Whereoscope now has 3 separate database servers, and every time we get data coming in, we’ll write that data out to all three of them. There’s definitely still ways things can go wrong, but the database was by far the most fragile. By having these “hot-spares” running all the time, we’re seriously limiting the impact a database failure can have on the system as a whole. The replication system also has automated failover, meaning that it will automatically shutdown the errant server and switch-over to one of the spares before we even notice anything is wrong.

There’s another side-benefit to come of this also: since we now have 3 servers where we used to have one, we’re able to use these extra database servers to speed things up (something the President’s motorcade can’t do). We’re being cautious in rolling this out, because there are some subtleties to it, but moving forward, we’re optimistic that this will just magically make everything go faster with no work for us (or you!)

Kudos to our admins on this migration: we managed to do the whole switch-over with only about 3 minutes of downtime, very late last night.

And just in case anyone was wondering, we also have an array of “hot-spare” webservers, and a load-balancer with automatic failover, so we’re safe if our webservers start misbehaving also.

Our goal is to get to a place where we don’t even have to think about the reliability of the system: to have it completely functional 100% of the time, whether or not we’re around to look after it (after all, we do occasionally sleep). To be clear, this is just one step on the road to that goal, but it’s a big one — the database server is simultaneously the most critical and fragile component of the system, so it’s great to have it replicated and safe. We’ll keep you posted on further improvements as they happen.

James Gregory
CTO & Co-Founder.

Email Problems

September 15, 2010

We’ve hit an issue with our system for sending out emails to everyone to help them get started with Whereoscope. This was a new system we introduced a couple of days ago, and we’ve had a few teething problems with it. Basically what would happen is that it would send an email out suggesting that you should try adding some places to be notified about, and then the system would promptly “forget” that it had done this, so it would do exactly the same thing the next day.

What this all means is that some of you will have received an email every day for the last 3 days with the subject line “Try adding n places”. I’m very sorry if you’ve been affected by this — it wasn’t our intention to blast you with email. We’ve now got a fix in place, and I’ll be watching the system very carefully over the next few days to ensure that nothing else goes wrong with it.

Sorry again, and thanks for your patience!

James Gregory,
CTO & Co-Founder.