Let's talk
engineering

The camera button in the field app did nothing

Field staff tapped Camera and nothing happened, so no proof photos. Two separate faults, each enough alone, hidden because the app swallowed the error.

·

A field crew member on a city street taking a proof photo in the Sazinga AdBoard camera screen on a phone.

Your field staff stand at a board with the app open and tap the Camera button. Nothing happens. No error, no message. They tap again. From the crew’s side it looks like a broken phone, or like they are doing it wrong.

A photograph taken at the board is the evidence behind the advertiser’s invoice. A dead camera button means proof that never reaches the system, and nobody is told. There was a second, quieter problem in the same area: a board could only be photographed while a campaign was booked on it, which is backwards for anyone surveying a new or empty board.

What was actually going on

There were two faults, and either was enough to kill the button on its own.

The first was the one actually firing. The app targeted a recent version of Android, and on that version an app has to declare in advance that it intends to open a camera. Ours never did, so every tap threw an error. We proved it by comparing the merged manifest before and after, rather than reasoning about it.

The second was waiting behind the first. The app declared that it uses the camera but never asked the user for permission. The camera library refuses to open when permission is declared but not held. On a clean install, the permission was not granted.

Both stayed invisible for the same reason: the code handling the tap quietly returned on any error. A dead button and a user who cancelled the camera looked identical.

What we changed

The declaration and the permission request were added. Errors are now shown. Each way a person can respond has its own outcome. If they refuse the camera, the app explains why it is needed and points them to the gallery. If they refuse location, which is not essential, it says what is lost and gets out of the way.

The third case is the one that mattered. Once Android records “never ask again”, the request returns instantly, forever, so the button can never work again. The app now offers to open its settings page instead.

Site photo capture was added to the phone. The server already accepted site photographs; only the phone never called it. It was checked on a real handset against production data.

What it did not fix

The log does not say how long the button was dead in the field, or how many proof photographs were lost. Nobody could count photographs that were never sent.

Nor does the fix make a person grant permission. A user who refuses everything and never opens settings still cannot take a picture. The app now tells them why.

The pattern, for anyone whose staff rely on a phone app

Ask what the app does when something fails. If the answer is “nothing”, you cannot tell a broken feature from a user who changed their mind, and neither can your staff.

Then look at each state a permission can be in, not only the happy one. Granted, refused once and refused for good are three different situations.

Where this ends up

The camera is how a field crew proves the work in AdBoard, the system that runs for Gold Sign Media, an outdoor media operator. A tap now either opens the camera or tells the person what to do next.

This came out of building Sazinga AdBoard

Every site, every booking, every invoice — in one place. The problem above is one we met while building it, and what we did about it is in the product.

If you run something like this, there is one thing you can do without a call: tell us your board count.