DocumentationiPhone

Working in the field

The iPhone companion is for the person standing in front of the machine. It scans, it verifies, it captures, and and the register it writes into is its own.

For: The iPhone companion for scanning, verifying and capturing hardware in the field, holding its own register offline.
Will not: It is not a remote control for the Mac and does not need the Mac awake. Nothing the camera reads is written without confirmation, and in the three camera trouble states only Add it by hand is offered.
Writes: Verifications and captures are written to the phone’s own register, with refused stamps reported on the card; the page does not say whether entries are attributed.
On iPhone: Send to the Mac offers the register across, but nothing is written until somebody at the Mac accepts it.

What the phone is for

The Mac is where the register is kept. The phone is where it is used, which is a different job with different constraints: one hand, poor light, a label that has been rubbed half away.

Everything on this page happens on the iPhone. The companion holds its own register, works offline, and syncs when it can. It is not a remote control for the Mac, and it does not need the Mac to be awake to record a verification.

Three things are worth knowing before you start. The camera reads barcodes and printed text at the same time, so a label with a dead barcode is still readable. Nothing the camera reads is written to the register without somebody confirming it. And every way into intake has a route that does not use the camera at all, because a phone with a cracked lens or a refused permission still has to be able to record hardware.

Scanning a label

Scan is the sheet you open most. Point it at an asset tag and it opens the record; point it at a manufacturer label and it offers you what it read.

The camera reads barcodes and printed text in the same pass. A QR code that Manifest can prove is one of ours fires the instant it decodes and opens the record, because a code that can only mean one thing should not wait. Anything else settles: the reader collects what it can see over a short window and then offers it, because a single frame showing one barcode proves only that one barcode was legible in that frame.

The instruction names pairing codes as well as asset tags. The Mac’s pairing card points at this tab, so the sentence has to say so, or somebody sent here to pair would reasonably conclude they were on the wrong screen.

The alternatives stand down while a result card is up. They are ways of answering “this scan is not going to work”, and one just did.

When the camera will not read

A black rectangle is not a diagnosis. The screen says which of the five troubles you have, and offers only the routes that can actually help.

There are five states, and each has its own sentence. Starting the camera… while it comes up. Point at an asset tag, or a pairing code on your Mac when it is running. Then the three that are trouble:

Camera access is off. Turn it on in Settings, or add it by hand. The only state with a remedy button, because it is the only one the operator can undo. Open Settings takes you straight there.
This device cannot scan. Add it by hand instead. No Neural Engine, which in practice means the Simulator.
The camera is busy. Another app is using it. Close it and come back, or add it by hand. There is no retry button, on purpose: nothing in the app can take the camera back from whatever is holding it, so the button would fail in place and teach you that the buttons here are decorative. Leaving and coming back is the fix, and the scanner tries again on its own when the app returns to the foreground.

The scanner stopped. Add it by hand instead. covers everything else. The underlying reason goes to the log rather than the screen, because it belongs in a log and not in the one line somebody reads at arm’s length.

The rule the screen follows is that an alternative offered in answer to a failure must not depend on the thing that failed. Two of the three ways off this screen open a camera. When the camera is what failed, offering them is not a fallback, it is the same refusal with a different button on it. So Photograph a serial instead and Sweep a rack instead disappear in the three trouble states, and Add it by hand stays, because it needs no lens.

Reading a serial off a printed label

Photograph a serial instead is a different screen because it is a different technology and a different promise: nothing it produces is applied without you confirming it.

The reader takes barcodes and printed text together, which is what makes the cross-check almost free. A barcode carries a checksum and is exact; printed text is a hint, and the serial is chosen by a separate extractor with a corpus of tests behind it. Where the two agree, that is the strongest evidence available. Where they disagree, the screen shows both rather than picking one, because picking one would bury the very thing worth noticing.

The read settles itself. Nothing is delivered until the reader has seen enough to be sure, and then the list comes up on its own. You do not have to tap a glowing box before the screen will tell you what it read: the tap belongs on the answer, not on the question.

Choosing which value is the serial

A part number and a serial look alike. The person holding the box can tell them apart in a second, so the app asks.

The sheet is titled Which one is the serial? and the line under it reads Everything the camera read. Tap the serial. Each row shows the value large enough to check against the print, and where it was read underneath, so you can look at the right part of the box. There are no scores and no percentages, nothing you would have to be taught to read.

The confirm button spells out what you are about to commit: USE THIS SERIAL with the value underneath it. The field it fills is two screens away, so the button has to carry the value with it.

Scan again in the toolbar takes another look. Cancel re-arms the scanner as well, so declining these readings does not leave the camera unable to offer any others.

A label that yields a single candidate still goes through this sheet. On a device label it is common for one barcode to reach the reader first and settle the read, and a serial written into an asset register is read aloud in server rooms and printed onto labels. Confirming is the cheap half-second; being wrong is expensive and quiet. Nothing read at all goes straight through, because a chooser with no choices is a dead end rather than a question.

Verifying on a walk-round

A hit is drawn over the live camera and the camera keeps running. Verify is one tap from here, and the record is still one tap away for the times you want it.

The card carries the asset tag, the machine’s name, and the reason it is on the list, in the same words the register uses. VERIFY is sized for a thumb pressed one-handed at arm’s length, by somebody whose other hand is holding a machine. OPEN THE RECORD is there for the times you do want it. NEXT clears the card and lets the camera read again.

A verification that did not record is not quieter than one that did. If the stamp is refused, the card says so in the same place the confirmation would have appeared.

The record is not opened on a hit, because on a walk-round it answers a question nobody asked: you are standing in front of the machine and you know what it is. Two taps for the job this app exists for: open Scan, point, tap Verify.

Adding a machine with no camera at all

Every way into intake used to be a lens. A rubbed-off barcode, a machine with no label, a refused permission or a cracked lens meant the fleet could not be added to.

Add it by hand is the door for that. It is on the Scan sheet in every state, including the three where the camera has failed, because it is the one route that needs no lens.

Sweep a rack instead is the other alternative, and it is a different job rather than a different way of doing the same one: one asset you are holding, versus a rack you are walking past. It uses a different camera stack, because a sweep runs for minutes in a dark aisle and needs a torch and low thermals, where reading one label in your hand for a few seconds wants live highlighting instead.

What is still on the phone

The queue screen and the More screen both report what this iPhone is still holding, and the count has to be honest, because the output goes to auditors.

The summary reads All sent only when three counts are all zero: rows the queue is actively working, rows that have stopped and need a decision, and photographs kept on this phone that never made it into the queue. Any one of them being non-zero means something is still here.

3 need a decision when files have stopped and are waiting on you.
The queue’s own explanation when it knows why nothing is moving.
2 kept on this phone, not queued to send yet for captures that never reached the queue: an asset the register has not synced yet, a queue that did not exist when the shutter fired, a file the storage ceiling refused.
4 still going up while the queue is working.

The third count is the one that used to be missing. A capture is kept on the phone first and queued second, and the gap between those is exactly where the interesting cases live. Both screens used to compute the summary from the upload queue alone, so a photograph with no queue row was invisible to both counts and the phone reported a clean board. For a product whose output goes to auditors that is the worst available failure: not “something went wrong”, but a positive claim that the evidence is filed, standing in front of the evidence that is not.

Handing the register to a Mac

Somebody worked off this iPhone for a quarter and has now bought a Mac. Send to the Mac moves the work across without taking it off the phone.

The destination is not a question. It is the paired Mac, by name. The two devices already have a cert-pinned channel whose fingerprint was compared out of band at pairing, which is stronger authentication than any file you could carry between them, so re-asking which Mac would be asking you to re-answer something you already proved.

Send it offers the register to the Mac. Nothing is written until somebody at the Mac reads what would change and decides. The screen then shows Waiting for somebody to accept it with the Mac’s own summary underneath, and Check again asks where it got to. You can close the sheet; it does not stop the transfer.

If this iPhone has not met a Mac yet, Pair with the Mac is on this screen rather than three screens away in Settings, because the screen is deliberately reachable before there is a Mac to reach.

Photographs travel on the upload queue, one capture at a time, and a Mac taking this register holds records describing pictures it does not yet have. Keep the phone paired until the queue is empty: the phone pushes and nothing else moves a file, so nothing else can send them.

When the Mac has dealt with the offer, the screen says so without claiming an outcome. It was accepted, declined, or it timed out, and the Mac shows which. Nothing here changed either way, and your register is still on this iPhone exactly as it was.