A new Android handheld does not have to mean a new warehouse application. If the existing system exposes a supported terminal interface, a terminal-emulation client may keep that host workflow in use. But the buying decision includes the client, host connection, scan handling, keys and session ownership—not just a handheld that can display a login screen.
Start by deciding what must stay unchanged: the host application and its transactions, or also the exact operator interaction. Those are different requirements. A touch-friendly presentation may preserve the host while changing how operators select fields and invoke commands. Conversely, a familiar green screen can still behave differently when the scanner or keyboard changes.
Buy a connection to a named host, not “terminal emulation” in general
Ask the application owner for the required terminal type, host endpoint, permitted transport, authentication method and screen dimensions. Have the proposed software vendor map those requirements to a named client release and supported device/OS configuration. A protocol name on a product page is a starting point, not evidence that every host-specific key sequence or display attribute will work.
Honeywell’s public Browsers and Emulators range distinguishes BasicTE and SmartTE offerings. That is evidence that buyers have different software paths to evaluate; it is not a licence entitlement or a compatibility statement for an AIDC GO device. Obtain a current, configuration-specific support statement before including a client in the hardware quotation. Source: Honeywell Browsers and Emulators.
Separate the quote into device and accessories, client software, any required server component, deployment work and ongoing software support. Ask who owns host configuration and who will diagnose a failed scan-to-field interaction. Do not assume the hardware supplier supplies the warehouse system, terminal client or software licence.
Locate the session before comparing reconnection claims
In a device-resident arrangement, establish what happens to the host connection when the client stops. In a server-hosted arrangement, establish where the session lives and what the handheld reconnects to. The same phrase—“resume work”—can describe reopening a login screen, reconnecting to a surviving session or recovering a confirmed business result. The project needs the last two distinguished.
StayLinked’s historical User Experience guide, document SL-1003 JC/RP at its dated 2017 entry, describes a client/server architecture with the terminal session hosted on the server. It also distinguishes session persistence from buffered input: closing the client or rebooting can lose buffered transactions. These are documented boundaries of that example, not universal behaviour or a current-version guarantee. Do not reuse its old defaults or platform descriptions as present-day procurement specifications. Source: StayLinked User Experience.
For the actual proposal, request the matching current documentation and decide who operates the session server, where it runs and how planned outages are handled. Include licence consumption for idle or disconnected sessions in the commercial discussion. A server component can add an operational dependency even when it simplifies handheld replacement; its support and recovery arrangements belong in the quote.
Keep the host transaction, redesign only the interaction that needs it
Use three possible paths to frame the choice. These are purchasing alternatives, not promised modes on every client.
| Path | Why consider it | Trade-off to resolve |
|---|---|---|
| Preserve the terminal layout | Why consider it: Operators retain familiar field positions and command sequences. | Trade-off: The full host screen, prompts and error messages must remain usable on the selected handheld. |
| Use client-side presentation changes | Why consider it: A supported client may present selected host interactions in a more usable mobile layout. | Trade-off: Name the owner of mappings and test changed host screens before rollout. |
| Move to a different application interface | Why consider it: Required workflow changes may exceed what a terminal presentation can reasonably provide. | Trade-off: This is an application migration with its own integration scope, not merely a handheld replacement. |
Do not hide necessary information to make a screen look cleaner. An exception prompt, selected warehouse or active order may matter more than the main quantity field. Compare the normal screen with its validation-error state and with the on-screen keyboard open. For the separate physical input decision, use the touchscreen and keypad workflow guide.
A picking example exposes the real purchase boundary
Editorial example—not a customer deployment or measured test: a warehouse intends to replace ageing terminals while keeping its host picking application. A test order requests location A-12, item 004821 and quantity 6. The host uses a function key for a short-pick exception. The proposal offers an Android handheld with a terminal client.
First, open the permitted test order and scan the location. Confirm that A-12 reaches the location field without also sending a second confirmation. Then scan 004821 and verify the leading zeros, field destination and resulting host screen. Enter 6, change it to 4 and invoke the short-pick action. The useful outcome is a host-recognised exception with the intended quantity—not simply visible text on the handheld.
If Enter advances two fields, identify whether the scanner adds a terminator, the client maps it, or a separate key action duplicates it. Change only the responsible layer and repeat the affected sequence. The wedge, intent and SDK guide explains the capture-to-application boundary; the terminal project must additionally establish how the client sends the host’s expected actions.
Next, under the application owner’s test procedure, interrupt the connection after a quantity is entered but before its outcome is clear. On return, identify the session and ask the host owner to verify whether the transaction was accepted. Do not scan again just because the prior screen reappears. Test client restart separately from a short network interruption: surviving session state does not prove that every local input survived. A warehouse roaming assessment answers a different question about the moving network path.
This example can reject a seemingly suitable quotation for a specific reason: an essential exception key is inaccessible, an error prompt is off-screen, or the supported client cannot deliver the required scanner event. It should not become a claim that all terminal clients fail or that an untested device is compatible.
Make the quotation match the supported combination
Request the exact handheld configuration, Android build, scanner interface, client release, host type, key map and transport arrangement. Ask the software vendor to state support, licence and upgrade conditions for that combination. Keep a small set of representative host screens and input sequences with the decision, including one correction and one exception; these explain why the configuration was selected.
Use the AIDC GO device catalogue to identify hardware to discuss, then send sanitised host-screen examples and the proposed client details to Integration Support. Do not send live credentials or customer records. If the client vendor has not confirmed the device and OS, describe that as an open integration dependency rather than an AIDC GO compatibility promise.
A useful purchase decision is conditional and specific: keep the host with the supported terminal combination, revise the client presentation where justified, or scope an application change where the required workflow cannot be supported. Contact AIDC GO with that decision context for hardware selection and integration enquiries; this guide does not claim that AIDC GO supplies a terminal-emulation platform.