DocumentationiPhone

Working in the field

The iPhone app is for the person standing in front of the machine. It verifies, it records, it captures evidence, and the register it writes into can be its own.

For: Verifying, recording and capturing hardware in the field on the iPhone, with or without a signal.
Will not: It isn't a remote control for the Mac and doesn't need the Mac awake. Nothing the camera reads is written without confirmation, and when the camera fails only the routes that need no lens are offered.
Writes: Verifications, hand-overs and captures are written to the register on the phone and signed with your name; a refused stamp is reported on the card.
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 phone can hold the register itself, or work with a Mac or Starkive Cloud. Out in the field the job is the same either way: one hand, poor light, a label rubbed half away.

Everything on this page happens on the iPhone. The app writes to the register on the phone, works offline, and syncs when it has somewhere to sync to. 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 tab you open most. Point it at an asset tag and its card comes up over the camera; 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 puts the machine’s card up, 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 reads Point at an asset tag. When a Mac running Starkive is on your Wi-Fi it also names a pairing code, because then this screen can pair too. Read an NFC tag sits above the camera buttons for machines with an NFC sticker.

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.
Camera scanning isn’t available. Add it by hand instead. In practice, 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. Check out or Check in hands the machine over from the card. Open is there for the times you want the record. Scan 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

Settings → Files (the gear at the top of Home) and the Files row both report what this iPhone is still holding, and the count has to be honest, because the output goes to auditors.

On a phone holding its own register there’s nowhere to send to, so the summary reads Nothing waiting or 3 photographs kept on this iPhone. On a paired or cloud phone it 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 a machine to somebody

Check out and Check in record who has it, as one change, wherever you are.

Check out asks who the machine is going to, and records the holder and the status together. Check in takes it back. Both are on the scan card, on the record’s … screen, and as a swipe on the Assets list. A short note confirms it, like Checked out to Priya Raman.

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.

Send to the Mac is in Settings, and shows up when a Mac running Starkive is on your Wi-Fi and this phone holds assets of its own. 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. 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.