Skip to main content


Background services for Android, updated

If, like me, you've needed to set up and run a background service on Android before, these scenarios might make you shiver:
Creating Activities that can quickly and easily request a set of permissions.Binding those Activities to a Service, and then disconnecting them without shutting it down.Bringing the service to the foreground, and keeping it alive for as long as possible.Managing the Service lifecycle, as Android tears your service down and brings it back to life as and when it needs to.Communicating between entirely different processes/apps. A few years ago I wrote a library called background-service-lib to help smoothe over these exact pain-points. Android moved on, as did Android Studio and Gradle, and so I've refreshed it again.

You can find out more about how to use version 2.0, and how to include it in your projects at the Github repository:
front-line-tech/ background-service-lib
Recent posts


It was 1998 and I was 17. My tool of choice was QBasic and this is a game I wrote based on a concept I stole from another game called Wriggler.

The original Wriggler is a race game through a maze of bugs and creepy crawlies - played against the computer. My game would have been a race, had I gotten around to writing the computer player.

Instead it pits you, a plucky young worm (comprised of 4 lines and a blob), against an army of anatomically incorrect spiders in your mission to see a duck and solve a single puzzle. Also there are some chocolate bars.

I fired it up once again to make a playthrough video. The game features some pretty old-school beep/boop sound effects, which really hit me right in the nostalgias!

Warning, this playthrough video contains spoilers for the puzzle... 😂

I don't suppose there's much to be learned from my code, but you can see it all on Github if that's your groove and you're welcome to have a tinker. I had some success running it with DOSBox

What's in a bothie?

I was recently asked in a review to talk a little bit about the technologies that drive my app, Bothie.

Bothie is an Android app that takes two pictures (a main photo from the main camera on your phone, and a selfie from the selfie camera), combining them into a single bothie.

Perhaps it’s time to write a little more about how Bothie slots together and which libraries and tools I use.

Bothie is a native Android app written in Java. I have been working on Bothie since 2014, and at the time Bothie was conceived, neither Kotlin nor the Architecture Components were available for Android. It has been a long road getting the app to where it is now, and without the help of existing libraries and SDKs it would have been almost impossible. Bothie stands on the shoulders of giants...

The camera preview you see in Bothie, for both images, is driven by Google's unofficial CameraView library. There were various choices for camera library available, and I've talked a little about them befo…

3 excellent ways to build trust with your users

"I don't see why it needs that permission!"
Android apps ask for unusual permissions sometimes, and they doesn't always make sense.
This article assumes that you are already a trustworthy developer. If you intend to harvest user details or conceal other nefarious activity on a user's device, please follow this link (US | UK) and then make your way to the nearest police station.
The Android permissions system doesn't know how to explain what it needs clearly, and some permissions lock away a group of features, when only one is needed.
For instance, this screengrab from a game demonstrates a fear response to a regularly requested permission. It was posted with the title:
"Quickest way to get your app deleted"
The app is asking for a permission called "make and manage phone calls". When the poster attempts to find out more, he reports that "it went to a screen that said the reason that needed this type of access was to provide me with rewar…

What is refactoring, and why have I got technical debt?

"It didn't used to be so expensive to change one little thing..."
Congratulations! You've put together a great team and steered the new project all the way to your first release. You've re-focussed on marketing, press releases, and you're doing some horizon scanning for new features...

Your lead developer comes to you with a serious request: She wants to refactor the project.
"What does that even mean?" you ask. The answer doesn't sound like it's worth your time - the app won't even change, but some of the wiring under the bonnet gets re-plumbed. So what? Mixed metaphors aside, it sounds like an expensive exercise that's not going to benefit you at all. Why should you bother?

It's time you learnt about technical debt.
All projects have technical debt. Technical debt increases the friction every time you want to modify your application to add a new feature or fix a bug. The amount of it you have is difficult to measure and takes effor…

Uplifting Bothie

Bothie has been a long time in development! I first created a demo app in 2014, and I've been revisiting the project regularly since then.

Bothie is an app to help you put yourself into your pictures. When you press the shutter button the first time, it takes a photo with the main camera. When you press it again, it takes another - this time with the selfie camera. Then it insets your selfie into your main photo, and lets you reposition, rotate, and zoom your pictures until you've made the perfect bothie.

Soon you'll be able to do a range of other exciting things to your pictures to create the perfect composition.

When I first published Bothie (through my company Front-Line Tech Ltd) in 2016, I quietly added it to the Play Store with no fanfare. I really wanted to develop it until I was completely satisfied with it before I launched it properly.

Since then, I've worked hard to add new features and modernise Bothie. I want it to stand out in its class as an elegant app, a…

Why are some projects so expensive? Need they be?

This article is adapted from a response I gave to the Reddit post for the Medium article "How I replicated an $86 million project in 57 lines of code" in r/coding...

The original poster, /u/javinpaul has written an article demonstrating an ANPR app - that can read number plates and compare them against an internally held database. The app itself works with a video feed from the phone's camera to process a video stream in real time.

First off, despite comments about his ego and a little name-calling, it isn't arrogant to demonstrate a working ANPR app that can operate on a live video feed, and ask why a similar looking project should cost as much as $86 million.

It is fair to say that any working solution to a problem like this cannot be as simple as a mobile app that can do ANPR. From a developer perspective that seems to be the hard problem, and a developer's instincts will tell her that that ought to be the most expensive part. It's easy to overlook everythi…