PassVerse is for sale

After many months of soul searching, I’ve decided to sell my PassVerse product.

I’ve been working on PassVerse for over two years and it has changed from a SaaS product to a standalone software product. I’ve learned an awful lot about selling software and I’ve some happy customers who use PassVerse within their own businesses. As I’m focused on my freelance work at this time (I need to get a mortgage!), I don’t have the necessary time to grow and support PassVerse. I’ve placed it up for Auction and you can check it out at

If you’re interested in becoming the new owner of PassVerse and taking it forward, please check it out!

How to view your colleagues’ schedules at a glance!

I spent some time over the weekend tweaking the UI for Peopler. I think this version looks a little clearer and more distinct. I’ve also added a new feedback page to this version and I’m keen to see whether this makes a difference.

iOS Simulator Screen Shot 9 Feb 2015 10.16.26

Peopler lets you view the calendar’s of other people using Microsoft Exchange. You don’t need shared calendars or anything complicated, just the person’s email address.

Peopler is available to buy in the App Store

This new version, with the updated UI, should be approved within the week!

How accurate is accurate? GPS adventures with Android

Testing of my Job Tracker app continues in earnest and, I’m pleased to say, it is becoming a useful tool that my brother is beginning to integrate into his day.

While this is all very positive, there is a new issue that reared its head yesterday and it’s a doozie! One of the functions of the app is to capture the user’s location at appropriate times. The app will then analyse this location and take action using this information. One of the actions it takes is determining whether or not the user’s van has moved in between and entry and exit event (getting in and out of the van). It does this by comparing the current position (exit) with the last known position (entry). If the distance is greater than 100m, we assume the van has moved.

Yesterday, whilst on a job, the app determined the van had moved, in spite of the fact it hadn’t. It recorded two positions:

Screen Shot 2015-02-07 at 09.27.34

I then check the logging provided by the device (I use my own HTTP Logging module that sends the logs directly to an Azure web application). The first block of logs show the position being recorded.

Screen Shot 2015-02-07 at 09.29.20It clearly indicates the position has an accuracy of 36.0m and an age of 34 seconds, which is within the 50m /1min tolerance defined by the application. I read this as meaning that they are  36m from this position, at the very most. The user then returns to the van to get something and, as they walk away, an exit event is triggered and the application determines their location again.

Screen Shot 2015-02-07 at 09.28.42

This position has an accuracy of 26m and an age of 24 seconds, which is an slight improvement over the first and to be expected as the FusedLocationAPI gets better with time.

When I compare the actual distance between those locations, I get 0.11km, a distance of 110m. This is outside the 100m allowance and the system therefore creates a new record. This behaviour is throwing a spanner in the works!

Given the two accuracies of 36m and 26m, I believe the theoretical max distance between these two positions is 52m, well within the 100m. I just cannot see how they are 110m apart. I realise that the distance was 10% greater than the allowance, which isn’t really that much in GPS terms (10m is nothing!), but it’s enough to reduce the usefulness of this app, because the arrival and departure times are wrong.

I am going to reduce the location filter from 50m to 40m and see what effect that has. Lowering this could cause greater battery drain as the GPS radio needs to be on for a little longer, but I need to see what effect it will have.

Do you have any experience with Android and the FusedLocationAPI’s accuracy? If you’ve done anything in this space, I’d like to hear your experience.

Location accuracy in Android

As part of my work on Job Tracker, I’ve been using the FusedLocationApi within Android. Initial tests haven’t been very promising, with some wild inaccuracies. Some positions have been over 800m off!


It’s that or my brother has been working in the middle of a field. I’ve been modifying the logic to try and make it more accurate. Once I prove my new code in the field (pardon the pun), I’ll blog about it.

Job Tracker beta testing

It’s been a week since my little brother, AKA beta tester prime, started using my Job Tracker app on his Android phone.

He’s an electrician and travels around doing work at a mixture of sites, commercial and residential, so an app that let’s him record accurate details of the work he has done could be very helpful. I delivered a build of the app to him using Google’s Alpha delivery mechanism, which is very simple I must say.

As with all apps, there were plenty of head scratching issues to work out. This proved to be very challenging, since my brother is in Ireland and I’m in England. I had two main issues, both beacon related.

It wasn’t detecting the beacons.

Since the app is build around the concept of iBeacon monitoring, this was quite a big one! I posted an Estimote beacon to my brother for the purposes of this beta testing. He basically placed it in a room and walked in and out of the room. The broadcast radius of the beacon was very low, so I was puzzled as to why it wasn’t recording the stops. There was no way to get an insight into the app (to read the logs) so I was diagnosing the issue blind.

They possible causes:

  1. The beacon monitoring wasn’t working at all.
  2. The location detection was generating an error and being swallowed.
  3. The call to my API was failing.

I ruled out number 1 by adding lots of Toasts to the Background Service. This allowed my brother to determine that it was detecting the beacons.

Number 2 was an act of faith. I had to assume that since the permissions were requested and the location services were switched on, that this was working okay.

In the end, it was a silly omission on my behalf. I had just updated the backend and added authentication. I was missing the Authorization header on one of the requests, so the app couldn’t successfully function. D’oh!

Sometimes it would fail to record an entry or exit

This issue proved to be more subtle. During the day, the app would work perfectly, or not at all. In some cases it would stop detecting the end or exit events. There were two possibilities. Either my code was crashing or Android was killing the Background service and not restarting it. I added lots more exception handling to the Background service and included an alert dialog so my brother would know if the service crashed. After a day’s use, this dialog never appeared, so I ruled out developer negligence. I switched the service over to a Foreground one. This eliminated the issue, but left me with a permanent dialog. I’ll revisit this once the app’s functionality has been improved.

There were, of course, other bugs in my code. Most very simple to squash.

This week should bring a full 5 days of uninterrupted testing and help me determine if the app is useful, annoying, pointless or somewhere in-between. I just completed an iOS version too and that’s being deployed to another brother. He’s a mobile mechanic, so this app is suitable for him too. I’ve got a beacon sitting in a Jiffy bag ready to post to him!

I’ve had an idea for a home-delivery beacon platform too :)


Android Beacon Monitoring Woes

My new experimental app, Job Tracker, has been out in the wild with my beta tester for the past few days and, whilst the feedback has been good, the app is just not working as I expected.

The main problem is that, after a random period of time, it stops picking up the beacons. This is due, I believe, to the fact that Android is killing my monitoring service due to memory pressure and failing to restart it. That or my implementation is utter rubbish. I’m going with the former :)

In order to make region monitoring work for beacons, you need to have an Android Service running that actually performs the monitoring. I had originally implemented this as a background service. To try and work around the problem, I’ve made my Monitoring Service run in the foreground and added a Ongoing notification to inform users as such.


This will, I hope, keep the service running for much longer, allowing a better experience for the user. This is just a reminder that iBeacons are certainly an Apple invention and hopefully Android will eventually bake iBeacon support into the OS.