Cross-platform scanner application implementation system and method thereof

Abstract

The cross-platform scanner application implementation system comprises a service layer and an application layer which are mutually independent, the service layer and the application layer adopt a separated development mode, and development technology stacks of the service layer and the application layer do not depend on each other. The method comprises the steps of constructing a service layer; constructing an application layer; starting a local server module of the service layer, and enabling the service layer to enter an HTTP request monitoring state; a user initiates an operation request through the UI view module of the application layer, and the service logic module of the application layer converts the operation request into an HTTP request and sends the HTTP request to the service layer; after the service layer receives the HTTP request, a request instruction is analyzed, a scanner is called through a TWAIN development kit to execute corresponding operation, and an operation result is returned to the application layer through HTTP response; and the application layer receives the HTTP response, processes result data through the service logic module, and presents a processing result to a user through the UI view module. According to the method, the limitation of the whole application on a technology stack is liberated, and a user interface layer, a business logic layer and a scanning service layer can be constructed by using different languages and technology stacks.

Description

Technical Field

[0001] This invention relates to the field of scanners, specifically to a cross-platform scanner application implementation system and method. Background Technology

[0002] A scanner is a device that captures images. As a computer peripheral product that integrates opto-mechatronics, the scanner is the third largest computer input device after the mouse and keyboard. It can convert images into digital formats that computers can display, edit, store, and output, making it a very powerful input device.

[0003] A complete scanning process consists of the following modules: 1. Scanner Hardware: This refers to the physical scanner device, manufactured by the scanner manufacturer. 2. Scanner Driver: Provided by the scanner manufacturer, acting as a translator between the operating system and the scanner hardware, responsible for providing a standardized programming interface to the hardware. 3. Scanner API: Provides a unified and standardized way for applications to discover, configure, and control the scanner, acquire image data, and shields the differences between different drivers and hardware. Depending on the operating system, the mainstream API standards currently include TWAIN (Win / macOS / Linux), WIA (Win), SANE (Linux / nix), and ICA (macOS). 4. Scanning Application: The user-interactive interface, providing rich scanning functions and workflows. It offers a user-friendly interface that allows users to control the scanner hardware, select scanning parameters (such as resolution, color mode, scan area, file format, etc.), start the scanning process, receive the scanned image data, and perform subsequent processing (such as previewing, editing, saving, printing, OCR, etc.).

[0004] Modern scanner programs typically employ a layered architecture: 1. User Interface Layer: Provides a graphical user interface; 2. Business Logic Layer: (1) Handles user interaction events (button clicks, settings changes). (2) Manages scanning sessions (parameter settings, start / stop scanning). (3) Calls underlying scanning services or libraries to obtain image data. (4) Performs image processing operations (rotation, cropping, applying filters). (5) Handles file saving / output logic. (6) Other business logic. 3. Scanning Service Layer: This is the core layer for interacting with scanning hardware and drivers, abstracting the underlying scanning API for the business logic layer to call.

[0005] However, existing technical solutions typically involve binding the scanner API to the scanning application during development. The scanner API is treated as part of the scanning application project, and the same programming language is used to develop the user interface layer, business logic layer, and scanning service layer simultaneously within the same project, producing the overall scanning application package using a unified construction method. This approach imposes significant limitations on the technology stack for the entire application. Therefore, it is essential to propose a cross-platform scanner application implementation system and its methodology. Summary of the Invention

[0006] The purpose of this invention is to provide a cross-platform scanner application implementation system and method, which can liberate the overall application from the limitations of the technology stack, so as to solve the existing technical defects and unmet technical requirements.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a cross-platform scanner application implementation system, comprising a service layer and an application layer that are independent of each other and communicate with each other through an HTTP interface;

[0008] The service layer includes the TWAIN SDK and a local server module. The TWAIN SDK is used to call the driver corresponding to the scanner hardware. The local server module is used to encapsulate the scanner operation as an HTTP service and provide an HTTP API to the outside world. The HTTP API at least covers the functions of starting the scanner and opening the scanner driver configuration window.

[0009] The application layer includes a UI view module and a business logic module. The UI view module provides a user interface, and the business logic module implements scanner parameter configuration, scanning operation execution, and post-scanning image editing functions by calling the HTTP API of the service layer.

[0010] Preferably, the service layer and the application layer adopt a separate development model. The service layer is built using a technology stack that supports TWAIN protocol and HTTP service development, and the application layer is built using a technology stack that supports UI development and HTTP interface calls. The development technology stacks of the service layer and the application layer are independent of each other.

[0011] Preferably, the TWAIN development kit of the service layer interacts with the scanner driver to shield the differences in scanner hardware under different operating systems (Windows / macOS / Linux), thereby enabling cross-platform access to scanner hardware.

[0012] In this application, the TWAIN protocol itself is cross-system, and the scanner driver call here is handled by the open-source TWAIN SDK.

[0013] Preferably, after startup, the local server module listens for HTTP requests on a preset port in real time. When it receives an HTTP request sent by the application layer, it parses the operation instructions in the request, calls the corresponding scanner function through the TWAIN development toolkit, and returns the operation result to the application layer in the form of an HTTP response.

[0014] Preferably, the business logic module includes an image data processing unit, which receives scanned image data returned by the service layer, performs editing operations such as rotation, cropping, and filter application, and saves the edited image data in a preset file format (JPEG / PNG / PDF).

[0015] A method for implementing a cross-platform scanner application includes the following steps:

[0016] S1: Build a service layer, connect to the scanner driver through the TWAIN development toolkit, develop a local server module, and encapsulate scanner operations (start scanning, open driver configuration window) as HTTP API, so that the service layer has independent scanner access and HTTP service provision capabilities;

[0017] In this application, "scanner operation includes, but is not limited to: selecting scanner device, starting scanning task, opening driver configuration window, and acquiring scanned image data;

[0018] S2: Build the application layer, develop the UI view module to provide the user interaction interface, and develop the business logic module to handle user operation events. The business logic module calls the HTTP API of the service layer in step S1 through the HTTP protocol.

[0019] S3: Start the local server module of the service layer, so that the service layer enters the HTTP request listening state;

[0020] S4: The user initiates an operation request (configure scanner parameters, start scanning) through the UI view module of the application layer. The business logic module of the application layer converts the operation request into an HTTP request and sends it to the service layer.

[0021] S5: After receiving the HTTP request, the service layer parses the request instructions, calls the scanner to perform the corresponding operation through the TWAIN development toolkit, and returns the operation results (scanned image data, operation status) to the application layer through an HTTP response;

[0022] S6: The application layer receives the HTTP response, processes the result data (image editing, status display) through the business logic module, and presents the processing results to the user through the UI view module.

[0023] Preferably, in step S1, when encapsulating the HTTP API, the local server module of the service layer assigns a unique API interface path to each scanner operation instruction and defines the request parameter format (including scanner device identifier, scanning resolution, color mode and scanning area parameters, etc.) and response data format (including operation success identifier, image data URL / binary stream and error information, etc.).

[0024] Preferably, in step S4, before sending an HTTP request, the application layer business logic module first verifies the validity of the scanning parameters (resolution, color mode) input by the user. If the parameters are valid, an HTTP request that meets the requirements of the service layer API is generated. If the parameters are invalid, the user is prompted to correct the parameters through the UI view module.

[0025] Preferably, in step S5, when the service layer calls the scanner driver configuration window through the TWAIN development kit, the driver configuration window is directly displayed on the operating system desktop. After the user completes the parameter settings in the configuration window, the configuration information is synchronized from the scanner driver to the service layer, and the service layer performs subsequent scanning operations based on the synchronized configuration information.

[0026] Preferably, in step S6, after receiving the scanned image data, if the user initiates an image editing request, the application layer business logic module processes the image data by calling the built-in image processing algorithm (rotation algorithm, cropping algorithm). After processing, a file saving option is provided. After the user selects the saving format, the business logic module encodes the image data into a file of the corresponding format and stores it in the path specified by the user.

[0027] Compared with the prior art, the beneficial effects of the present invention are:

[0028] 1. The scanner API and scanning application are developed separately. The scanning service layer is isolated from the user interface layer and business logic layer as an independent project. It is provided to the business logic layer for calling via HTTP interface. This frees the overall application from the limitations of the technology stack. Different languages ​​and technology stacks can be used to build the user interface layer, business logic layer and scanning service layer. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the overall logic of the present invention; Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Please see Figure 1 Embodiments of the present invention:

[0032] Example:

[0033] like Figure 1 As shown:

[0034] Development Environment and Technology Stack Selection

[0035] Service layer

[0036] Development language: JavaScript (good cross-platform support, excellent HTTP service performance);

[0037] TWAIN component: Node-TWAIN SDK (supports Windows / macOS / Linux, providing interfaces for scan initiation, parameter reading, and image acquisition);

[0038] HTTP service framework: Node.js (lightweight, supports rapid construction of RESTful APIs);

[0039] Application layer

[0040] Development framework: Electron 25.0 (supports cross-platform desktop application development and can integrate front-end technologies);

[0041] Front-end technology: React.js (UI development, supporting responsive interfaces);

[0042] Image processing library: sharp-electron (supports image rotation, cropping, and editing);

[0043] HTTP request library: Axios (sends HTTP requests and processes responses);

[0044] Build tool: electron-forge (generates desktop application installers for Windows / macOS platforms).

[0045] Service layer API design

[0046] 1. Determine if the local service is starting normally.

[0047] `GET / api / twain / status`

[0048] Input parameters: empty

[0049] Returns: JSON

[0050]

[0051]

[0052] 2. Select one from multiple scanners

[0053] The `GET / api / twain / select_source` parameter is empty. The return value is JSON.

[0054]

[0055] 3. Launch the scanner driver configuration GUI: `GET / api / twain / config`

[0056] Input parameter: empty; Return value: json

[0057]

[0058]

[0059] 3. Start scanning

[0060] While scanning, the scanned files will be saved in a folder named after the date under the "scanner_saved" folder in the "Pictures" directory: `C:\Users\[Current Windows Username]\Pictures\scanner_saved`

[0061] `POST / api / tawin / start_scan`

[0062] Input parameters: empty

[0063] 4. Poll to obtain scanned images

[0064] ` / api / twain / start_scan` pushes the paths of the scanned files into a queue, and this API retrieves the scanned images from the queue.

[0065] `GET / api / twain / dequeue_file`

[0066] Input parameters: empty

[0067] return:

[0068]

[0069] Application layer functionality implementation

[0070] 1. Open scanner settings

[0071] 2. Scan

[0072] 3. Image naming

[0073] 4. Image sorting

[0074] 5. Image Upload

[0075] 6. Image Barcode OCR

[0076] 7. Other business functions

[0077] Cross-platform verification

[0078] 1. Windows platform: Windows 11

[0079] 2. MacOS platform: MacOS 15.6

[0080] Verification results

[0081] 1. All application-level functions are available and functioning normally on Windows 11.

[0082] 2. All application-level functions are available on macOS 15 and

[0083] Advantages and effects

[0084] The application layer and service layer are separated. The application layer and service layer can be written in the programming languages ​​that the developers are good at, respectively, for scanning logic, GUI and business logic. If a cross-platform language and framework are selected, it is possible to write once and reuse it on multiple platforms.

[0085] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the scope of the invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0086] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A cross-platform scanner application implementation system, characterized in that, it comprises a service layer and an application layer which are independent of each other and communicate through an HTTP interface; the service layer comprises a TWAIN development kit and a local server module, the TWAIN development kit is used to call the driver corresponding to the scanner hardware, and the local server module is used to encapsulate scanner operations as HTTP services and provide HTTP APIs externally, the HTTP APIs at least cover the functions of starting scanner scanning and opening a scanner driver configuration window; the application layer comprises a UI view module and a business logic module, the UI view module is used to provide a user interaction interface, and the business logic module is used to realize scanner parameter configuration, scanning operation execution and post-scanning image editing processing functions by calling the HTTP APIs of the service layer.

2. The cross-platform scanner application implementation system of claim 1, wherein, The service layer and the application layer adopt a separate development mode, the service layer is built with a technology stack supporting TWAIN protocol and HTTP service development, the application layer is built with a technology stack supporting UI development and HTTP interface calling, and the development technology stacks of the service layer and the application layer are independent of each other.

3. The cross-platform scanner application implementation system of claim 2, wherein, The TWAIN development kit of the service layer shields the differences of scanner hardware under different operating systems by interacting with the scanner driver, and realizes cross-platform scanner hardware access capability.

4. The cross-platform scanner application implementation system of claim 3, wherein, After being started, the local server module listens to HTTP requests of a preset port in real time, parses operation instructions in the HTTP request received from the application layer when the HTTP request is received, calls corresponding scanner functions through the TWAIN development kit, and returns operation results to the application layer in the form of an HTTP response.

5. The cross-platform scanner application implementation system of claim 4, wherein, An image data processing unit is arranged in the business logic module, the image data processing unit is used to receive scanned image data returned by the service layer, and perform editing operations such as rotation, cropping and filter application, and save the edited image data in a preset file format.

6. A cross-platform scanner application implementation method, characterized by, It comprises the following steps: S1: constructing a service layer, connecting a scanner driver through a TWAIN development kit, developing a local server module, encapsulating scanner operations as HTTP APIs, and enabling the service layer to have independent scanner access and HTTP service providing capabilities; S2: constructing an application layer, developing a UI view module to provide a user interaction interface, and developing a business logic module to process user operation events, the business logic module calling the HTTP APIs of the service layer in step S1 through an HTTP protocol; S3: starting the local server module of the service layer, so that the service layer enters an HTTP request listening state; S4: a user initiates an operation request through a UI view module of the application layer, and a business logic module of the application layer converts the operation request into an HTTP request and sends it to the service layer; S5: after receiving the HTTP request, the service layer parses the request instructions, calls the scanner to perform corresponding operations through the TWAIN development kit, and returns the operation results to the application layer through an HTTP response; S6: The application layer receives the HTTP response, processes the result data through a business logic module, and presents the processing result to the user through a UI view module.

7. The cross-platform scanner application implementation method of claim 6, wherein, In step S1, the local server module of the service layer assigns a unique API interface path to each scanner operation instruction when encapsulating the HTTP API, and defines the request parameter format and response data format.

8. The cross-platform scanner application implementation method of claim 7, wherein, In step S5, when the service layer calls the scanner driver configuration window through the TWAIN development kit, the driver configuration window is directly displayed on the operating system desktop, and the user completes parameter setting in the configuration window and then performs scanning. The configuration information is stored in the scanner driver program itself, and does not need to be reset subsequently.

9. The cross-platform scanner application implementation method of claim 8, wherein, In step S6, after receiving the scanned image data, the business logic module of the application layer processes the image data by calling the built-in image processing algorithm if the user initiates an image editing request. After the processing is completed, a file saving option is provided, and after the user selects a saving format, the business logic module encodes the image data into a file of the corresponding format and stores it in the user-specified path.

Images