Printing instruction transmission method and electronic equipment

Abstract

The invention discloses a printing instruction transmission method and electronic equipment, the printing instruction transmission method is applied to the electronic equipment, the electronic equipment is connected with a printer, the electronic equipment comprises a service access layer, an application control layer and a communication routing layer, and the method comprises the following steps: receiving externally input original printing data through the service access layer and analyzing an access protocol type; calling a corresponding protocol analysis module according to the access protocol type, and converting the original printing data into an intermediate format instruction; acquiring a connection configuration strategy in the current environment; and determining a target transmission channel in various preset candidate transmission channels through the communication routing layer according to the connection configuration strategy, and sending the intermediate format instruction to a printer through the target transmission channel to execute printing operation. Decoupling of service logic and underlying communication is achieved through the layered architecture, multiple access modes are supported, the development cost is reduced, and the system compatibility is improved.

Description

Technical Field

[0001] This invention relates to the field of electronic communication and printing control technology, and in particular to a printing command transmission method and electronic device. Background Technology

[0002] When existing POS machines or cash registers handle printing business, changes in the hardware connection environment often require modifications to a large amount of native code and recompilation of the application, which greatly increases the development difficulty and maintenance costs. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a printing instruction transmission method and electronic device, so as to realize the unified processing and decoupling of printing instructions from different sources and the underlying transmission channel.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A printing instruction transmission method is applied to an electronic device connected to a printer. The electronic device includes a service access layer, an application control layer, and a communication routing layer. The method includes: The service access layer receives raw print data from external input and parses the access protocol type of the raw print data. According to the access protocol type, the corresponding protocol parsing module in the service access layer is invoked to convert the raw print data into intermediate format instructions; The application control layer is invoked to obtain the connection configuration policy under the current environment. The connection configuration policy includes a user-preset mode and an automatic identification mode. The communication routing layer is invoked to determine the target transmission channel from a variety of preset candidate transmission channels according to the connection configuration strategy; The intermediate format instruction is sent to the printer via the target transmission channel to perform the printing operation.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described printing control method.

[0006] The beneficial effects of this invention are as follows: The service access layer parses the raw data input from the outside and converts it into a unified intermediate format instruction. Then, the communication routing layer automatically determines the target transmission channel from multiple preset candidate channels based on the connection configuration strategy to send the instruction. The intermediate format instruction achieves data normalization, and combined with the dynamic routing mechanism of the routing layer, effectively isolates changes in the upper-layer business logic from the underlying hardware environment, solving the problem in existing technologies where changes in hardware connections require modification of the original code and recompilation. By constructing a layered transmission architecture including a service access layer, an application control layer, and a communication routing layer, complete decoupling of printing services from the underlying communication is achieved. Specifically, the service access layer uniformly converts raw data from different protocols in the upper layer into intermediate format instructions, and the communication routing layer automatically routes and determines the target transmission channel from multiple channels according to the strategy. This multi-layered unified mechanism allows developers to focus on upper-layer content editing without worrying about the details of the underlying communication, solving the technical problem of repeatedly developing and recompiling code for different instruction methods, significantly reducing development costs and improving system compatibility. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a printing instruction transmission method provided in an embodiment of the present invention; Figure 2 A flowchart for printing instruction recognition provided in an embodiment of the present invention; Figure 3 A cross-device communication framework diagram provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] In order to meet the growing demand for POS machine printing, related technologies typically need to adapt to various printing scenarios, including local application printing, browser web printing, and cross-device printing. However, these technologies generally suffer from strong coupling between upper-layer business logic and lower-layer communication transmission, and lack a unified processing mechanism for multi-source heterogeneous commands.

[0013] For example, when developing printing functionality, developers must create multiple sets of underlying driver code for different command input methods such as web interface, Bluetooth API, and Socket communication, as well as different underlying connection methods such as virtual Bluetooth, physical Bluetooth, or local Socket. This means that developers need to master multiple technology stacks, including web development, native Android development, and underlying communication protocols. When the hardware connection environment changes (e.g., switching from an external Bluetooth printer to a built-in Socket printer, or needing to support new web access methods), the original business logic code cannot be directly reused. Developers often need to modify a large amount of native code and recompile the entire application, resulting in high development costs, repetitive work, and difficult maintenance.

[0014] Furthermore, the lack of a unified intermediate layer routing and command conversion mechanism in related technologies results in poor device compatibility. External devices (such as mobile phones and tablets) or web pages cannot directly drive printers with different hardware configurations, making it impossible to achieve the effect of "develop once, run on multiple devices," thus limiting the flexibility and scalability of web-based lightweight printing services.

[0015] To address the aforementioned problems, this application provides a method for transmitting printing instructions and an electronic device. The printing instruction transmission method of this application is described in detail below.

[0016] The printing instruction transmission method in this application can be used in scenarios such as local application printing, local browser web printing, and cross-device web printing. The electronic device in this application can be an electronic device running the Android operating system and connected to a printer, such as a POS machine or cash register.

[0017] The following describes in detail a printing instruction transmission method of the present invention, with reference to the appendix. Figure 1 This includes steps 110 to 150.

[0018] Step 110: Receive the raw print data input from the outside through the service access layer and parse the access protocol type of the raw print data.

[0019] Please refer to Figure 3 The service access layer, acting as the interface between electronic devices and external input sources, can listen to and capture data streams from different sources. Access protocol types are used to distinguish the communication protocol characteristics of the data source, such as whether it's a call from a web browser, an HTTP network request, or a Bluetooth transmission.

[0020] Step 120: Based on the access protocol type, call the corresponding protocol parsing module in the service access layer to convert the raw print data into intermediate format instructions.

[0021] The service access layer integrates a parsing module that adapts to different protocols. Regardless of whether the original printed data is based on JavaScript interactive objects, HTTP messages, or BLE feature data, it is normalized in this step, stripping away the headers or encapsulations specific to each protocol, extracting the core printed content, and recombining it into a unified intermediate format instruction.

[0022] Step 130: Call the application control layer to obtain the connection configuration policy under the current environment.

[0023] The application control layer is responsible for managing the device's configuration parameters. Connection configuration strategies include user-preset modes and automatic identification modes. User-preset modes refer to the connection methods manually specified by the user on the interface, while automatic identification modes refer to the system automatically finding available connections based on preset logic.

[0024] Step 140: Invoke the communication routing layer to determine the target transmission channel from a variety of preset candidate transmission channels according to the connection configuration policy.

[0025] The communication routing layer shields the underlying hardware differences and maintains a variety of preset candidate transmission channels. Based on the strategy obtained in step 130, the system makes decisions and performs handshakes among these candidate channels, ultimately locking onto the only available target transmission channel and establishing a stable communication link.

[0026] Step 150: Send the intermediate format instruction to the printer through the target transmission channel to perform the printing operation.

[0027] The communication routing layer sends the standardized intermediate format instruction generated in step 120 to the physical printer through the selected target transmission channel. The printer parses the instruction and completes the printing task.

[0028] In this way, the service access layer parses the raw data input from the outside and converts it into a unified intermediate format instruction. Then, the communication routing layer automatically determines the target transmission channel from multiple preset candidate channels according to the connection configuration policy to send the instruction. The intermediate format instruction achieves data normalization, and combined with the dynamic routing mechanism of the routing layer, effectively isolates changes in the upper-layer business logic from the underlying hardware environment, solving the problem of needing to modify and recompile native code due to changes in hardware connections in existing technologies. By constructing a layered transmission architecture including a service access layer, application control layer, and communication routing layer, complete decoupling of printing services from underlying communication is achieved. Specifically, the service access layer uniformly converts raw data from different protocols in the upper layer into intermediate format instructions, and the communication routing layer automatically routes and determines the target transmission channel from multiple channels according to the policy. This multi-layered unified mechanism allows developers to focus on upper-layer content editing without worrying about the details of underlying communication, solving the technical problem of repeatedly developing and recompiling code for different instruction methods, significantly reducing development costs and improving system compatibility.

[0029] In one embodiment of this application, the protocol parsing process in step 120 includes steps 210 to 230.

[0030] Step 210: If the access protocol type is identified as a web view call, then obtain the interaction data through the web view interface and construct the intermediate format instruction.

[0031] When an electronic device runs an embedded webpage (WebView), the service access layer intercepts or receives interactive data from the webpage through a webpage view interface (such as a JSBridge channel). This interactive data typically contains printable objects constructed from JavaScript, which the system converts into intermediate format instructions.

[0032] Step 220: If the access protocol type is identified as a Hypertext Transfer Protocol request, then obtain the request data through the Hypertext Transfer Protocol interface and construct an intermediate format instruction.

[0033] When an electronic device, acting as a local server, receives an HTTP request from its local browser or other applications, the service access layer parses the HTTP message body through the Hypertext Transfer Protocol interface, extracts the request data, and converts it into intermediate format instructions.

[0034] Step 230: If the access protocol type is identified as a Bluetooth Low Energy protocol request, then obtain the transmission data through the Bluetooth Low Energy service interface and construct the intermediate format instruction.

[0035] When an electronic device is connected as a Bluetooth peripheral, the service access layer listens for write operations of specific characteristic values ​​through the Bluetooth Low Energy service interface, obtains the transmitted data, and converts it into intermediate format instructions.

[0036] In this way, standardized access implementations are provided for three typical POS printing scenarios: embedded in web pages, accessed via local browsers, and cross-device Bluetooth access. Through targeted interface adaptation, the system can convert heterogeneous input data (JS objects, HTTP messages, BLE data packets) into a unified intermediate format instruction before entering the core business logic. This ensures that the subsequent application control layer and communication routing layer do not need to be aware of the differences in the input source, achieving multi-protocol compatibility and unified management of the input end.

[0037] In one embodiment of this application, the process of determining the target transmission channel in step 140 includes steps 310 to 330.

[0038] Step 310: Check if the connection configuration policy contains a user-specified preferred channel.

[0039] The system first reads the configuration parameters set by the user in the application control layer to determine whether the user has explicitly specified Bluetooth or Socket as the preferred connection method.

[0040] Step 320: If the preferred channel is designated as the virtual Bluetooth channel, activate the virtual Bluetooth driver module and establish a virtual Bluetooth connection. If the connection is successful, lock the virtual Bluetooth channel as the target transmission channel.

[0041] The virtual Bluetooth driver module is used to simulate a standard Bluetooth interface. When the user selects this mode, the system attempts to initialize the driver and establish a connection.

[0042] Step 330: If the virtual Bluetooth connection fails to be established, or the preferred channel is specified as the local socket channel, then activate the local socket driver module, establish a local socket connection, and if the connection is successful, lock the local socket channel as the target transmission channel.

[0043] When virtual Bluetooth is unavailable, or when the user explicitly wants to use the more efficient LocalSocket, the system activates the LocalSocket driver module and attempts to establish an inter-process communication connection with the print service process.

[0044] In this way, a priority-based channel selection mechanism was constructed. The system not only allows users to manually specify channels to meet specific business needs (such as legacy code adaptation), but also incorporates automatic fallback or switching logic from virtual Bluetooth to local sockets. By introducing the virtual Bluetooth driver module, the system can simulate Bluetooth behavior without modifying the upper-layer web code; while the local socket driver module provides a more efficient, low-latency transmission path for devices supporting the protocol, thus achieving a balance between compatibility and performance.

[0045] In one embodiment of this application, steps 410 to 430 are also included, which may be performed when determining the target transmission channel in step 140.

[0046] Step 410: When establishing a connection based on the preferred channel fails, read the preset configuration file, obtain the default address of the local socket, and establish a communication connection based on the default address.

[0047] This step initiates the automatic identification mode. When none of the user-configured preferred channels can be connected, the system attempts to read the built-in configuration file to obtain the default address of the local socket and attempt to connect.

[0048] Step 420: If the connection is established successfully, lock the local socket channel as the target transmission channel and return; if the connection fails to be established, start the physical Bluetooth scanning program to search for physical Bluetooth devices that can be connected to the local machine.

[0049] The system performs a connection test on the local socket. If the test fails, it infers that the device may not have an integrated internal printer and instead calls the physical Bluetooth hardware to perform an environmental scan.

[0050] Step 430: Establish a communication connection with the found physical Bluetooth device. If the connection is successful, map the communication connection of the physical Bluetooth device to the virtual Bluetooth driver module, encapsulate the underlying data transmission through the virtual Bluetooth driver module, and lock the virtual Bluetooth channel as the target transmission channel.

[0051] When connected to a real physical Bluetooth printer, the system does not directly expose the physical handle to the upper layer. Instead, it maps the data stream to a virtual Bluetooth driver module. The upper-layer applications still perceive that they are interacting with the virtual Bluetooth, while the lower layer actually transmits data via physical radio frequency.

[0052] In this way, a complete failover and automatic fallback mechanism was designed. Following the order of "user configuration -> default Socket -> physical Bluetooth," a layer-by-layer degradation attempt is made to ensure that an available print output path can be automatically found in various complex hardware environments (such as a faulty built-in printer or the use of an external Bluetooth printer). The step of mapping the physical Bluetooth to the virtual Bluetooth driver maintains the uniformity of the upper-layer interface, eliminating the need for the business layer to write separate code for physical Bluetooth, thus achieving transparency of the underlying hardware to the upper layer.

[0053] In one embodiment of this application, steps 510 to 530 are also included, which can be executed when the corresponding protocol parsing module in the service access layer is called according to the access protocol type in step 120.

[0054] Step 510: When the access protocol type is identified as a Bluetooth Low Energy protocol request, start Bluetooth Low Energy broadcast and configure itself as a server.

[0055] At this point, the electronic device's role changes from a typical Bluetooth master device to a Bluetooth slave device, and it announces its printing service capabilities via broadcast.

[0056] Step 520: Respond to the connection request initiated by the external device and establish a wireless communication link.

[0057] An external device scans and connects to the electronic device as the master device, and the two parties establish a GATT connection.

[0058] Step 530: Listen for and receive data packets written by external devices, and pass the data packets as raw print data to the service access layer.

[0059] Electronic devices listen for write events of specific GATT characteristic values, receive print data sent by external devices, and inject it into the service access layer for further processing.

[0060] In this way, by configuring the electronic device as a BLE server, the pain point of traditional POS machines' inability to support cross-device printing is solved. This mechanism allows external mobile devices to send print jobs directly to this electronic device via the standard WebBluetooth API without installing dedicated drivers, and then this electronic device drives the printer to complete the printing. This greatly expands the use cases for printing services, achieving the technical effect of one device, multiple devices sharing the print job.

[0061] In one embodiment of this application, the process of converting the raw print data into intermediate format instructions in step 120 includes steps 610 to 620.

[0062] Step 610: Read the printing parameters in the original print data according to the access protocol type of the original print data.

[0063] Different access protocols carry data in different ways. The system first extracts the payload according to the protocol type, such as extracting JSON strings from the HTTP Body or concatenating byte streams from BLE data packets, thereby obtaining printing parameters containing information such as layout, content, and paper cutting instructions.

[0064] Step 620: Obtain intermediate format instructions by encapsulating printing parameters according to the preset encapsulation format.

[0065] The system reassembles the extracted printing parameters according to a normalized data structure independent of the transmission channel type. This intermediate format instruction unifies the encoding of control instructions (such as alignment) and data content (such as text and images).

[0066] In this way, by converting heterogeneous raw data from multiple sources into a unified intermediate format instruction, the system logically severs the direct dependency between the input and output ends. Regardless of how the input data changes, as long as it can be converted to the intermediate format, the subsequent routing layer can recognize and send it; regardless of whether the output is Bluetooth or a Socket, as long as the intermediate format can be parsed, printing can be executed. This data normalization process is the core key to achieving decoupling in a multi-layered architecture.

[0067] In one embodiment of this application, steps 710 to 730 are also included, which can be performed after the establishment of the communication link in step 140.

[0068] Step 710: Receive device feedback data returned by the printer through the target transmission channel.

[0069] While sending commands through the target transmission channel, the system keeps monitoring that channel and receives device feedback data reported by the printer. This device feedback data includes status data returned by the printer and command response data.

[0070] Step 720: Parse the device feedback data into standardized feedback results through the communication routing layer.

[0071] The communication routing layer parses the raw feedback data from the underlying layer and maps it into a standardized feedback result common to the system, thereby shielding the differences in the underlying feedback formats of different printers.

[0072] Step 730: Through the service access layer, push the standardized feedback results back to the input terminal corresponding to the original print data.

[0073] The service access layer pushes standardized feedback results to the source of the command (such as a web page or external device) in real time, based on the path of the data source (such as a WebSocket connection).

[0074] In this way, this embodiment constructs an end-to-end bidirectional communication closed loop. Traditional printing solutions are often unidirectional transmissions, making it difficult for upper-layer applications to obtain real-time feedback from the printer. This embodiment, through a mechanism of low-level listening, middle-level parsing, and upper-level push, enables web pages or external devices to obtain printer status and response data in real time, thereby promptly displaying prompts to users and significantly improving the interactive experience and reliability of printing services.

[0075] In one embodiment of this application, after determining the target transmission channel in step 150, steps 810 to 820 are included.

[0076] Step 810: After determining the target transmission channel, if the target transmission channel is a local socket channel, monitor the connectivity of the target transmission channel periodically.

[0077] For local socket channels, the system starts a daemon thread or heartbeat mechanism to periodically check the activity status of the socket connection.

[0078] Step 820: If the target transmission channel is detected to be disconnected, the target transmission channel is re-determined according to the connection configuration policy.

[0079] Once a connection is abnormally disconnected (such as when a service process crashes or is unexpectedly shut down), the system immediately triggers a reconnection mechanism, or, based on the configuration policy, downgrades to another available channel (such as switching from Socket to Bluetooth scanning) to attempt to restore communication.

[0080] This approach enhances the system's robustness and self-healing capabilities. During long-term printing operations, communication links may be interrupted due to various anomalies. Through regular monitoring and automatic reconnection mechanisms, the system can promptly detect link failures and automatically attempt repairs, restoring printing services without manual intervention and ensuring the continuity and stability of POS printing operations in commercial scenarios.

[0081] In one embodiment of this application, after step 120 converts the raw print data into intermediate format instructions, steps 910 to 920 are included.

[0082] Step 910: Store the converted intermediate format instructions into the print data queue.

[0083] The communication routing layer maintains a data queue structure based on the first-in, first-out (FIFO) principle. Intermediate format instructions from different input sources (such as Web, HTTP, BLE) are first stored in this print data queue and waited for their turn before being sent to the printer.

[0084] Step 920: According to the order in which the intermediate format instructions enter the print data queue, send the intermediate format instructions to the printer through the target transmission channel to execute the printing operation.

[0085] The system strictly follows the queue order, retrieving instructions one by one from the head of the queue and sending them to the printer through a designated target transmission channel. Subsequent instructions are processed sequentially only after the preceding instruction enters the transmission process, thus transforming concurrently arriving multi-source instructions into a serial data stream.

[0086] In this way, by introducing a print data queue mechanism, the potential data conflict problem caused by concurrent access from multiple protocols is resolved. Since this system supports multiple input methods simultaneously, without proper control, concurrent transmission of data from multiple sources can lead to disordered print content (i.e., the risk of out-of-order handover documents). By enforcing serial transmission of print commands through queue management, the sequentiality and integrity of print data are strictly ensured, effectively preventing printing errors caused by data interleaving in concurrent scenarios.

[0087] In summary, by constructing a layered transmission architecture comprising a service access layer, an application control layer, and a communication routing layer, the service access layer first performs protocol parsing and normalization on heterogeneous raw print data from external inputs such as web page views, HTTP requests, or Bluetooth Low Energy, generating intermediate format instructions independent of the transmission channel. Then, the application control layer obtains the connection strategy, driving the communication routing layer to dynamically determine the target transmission channel and establish a communication link from multiple candidate channels such as virtual Bluetooth, local sockets, or physical Bluetooth mapping. Based on intermediate format instructions and a multi-level routing mechanism, this scheme logically severs the strong coupling dependency between upper-layer instruction input and lower-layer hardware output, thus solving the technical problem of needing to repeatedly develop driver code and recompile due to differences in instruction methods or connection environments in existing technologies. It achieves the beneficial effect of requiring only one set of business code to adapt to multiple hardware environments and cross-device access, significantly reducing maintenance costs and improving system compatibility and robustness.

[0088] The following combination Figure 2 (A flowchart for recognizing printing instructions) and Figure 3 (A cross-device communication framework diagram) The specific implementation logic of the present invention is explained in detail step by step.

[0089] Step 1: Multi-source data reception and protocol identification (corresponding to) Figure 3The three usage methods in the entry point correspond to the raw print data received from external input in step 110 above.

[0090] The system starts the service access layer and continuously listens for input requests from different ports.

[0091] If a call from a WebView embedded in the APK is detected, the interactive data sent by JavaScript is intercepted through the JSBridge interface; If an HTTP request is detected from the local browser, parse the request data in the HTTP message body; If a connection request from an external device is detected, the electronic device initiates a BLE broadcast and configures itself as a server, responding to GATT connections from the external host device and listening for write operations on specific characteristic values ​​to receive data packets. Based on the different access methods described above, the system parses and determines the access protocol type of the raw printed data.

[0092] Step 2: Instruction normalization conversion, corresponding to the instruction in step 120 above to convert the original print data into an intermediate format.

[0093] The service access layer calls the corresponding protocol parsing module to extract printing parameters (such as text content, layout instructions, and paper cutting actions) from the raw data. The system strips away the communication headers specific to each protocol and reassembles the core printing parameters into a unified data encapsulation format independent of the underlying transmission channel. This step ensures that regardless of whether the data comes from the Web, network, or Bluetooth, it is a homogeneous data stream when it enters the next layer.

[0094] Step 3: Strategy Acquisition and Preferred Channel Determination (corresponding to) Figure 2 Steps S1, S2 and S6 correspond to determining the target transmission channel according to the connection configuration strategy in steps 130 and 140 above.

[0095] The application control layer reads the connection configuration policy for the current environment. The system first determines whether the user has explicitly specified the preferred channel in the configuration interface.

[0096] If the user selects the virtual Bluetooth mode, the virtual Bluetooth connection branch will be entered; If the user selects the local Socket mode, then proceed to the local Socket connection branch; If the user has not configured or the configuration is invalid, the system will enter the automatic recognition mode branch.

[0097] Step 4: Connection establishment in user-preset mode (corresponding) Figure 2 Steps S3 to S5 and steps S7 to S11 correspond to determining the target transmission channel from a variety of preset candidate transmission channels in step 140 above.

[0098] If the virtual Bluetooth branch is entered, the communication routing layer activates the virtual Bluetooth driver module and attempts to establish a virtual Bluetooth connection. If the connection is successful, the channel is locked and the virtual Bluetooth connection status is returned. If the local Socket branch is entered, or the virtual Bluetooth connection fails, the communication routing layer activates the local socket driver module to attempt to establish a local Socket connection. If the connection is successful, the channel is locked and the local Socket connection status is returned.

[0099] Step 5: Automatically identify and map to the physical Bluetooth backup (corresponding) Figure 2 Steps S9 to S14 correspond to the automatic identification mode determination process in step 140 above.

[0100] If none of the above user-preset attempts succeed, the system will enter an automatic fallback process: First, read the configuration file to obtain the default address, and attempt to establish a local Socket connection. If successful, lock the channel and return. If the scan fails, the system initiates a physical Bluetooth scanning program to search for physical Bluetooth devices within the local visual range. It attempts to establish a physical connection with the found devices. If the connection is successful, the system does not directly expose the physical handle. Instead, it maps the communication connection of the physical Bluetooth device to the virtual Bluetooth driver module, encapsulates the underlying data transmission through the virtual Bluetooth interface, and returns the virtual Bluetooth connection status to the upper layer, thus maintaining logical interface consistency.

[0101] Step 6: Timing control and command sending, corresponding to sending to the printer in step 150 above.

[0102] After determining the target transmission channel and establishing the link, the communication routing layer stores the intermediate format instructions generated in step 2 into a first-in-first-out (FIFO) print data queue. The system strictly follows the order in which the instructions enter the queue, sequentially sending the instructions to the physical printer for execution through the selected target transmission channel (virtual Bluetooth, local Socket, or mapped physical Bluetooth) to prevent data corruption caused by concurrent input of multiple protocols.

[0103] Step 7: Two-way feedback and status push (corresponding) Figure 3 (From the Android processing layer to the external device update layer), corresponding to the execution of the printing operation in step 150 above.

[0104] While sending commands, the communication routing layer monitors the transmission channel in real time, receiving device feedback data from the printer (including hardware status such as paper out, overheating, and command response). The system parses this low-level data into standardized feedback results and pushes them back to the source end through the service access layer. For example, in cross-device scenarios, the system sends the status to external devices via BLE GATT notifications; in web scenarios, it pushes the status via JS callbacks, achieving end-to-end closed-loop monitoring.

[0105] In summary, this application constructs a three-layer architecture consisting of a service access layer, an application control layer, and a communication routing layer. Combined with the normalization of intermediate format commands and multi-level cascading channel selection logic, it achieves a highly compatible method for transmitting printing commands. The service access layer unifies heterogeneous input, the communication routing layer masks the differences between underlying layers (virtual / physical Bluetooth, Socket), and a mapping mechanism from physical Bluetooth to virtual Bluetooth drivers and an automatic failover process are specifically designed. This solution completely decouples upper-layer business logic from underlying hardware, eliminating the need for developers to repeatedly develop driver code for different connection methods. Developers only need to write the web business code once to run it directly in various hardware environments. It also supports plug-and-play across devices and real-time status monitoring, significantly reducing development and maintenance costs and improving system robustness.

[0106] Please refer to Figure 4 The present invention also provides an electronic device 400, including a memory 401 and a processor 402, and a computer program stored on the memory 401 and running on the processor 402. When the processor 402 executes the computer program, it implements the various steps of the printing instruction transmission method described above.

[0107] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0108] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for transmitting printing instructions, characterized in that, Applied to an electronic device connected to a printer, the electronic device comprising a service access layer, an application control layer, and a communication routing layer, the method includes: The service access layer receives raw print data from external input and parses the access protocol type of the raw print data. According to the access protocol type, the corresponding protocol parsing module in the service access layer is invoked to convert the raw print data into intermediate format instructions; The application control layer is invoked to obtain the connection configuration policy under the current environment. The connection configuration policy includes a user-preset mode and an automatic identification mode. The communication routing layer is invoked to determine the target transmission channel from a variety of preset candidate transmission channels according to the connection configuration strategy; The intermediate format instruction is sent to the printer via the target transmission channel to perform the printing operation.

2. The printing instruction transmission method according to claim 1, characterized in that, The step of invoking the corresponding protocol parsing module in the service access layer according to the access protocol type includes: If the access protocol type is identified as a webpage view call, then the interactive data is obtained through the webpage view interface to construct the intermediate format instruction; If the access protocol type is identified as a Hypertext Transfer Protocol request, then the request data is obtained through the Hypertext Transfer Protocol interface, and the intermediate format instruction is constructed. If the access protocol type is identified as a Bluetooth Low Energy (BLE) protocol request, then the transmission data is obtained through the BLE service interface to construct the intermediate format instruction.

3. The printing instruction transmission method according to claim 1, characterized in that, The step of determining the target transmission channel from a variety of preset candidate transmission channels according to the connection configuration strategy includes: Check if a user-specified preferred channel exists in the connection configuration policy; If the preferred channel is designated as a virtual Bluetooth channel, the virtual Bluetooth driver module is activated to establish a virtual Bluetooth connection. If the connection is successful, the virtual Bluetooth channel is locked as the target transmission channel. If the virtual Bluetooth connection fails to be established, or if the preferred channel is specified as the local socket channel, the local socket driver module is activated to establish a local socket connection. If the connection is successful, the local socket channel is locked as the target transmission channel.

4. The printing instruction transmission method according to claim 3, characterized in that, Also includes: If no connection is established according to the preferred channel, the default address of the local socket in the preset configuration file is read. Establish a communication connection based on the default address; If the connection is successfully established, the local socket channel is locked as the target transmission channel and the process returns. If the connection establishment fails, a physical Bluetooth scanning program is started to search for physical Bluetooth devices that can be connected to the local machine. A communication connection is established with the found physical Bluetooth device. If the connection is successful, the communication connection of the physical Bluetooth device is mapped to the virtual Bluetooth driver module. The underlying data transmission is encapsulated through the virtual Bluetooth driver module, and the virtual Bluetooth channel is locked as the target transmission channel.

5. The printing instruction transmission method according to claim 1, characterized in that, Also includes: When the access protocol type is identified as a Bluetooth Low Energy (BLE) protocol request, Bluetooth Low Energy broadcast is initiated, and the device is configured as a server. Respond to connection requests initiated by external devices and establish a wireless communication link; Listen for and receive data packets written by the external device, and pass the data packets as the original printed data to the service access layer.

6. The printing instruction transmission method according to claim 1, characterized in that, Instructions for converting the raw print data into an intermediate format include: Read the printing parameters from the original print data according to the access protocol type of the original print data; The intermediate format instruction is obtained by encapsulating the printing parameters according to the preset encapsulation format.

7. The printing instruction transmission method according to claim 1, characterized in that, Also includes: The device feedback data returned by the printer is received through the target transmission channel. The device feedback data includes hardware status information and command response data. The communication routing layer parses the device feedback data into standardized feedback results. The standardized feedback result is pushed back to the input terminal corresponding to the original printed data through the service access layer.

8. The printing instruction transmission method according to claim 1, characterized in that, After determining the target transmission channel from a variety of preset candidate transmission channels according to the connection configuration strategy, the method further includes: If the target transmission channel is a local socket channel, the connectivity of the target transmission channel is monitored periodically; If the target transmission channel is detected to be disconnected, the target transmission channel will be re-determined according to the connection configuration policy.

9. A printing instruction transmission method according to claim 1, characterized in that, Also includes: The converted intermediate format instructions are stored in the print data queue; According to the order in which the intermediate format instructions enter the print data queue, the intermediate format instructions are sequentially sent to the printer through the target transmission channel to execute the printing operation.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the printing instruction transmission method according to any one of claims 1-9.

Images