A handheld that reads a printed shipping label has not yet demonstrated that it can read the collection code on a visitor's phone. Evaluate the displayed symbol with the proposed scan option and the application that will use its value. A successful read should identify the intended code; releasing goods requires a separate business decision.
Consider a warehouse collection desk where a driver presents a QR code in a booking application. The operator scans it, checks the appointment and confirms the handover. This is an editorial illustration, not an AIDC GO customer case or a measured performance result. The useful purchasing question is whether the proposed configuration fits that presentation and confirmation sequence.
Decide which screen-to-application path you need
There are three different tasks hiding behind the phrase “scan a code on a phone.” A handheld can read a symbol physically displayed by another device. An application can use a camera to capture that display. Software can also decode a saved image without photographing a screen. Evidence for one path does not establish the other two.
For a staffed collection desk, start by describing who holds each device. Can the driver keep the phone in their own hand? Does the operator need one hand free for a document? Does the code open inside an application, an email or a browser? These details determine the presentation to reproduce before comparing hardware.
An integrated scan engine and a rear camera are different input paths even when they share one terminal. Ask which one the demonstration uses and which application receives the decoded result. The label “Android barcode scanner” alone does not identify the optical option, enabled formats or software delivery path. Use the existing handheld terminal configurations to establish the model direction, then identify the specific option being evaluated.
Google's ML Kit documentation illustrates the distinction: its barcode API accepts camera-derived images as well as image files. It also requires sufficient barcode detail and focus in the input image. Those are conditions of that software path, not proof that any AIDC GO handheld includes ML Kit or can read a particular phone display. Source: Google ML Kit barcode scanning on Android
Keep the displayed symbol intact
Start with the actual booking screen, not a replacement graphic enlarged on a laptop. Retain the intended code format, data length, surrounding interface and normal presentation size. Record both the displayed code and the value expected by the receiving application, using test identifiers rather than live customer credentials.
A code can be visible to a person while important parts of its pattern are cropped, softened or covered by another interface element. Check whether zooming removes an edge or its clear border, whether a notification covers part of the symbol, and whether the application changes the layout when the phone rotates. These are observations to make on the supplied screen, not assumed causes of every failure.
DENSO WAVE's QR Code guidance specifies a clear margin around a standard QR symbol, four modules wide on each side. Preserve that margin when preparing a QR presentation. Do not apply that numeric rule to every barcode format, or treat its presence as a guarantee of successful optical capture. Source: DENSO WAVE, determining the QR Code area
Record display brightness, ambient light, viewing angle, protective cover and visible screen damage as separate conditions. Begin with the normal working presentation. If a change helps, retain both results and say what changed. A demonstration conducted only after repeated brightness and angle adjustments may be a poor fit for a busy desk even though a decode eventually succeeds.
Do not assume a “screen mode” is universal. Zebra DataWedge 15.0 documents an LCD mode for applicable scan modules and notes possible performance effects. That manufacturer-specific example shows why a setting needs its exact device and software scope. It does not establish that the same control exists on an AIDC GO configuration. Source: Zebra DataWedge 15.0, Barcode Input
Compare what the demonstration actually proves
Keep a short comparison record that follows the input through to its destination. Each row below is a different observation; none can stand in for all the others.
| Demonstration | What to retain | Limits of this observation |
|---|---|---|
| Physical phone display read by the proposed handheld | Phone and handheld configuration, visible symbol, presentation conditions and returned value. | Does not establish reading from other displays, settings or code layouts. |
| Saved image decoded inside an application | Original image, decoder and application versions, and decoded value. | Does not establish optical capture from a physical phone screen. |
| Application finds the expected booking | Decoded value, test booking identity and the application's displayed match. | Does not establish that the collection is permitted or that handover was recorded. |
| Operator completes the permitted handover | Application result and the backend record required by the project's acceptance rules. | Does not establish that every phone presentation or interruption case will work. |
A supplier can use a fixed test code to separate optical behaviour from changing business data. The project must also exercise its real presentation pattern before accepting the workflow. Where a booking service refreshes or expires a code, agree with its owner which samples can be used, what is expected after expiry and how the test result is checked. Do not assume that every QR code is dynamic or that a screenshot is always acceptable.
For the collection-desk illustration, compare a normal presentation with one documented difficulty at a time. For example, use the same test booking at the intended size, then repeat with the permitted phone cover in place. Record whether the operator had to change posture or ask the driver to alter the display. The team should decide what adjustment is acceptable before observing the result.
Define repetitions and acceptance criteria for this project. This article supplies no universal reading distance, screen brightness, timing or success-rate target. If the sample set does not represent the phones and presentation software expected at the desk, restrict the conclusion to the tested set.
Separate a decoded value from permission to act
A decoder result tells the application what was read. It does not tell the operator whether a booking belongs to this driver, whether the collection has already been completed or whether the displayed code is still valid. The application and booking-system owners define those checks and the operator feedback.
Keep a known test value beside the observed result. A beep followed by an unrelated screen update is weak evidence when more than one code or identifier is visible. Check the actual identifier received, the intended field and the record selected. The existing wedge, Intent and SDK comparison explains delivery paths; this evaluation concerns the displayed sample travelling through the chosen path.
If the network response is missing, do not keep scanning to make the interface look complete. The owner needs a defined way to establish the outcome before another business action. Follow the project's rules for unconfirmed operations and offline recovery rather than treating a second optical read as a resolution.
Likewise, do not label a successful phone-screen scan as a formal barcode-quality verification. A reading observation and a verification report answer different questions. The scanning versus verification guide covers that boundary without requiring the collection-desk team to repeat a general label study.
Make the hardware enquiry specific
Send the proposed task, a non-sensitive sample of the actual display, expected code format, presentation position and receiving application to Integration & Support. Identify whether the enquiry concerns an integrated scan option, a camera application or both. Request a response tied to the model, configuration and document revision that the supplier proposes.
Keep the sample result with that response. If only a file-decoding demonstration is available, the next decision is to arrange a physical-screen evaluation, not to declare optical compatibility. If optical capture is satisfactory but booking acceptance is unclear, take the remaining question to the application owner rather than changing the scanner without evidence.
The useful outcome is a configuration shortlist supported by a reproducible presentation and a clear handover result. It is not a promise that every display, symbol or booking system will behave alike.