Renovotec · Android integration architecture
An existing warehouse system. A different way to put it in someone’s hands.
The integration boundary · Explanatory diagram
Warehouse systems can retain terminal-style workflows while operators use newer devices. The integration problem is to carry the meaning of those workflows onto a small back-of-hand display without treating the display as a miniature terminal.
I architected the Android bridge and its Intent-based communication with the ProGlove MAI device. The work sat between an existing Teremware workflow and a different operator interface. It did not replace the warehouse management system or constitute a production rollout.
Teremware translates an older terminal-style warehouse system into modern picking workflows. The next requirement was back-of-hand picking rather than only voice interaction.
I architected the Android application that connected this workflow to the hand scanner through Intents. That meant working within an existing system while designing the new device-facing integration.
The operator needs a clear next action, not an entire terminal screen squeezed onto a small display. The photographs show three concrete states: an order overview, pallet/product picking information and a check-digit error.
The bridge brings those workflow states to the wearable. The device and warehouse system remain distinct components; my contribution was the Android integration architecture.
The proof of concept reached physical hardware. The visible error state is particularly useful evidence: feedback from the workflow can reach the operator on the device.
The next step beyond this proof of concept is validating the wider production integration and its failure handling.
The following decisions connect the implementation to its practical constraints. Each separates what I changed from what still needs verification.
Different evidence answers different questions. This record distinguishes a visible demonstration, implementation history and validated operational outcomes.
What it supports: Show an order overview, a picking prompt and a check-digit error on the MAI.
What it does not establish: Identifiers are masked. The images establish visible states, not transaction-level traceability or a performance result.
What it supports: Shows the terminal-side location/check-digit workflow that provides context for the integration.
What it does not establish: The console and wearable images are related examples, not a synchronised capture of one transaction.
What it supports: Supports my responsibility for Android integration architecture and Intent-based communication.
What it does not establish: Commercial source remains private; production rollout and full failure-path validation are not claimed.
The value of the proof of concept is that the integration reached physical hardware and presented both task information and error feedback. That is a concrete result without needing to invent a time-saving percentage.
The next acceptance work would validate longer sessions, interruptions, invalid input and recovery across the full integration. The current photographs cannot answer those questions, so I do not present them as doing so.