Choose a charging arrangement by following the handheld through a working shift, its planned interruption and its return to service. Keeping the same device on charge, replacing its battery and handing over a spare device create different hardware and application requirements. A removable battery alone does not establish hot-swap support or uninterrupted work.
The purchasing question is not simply how many hours a battery might last. It is whether the proposed devices, batteries, chargers and operating procedure can keep the required tasks covered, with a clear way to recover work after an interruption.
Start with the next handover, not a battery-life headline
Consider an illustrative warehouse with two consecutive shifts sharing handhelds. This is an editorial scenario, not a customer case or an AIDC GO test. Some operators return their devices at a planned break; others finish a picking task close to the next shift's start. The incoming team needs equipment that is ready for its own work, not merely equipment that has been placed in a cradle.
Record when each device can actually leave service, where it can be charged and when it must be available again. Include walking to the charging point, the approved shutdown or swap procedure, any sign-in and the check that the correct application task has resumed. A charging window on a schedule is not automatically the same as usable charging time.
Describe the workload used to judge readiness: scanning and screen use, the application, radios, accessories and operating conditions. Ask for the battery and charging evidence for that configuration. Do not turn a supplier's result under a different workload into an entire-shift guarantee.
The existing deployment readiness checklist covers broader rollout responsibilities. Here, keep the discussion on the rotation between working equipment, equipment being charged and equipment ready to issue.
Compare three ways to keep work covered
Use the following comparison to identify the arrangement worth evaluating. The rows are alternatives to investigate, not confirmation that a particular AIDC GO model supports each one.
| Arrangement | What to establish before selecting it | What this arrangement does not establish |
|---|---|---|
| Charge the working handheld during planned downtime | Whole-device charging: identify an available charging window and the exact device, battery, power supply and charging accessory. | Whole-device charging does not establish that a short break restores enough charge for the remaining workload. |
| Keep the handheld and exchange its battery | Battery exchange: confirm that replacement is permitted, the required device state and procedure, and how a ready battery is identified. | Battery exchange does not establish hot-swap support, preserved application state or a supported replacement-time window. |
| Issue another ready handheld | Spare-device handover: confirm application provisioning, operator access, task ownership and the status of work left on the first device. | Spare-device handover does not establish that unsent work or an active task automatically transfers to the replacement device. |
Compare complete kits and procedures. A spare battery requires a supported way to charge it. A spare handheld requires its own ready-to-work configuration. A cradle with several physical slots is useful only when the proposed power and accessory arrangement supports the intended charging use.
Also consider who uses the equipment during the transition. Sharing a device across shifts is different from handing another device to the same operator in the middle of a task. The application owner should define which action ends one person's responsibility and starts the next person's work.
Ask what battery replacement means on the exact configuration
Request the replacement procedure for the proposed model, battery part number and relevant software revision. Establish whether the device must shut down, enter a named swap mode or follow another documented sequence. Ask which accessories must be removed and how the operator confirms that the replacement battery is correctly secured.
For a model-specific example, Zebra's TC52x/TC57x battery replacement instructions require a swap mode, an indicator-controlled wait and a defined replacement window, with a warning about data loss. Those are instructions for the named Zebra devices. They do not establish an AIDC GO swap mode, time allowance or data-retention capability.
Use terms such as removable, replaceable and hot-swappable only with the supplier's definition and applicable conditions. Ask what remains powered, whether the operating system restarts and what the application is expected to do. A demonstration that the screen returns is not enough to show that a business operation has been safely preserved.
Do not improvise a live battery removal to discover the answer. Follow the model's documented procedure, and agree any interruption tests with the equipment and application owners before performing them.
Separate device recovery from task recovery
After a swap or spare-device handover, check the operator identity, selected task, entered but unsubmitted values and the last confirmed business result separately. These states can have different owners and persistence mechanisms. Seeing the same screen does not by itself establish that the backend accepted the previous operation.
Android's guidance on saving UI state distinguishes in-memory state, saved UI state and persistent storage. It explains that a ViewModel does not survive system-initiated process death and that UI saved-state mechanisms are not long-term storage. This supports asking the application team about its recovery design; it does not prove that any particular app safely handles power removal.
If a confirmation was missing before the interruption, the incoming operator needs the application's defined way to identify and resolve that uncertain operation. Repeating the scan or pressing Confirm again is not a universal recovery method. Use the existing offline barcode capture guide for pending operations, lost confirmations and retry conditions.
For an agreed evaluation, observe a handover after a completed operation, with an unsent operation, and with a result that is still unknown. Record the application and backend evidence for each case. These are suggested checks, not tests already performed, and the correct outcome must come from the application's transaction contract.
Measure the charging rotation under the proposed conditions
Request evidence for the exact battery, charger or cradle, power supply and cable arrangement. Identify the starting charge, the required ready-to-issue condition, temperature and whether the handheld is asleep or working. Keep device charging and spare-battery charging results separate.
For example, Zebra publishes separate instructions for charging the TC52x family device and charging its spare battery. The device instructions specify charging conditions, while the spare-battery instructions describe a separate slot and charging indication. These examples show why the arrangement must be identified; their times and battery-life statements are not AIDC GO specifications.
Create a short rotation log showing when equipment leaves service, starts charging, meets the agreed readiness condition and returns to an operator. Include periods when all intended charging positions are occupied. If charging is delayed or interrupted, record the actual indication and resulting availability rather than assuming the original schedule still holds.
Size the proposed spare pool from that observed overlap, the service requirement and the permitted interruption. There is no universal number of spare batteries or percentage of spare handhelds that this article can justify. Make allowances for equipment unavailable for inspection or maintenance explicit, and review the plan when the workload or battery condition changes.
Use the supplier's battery safety, storage and charging instructions throughout. An abnormal battery or charging indication needs the documented response, not a workaround designed to keep the rotation moving.
Send a configuration request that includes the interruption
Start with the listed models in the handheld terminals category. Send the intended model and deployment country, application and OS requirements, shift and break pattern, charging locations and the work that must remain covered. If replacing existing equipment, include the battery, charger, power supply and accessory part numbers rather than a family name alone.
Ask for the applicable replacement instructions, charging arrangement and evidence conditions, including any dependency on software or accessory revision. Bring screenshots of the application states around a handover, with confidential information removed. Integration Support is the existing route for model, interface and documentation questions.
The equipment discussion should establish what configuration can be evaluated. The customer application team must define task ownership, durable recording and recovery of unconfirmed results. Neither party's answer should be substituted for the other's evidence.
Contact AIDC GO with the proposed working rotation and open configuration questions. A useful starting request states when the equipment can pause, what must be ready for the next operator and which parts of the procedure still need confirmation.