The on-device client itself knows only what the framework tells it to prompt for and display in the form of Data Items. These Data Items can be split down into three groups with an additional related set for what to display on-screen.
Communication between the device and the framework are handled using four separate types of data containing individual Data Items.
The Data entered/scanned on the client. This may be more than one piece of data dependent upon the barcode. GS1 barcodes may contain several pieces of information (Data Item) in one scan; this is not handled by a separate round-trip for each Data Item, all data for validation is provided in one round-trip.
Device Enquiries (detailed in the user guide) also use this mechanism for defining Filters prior to displaying data.
The data collected so far. Context is usually required during validation – for instance if you are validating the item on a purchase receipt you need the purchase order number entered on a previous round trip. The contextual data collected so far is not maintained anywhere in the framework between round trips, for the sake of simplicity the device collects then maintains the contextual data until we are ready to Post.
The Clever Handheld Frameworks response to the Validation and Contextual data passed. What have we collected, what data has changed, which DataItems are now locked etc.
ColumnStyle / ColumnStyleGroup
Tells the device client what grouped data (From the data collected so far) to display onscreen.
Device Enquiries do not require ColumnStyleGroup but ColumnStyle is supported.
These pieces of information come under the umbrella turn DataItem. Each is a collection of DataItems.
DataItems are individual pieces of information required to complete a transaction, which can also be linked to GS1 application identifiers (Such as identifiers for item number, EAN number, lot, serial and quantity).
There are currently four request types: Get, Post, Cancel, Close.
A normal round trip consists of a ‘Get’ – on the first-round trip this initialises the required DataItems on the device. On subsequent round trips this validates the data entered on the device.
Once all DataItems have been collected and locked off, Post occurs. This is the point where posting or registration occurs. For instance, posting a warehouse receipt.
Device Enquiries treat a Post as a request to run the query (All filter data has been collected, query and return the results).
Individual DataItems can be cancelled during entry, this type of request indicates there are DataItems to cancel.
When a function is closed on the device (By clicking the Close button) a request is made of this type.
Useful for such processes as Inventory Picking, where the Post request populates and splits the inventory pick lines and posting itself only occurs when the inventory pick is complete, or the Close button is pressed.
Close is not required or supported in enquiries.