CN116360737A - Plug-in service framework for reconfigurable integrated terminal - Google Patents

Plug-in service framework for reconfigurable integrated terminal Download PDF

Info

Publication number
CN116360737A
CN116360737A CN202310301910.2A CN202310301910A CN116360737A CN 116360737 A CN116360737 A CN 116360737A CN 202310301910 A CN202310301910 A CN 202310301910A CN 116360737 A CN116360737 A CN 116360737A
Authority
CN
China
Prior art keywords
service
request
plug
layer
peripheral
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310301910.2A
Other languages
Chinese (zh)
Inventor
丁林军
张章
李新疆
李杭
阎克栋
台宪青
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Aerospace Information Research Institute
Original Assignee
Suzhou Aerospace Information Research Institute
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Suzhou Aerospace Information Research Institute filed Critical Suzhou Aerospace Information Research Institute
Priority to CN202310301910.2A priority Critical patent/CN116360737A/en
Publication of CN116360737A publication Critical patent/CN116360737A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The invention discloses a plug-in service framework for a reconfigurable integrated terminal, which comprises an application layer, a forwarding layer, a primary supporting layer and a plug-in service layer, wherein: the application layer is a front-end page of the H5 standard and is responsible for interaction with a user and display and update of an interface; the forwarding layer is mainly used for receiving and forwarding user requests and service responses; the native support layer mainly comprises two components, namely a rendering engine and an eTS engine; the service layer mainly comprises a plug-in service engine and various peripheral services. The plug-in service engine is constructed between the application program and the operating system, supports the HTML5 standard, can shield the difference of the bottom operating system, and provides the peripheral service which is stably available for the upper application.

Description

Plug-in service framework for reconfigurable integrated terminal
Technical Field
The invention relates to a hardware module driving technology of an OpenHarmony operating system, in particular to a plug-in service framework for a reconfigurable integrated terminal.
Background
The OpenHarmony operating system is an open-source project hatched and operated by an open atomic foundation (Openatom foundation), and aims to face the full-scene, full-connection and full-intelligent era, and based on an open-source mode, a framework and a platform of the intelligent terminal equipment operating system are built, so that the prosperous development of the everything interconnection industry is promoted. A plurality of peripheral devices are connected in a wired and wireless mode to form a super virtual terminal with a reconfigurable hardware module and a reconfigurable software function, and the super virtual terminal is called a reconfigurable comprehensive terminal for short. At present, peripheral components are various, standards are not uniform, and quick access of hardware components cannot be guaranteed. The lack of authentication means also further increases the security risk of the system when peripheral components are accessed. A plug-in service framework oriented to a reconfigurable integrated terminal is introduced, and flexible reconfiguration of hardware modules and software functions is realized.
Compared with front-end and back-end integrated template (template) type website programming, front-end and back-end separated development modes are the main trend. The current popular cross-platform application development frames mainly comprise lonic developed based on AngularJS, reactitive constructed based on JavaScript, native script based on JavaScript and the like, but the mainstream frames do not adapt an OpenHarmony operating system yet, and a plug-in service frame developed based on front-end and back-end separation cannot be constructed.
Disclosure of Invention
The invention aims to provide a plug-in service framework for a reconfigurable integrated terminal based on an OpenHarmony operating system.
The technical solution for realizing the purpose of the invention is as follows: the plug-in service framework comprises an application layer, a forwarding layer, a primary supporting layer and a plug-in service layer, wherein the plug-in service framework is used for supporting a hardware reconfigurable terminal to carry out peripheral access, and is used for realizing cross-layer (application layer to service layer) and cross-language (JavaScript to C++/eTS) calling through a packaged websocket interface, wherein the plug-in service framework comprises the following components:
the application layer is a front-end page of the H5 standard and is responsible for interaction with a user and display and update of an interface;
the forwarding layer is mainly used for receiving and forwarding user requests and service responses;
the native support layer mainly comprises a rendering engine and an eTS engine, and has UI component rendering and eTS interface access capability;
the service layer mainly comprises a plug-in service engine and various peripheral services, wherein the plug-in service engine is developed by using a C++ language and performs service access authentication through analyzing services of a service suffix; loading peripheral services through a dlopen function; receiving a request of a forwarding layer by setting up a communication server of a Websocket protocol, and distributing the request to an eTS engine of a requested peripheral service or a native supporting layer according to a request type; receiving a peripheral service request response or an eTS engine interface request response through a signal slot mechanism;
the peripheral service is developed by a back-end function expansion library which is independently developed by a user, is developed by using a C++ language, receives and processes a request distributed by the plug-in service engine through inheritance of an OnMessage function, and finally returns a result to the plug-in service engine in a signal slot mode.
Furthermore, in the application layer, using a WebStorm development tool, completing the construction of a graphic rendering page based on an HTML5 or front end frame VUE, and generating a file VUE or HTML; the page style is controlled through the CSS3, and particularly, an inline style sheet, an embedded style sheet or an externally connected style sheet can be used for producing CSS style files; the service logic is controlled by the JavaScript of the ES6 standard, the JavaScript API packaged by the plug-in service framework is used for initiating the corresponding peripheral service request, the service request comprises the corresponding request callback function, the peripheral access and the request response are received, and the js script file comprising the control logic is generated.
Further, the forwarding layer uses JavaScript language to build a communication client based on a Websocket protocol, monitors a service access request of a front-end page of the application layer, completes request analysis, stores a request callback function which passes analysis in a callback pool, and forwards the request to a plug-in service engine of the service layer; the communication client based on Websocket is also used for monitoring a service request result returned by the service layer plug-in engine and returning the service request result to the front-end user through a callback function stored in the callback pool.
Further, the service access request should include a request ID, a peripheral service name, a peripheral interface, a service flag bit, and an access parameter; the request ID is designed into a character string type, and the length is fixed to be 10 bytes; the peripheral service name is a character string type, the length is variable, and the maximum length is 256 bytes; the peripheral interface has an indefinite length, and the maximum length is 256 bytes; the service access mark is of the String type, the value "eTS" identifies the service access request as a primary interface request, and the value space identifies the service access as a bottom interface request; the access parameter is a JSON character string, and the maximum length is 65536 bytes;
the service access request analyzer analyzes the front-end page request according to the standard, if the request is analyzed without error, the request callback function is cached, and meanwhile, the request is forwarded to a plug-in service engine of a service layer through a Websocket communication client; and if the analysis is wrong, returning the corresponding error type to the front-end user through the callback function.
Further, the service response includes a response ID, a call status flag bit, a response maintenance flag bit, and a call result, where the response ID is designed as a character string type, and the length is fixed to 10 bytes; the calling state flag bit is of a Boolean type, the value true flag is successfully called, and the value false flag is failed to call; the response state flag bit is of a numerical value type, and a value 999999 represents service response of the current open source hong Monte system; the response keeps the flag bit to be of the Boolean type, the value true identifies the service response to be a long-term response, and the value false identifies the service response to be a one-time response; the calling result is a JSON character string, the maximum length is 65536 bytes, and the data transmitted back by the service is represented;
the service response analyzer analyzes the back-end response according to the standard, and if the response analysis is correct, the stored callback function is called, and the result is returned to the front-end user; and if the analysis is wrong, returning the corresponding error type to the front-end user through the callback function.
Further, in the native support layer, the rendering engine is a rendering process of an OpenHarmony native ArkUI framework, eTS language development is used, a front-end page of the application layer is rendered by using a Web component provided by the rendering engine, and a service port is transferred to the forwarding layer to start a Websocket client; the eTS engine is used for analyzing the original ArkUI framework, eTS files are developed by using eTS language, a bottom layer server is initialized by calling a plug-in service engine interface, the bound port number of the bottom layer server is obtained, the socket client of the eTS native plug-in is started by transmitting the port number to the eTS native plug-in, and meanwhile, the calling work of the native interface request is completed.
The development process of the plug-in service framework for the reconfigurable integrated terminal is characterized by comprising the following steps of:
step S10: constructing an OpenHarmony system application project by using open source hong Mongolian system development software DevEcostudio, wherein the project is used for compiling a device software installation package, the catalog structure of the project comprises a front-end page file, a peripheral service file, a frame file and a configuration file, the front-end page file stores H5 page source codes and resource files of users and compiled camera front-end operation logic files, the peripheral service file stores compiled driving service files of an external camera, the frame file stores SDK of a service frame, and the configuration file stores access files for peripheral services;
using a front-end frame VUE to develop a front-end page, completing page layout, page navigation, page operation and page data request, and completing the development of the page interacted by the application and the user, wherein the page data request is JavaScript development, and the development is completed by compiling a logic file according to plug-in development requirements by using a fixed interface, and copying the logic file into an S10 project structure catalog;
step S20: under the project newly created in the step S10, an external camera service module is newly created, a processing interface of a Native operation code corresponding to the page data request in the step S10 is compiled, specific function codes related to the external camera are stored under a CPP catalog of the external camera service module, the result of the request is returned to the front end through a fixed interface interacted with a plug-in frame, and the camera module code is compiled by using IDE to generate an SO dynamic library file of the service, and is copied into the project structure catalog of the step S10;
step S30: copying the service library file generated in the external camera service module in the step S20 into the project structure catalog in the step S10, newly creating a configuration file to configure an accessed peripheral service path and service name, and analyzing and rendering a front-end page file by using the function of the frame; the project is packaged using DevEcoStudio software and installed on the equipment of the OpenHarmony system to complete the project.
Compared with the prior art, the invention has the following beneficial effects: (1) The cross-language call is realized, the C++ plugin service or the eTS native interface can be accessed through the front-end JavaScript interface, and the running efficiency of the application program is improved. (2) A plug-in service engine is constructed between the application program and the operating system, the HTML5 standard is supported, the difference of the bottom operating system can be shielded, and the plug-in service engine is provided for the upper application to stably and available peripheral services. (3) In the framework of the invention, a developer can be used for simultaneously adapting to a plurality of mobile terminal operating systems such as Android, syberOS and the like by only focusing on the realization of codes of application programs without considering the variability of the underlying operating systems. (4) Plug-in service is adopted, plug-in and play of various peripheral devices can be realized, and the peripheral device quick access capability is achieved.
Drawings
Fig. 1 is a diagram of a plug-in service framework.
Fig. 2 is a diagram of an example of code implemented by a client portion.
Fig. 3 is an exemplary diagram of a service access request.
Fig. 4 is a service response example diagram.
FIG. 5 is an exemplary diagram of rendering engine Web component code.
Fig. 6 is a diagram of a socket client portion code example.
Fig. 7 is a diagram of an example of a service side portion implementation code.
Fig. 8 is a diagram showing an example of a peripheral service section code.
Fig. 9 is a flowchart of the development of a peripheral service plug-in.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The plug-in service framework for the reconfigurable integrated terminal supports front-end and back-end separation development and cross-language call, supports standard HTML5 development, can realize quick access of a hardware module and dynamic loading of corresponding software functions, reduces the platform application transplanting cost, and improves the flexibility and cross-platform property of the application. As shown in fig. 1, the architecture of the plug-in service framework is a four-layer architecture system: the system comprises an application layer, a forwarding layer, a primary supporting layer and a plug-in service layer. Wherein:
(1) Application layer
The application layer is mainly a front-end page of the H5 standard developed by a user and is responsible for interaction with the user and display and update of an interface.
The user uses a WebStorm development tool under the JetBrains flag to complete the construction of a graphic rendering page based on HTML5 or front end frame VUE, and generates a file VUE or HTML; the page style is controlled through the CSS3, and particularly, an inline style sheet, an embedded style sheet or an externally connected style sheet can be used for producing CSS style files; the service logic is controlled by the JavaScript of the ES6 standard, where the JavaScript api encapsulated by the plug-in service framework may be used to initiate a corresponding peripheral service request, to implement peripheral access, and generate a. Js script file containing the control logic.
(2) Forwarding layer
The forwarding layer is mainly used for receiving and forwarding user requests and service responses.
The forwarding layer uses JavaScript language, as shown in fig. 2, builds a communication client based on Websocket protocol, monitors a service access request of a front-end page of the application layer, completes request analysis and caching, and forwards the request to a plug-in service engine of the service layer; the communication client based on Websocket is also used for monitoring a service request result returned by the service layer plug-in engine and returning the service request result to the front-end user through a callback function.
As shown in fig. 3, a service access request conforming to the plug-in service framework standard should include fields such as a request ID, a peripheral service name, a peripheral interface, a service flag, and an access parameter. The request ID is designed into a character string type, and the length is fixed to be 10 bytes; the peripheral service name is a character string type, the length is variable, and the maximum length is 256 bytes; the peripheral interface has an indefinite length, and the maximum length is 256 bytes; the service access mark is of the String type, the value "eTS" identifies the service access request as a primary interface request, and the value space identifies the service access as a bottom interface request; the access parameter is JSON string, and the maximum length is 65536 bytes. The request parser parses the front-end page request according to the above criteria, if the request is parsed correctly, the request callback function is cached, and meanwhile, the request is forwarded to the plug-in service engine of the service layer through the Websocket communication client; and if the analysis is wrong, returning the corresponding error type to the front-end user through the callback function.
As shown in FIG. 4, the service response of a service plug-in service framework standard should include fields such as a response ID, a call status flag, a response hold flag, and a call result. The response ID is designed into a character string type, and the length is fixed to 10 bytes; the calling state flag bit is of a Boolean type, the value true flag is successfully called, and the value false flag is failed to call; the response state flag bit is of a numerical value type, and a value 999999 represents service response of the current open source hong Monte system; the response keeps the flag bit to be of the Boolean type, the value true identifies the service response to be a long-term response, and the value false identifies the service response to be a one-time response; the call result is a JSON string, with a maximum length of 65536 bytes, representing the data returned by the service. The response analyzer analyzes the back-end response according to the standard, and if the response analysis is correct, the stored callback function is called, and the result is returned to the front-end user; and if the analysis is wrong, returning the corresponding error type to the front-end user through the callback function.
(3) Native support layer
The native support layer mainly includes two components, a rendering engine and an eTS engine, respectively.
As shown in fig. 5, the rendering engine is a rendering process of the OpenHarmony native ArkUI framework, developed using the eTS language, renders the front-end page of the application layer by using the Web component it provides, and passes the service port to the forwarding layer to launch the Websocket client.
The eTS engine is used for analyzing the original ArkUI framework, eTS files are developed by using eTS language, and the bottom server is initialized by calling the plug-in service engine interface and the bound port number is obtained; as shown in fig. 6, the socket client is started by passing the port number to the eTS native plug-in while the native interface request call work is completed.
(4) Service layer
The service layer mainly comprises a plug-in service engine and various peripheral services.
As shown in fig. 7, the plug-in service engine uses c++ language for development, and loads peripheral services through dlopen and other functions; receiving a request sent from a Websocket client through a communication server constructing a Websocket protocol, distributing the request to a requested peripheral service, and receiving a result sent from a native socet client; and receiving a result returned by the peripheral service through a signal slot mechanism and forwarding the result to the Websocket client.
The peripheral service is a back-end function expansion library which is developed by a user independently based on a certain development specification. As shown in fig. 8, the peripheral service is developed using the c++ language, receives and processes the request distributed by the plug-in service engine through the inheritance OnMessage function, and finally returns the result to the plug-in service engine through a signal slot.
As shown in fig. 9, a process for developing a service framework based on the plug-in, specifically includes the following steps:
step S10: the open source hong Mongolian system development software DevEcostudio is used for constructing an OpenHarmony system application project, the project is used for compiling a device software installation package, a catalog structure of the project comprises a front-end page file, a peripheral service file, a frame file and a configuration file, the front-end page file stores H5 page source codes of users, resource files, compiled camera front-end operation logic files and the like, the peripheral service file stores compiled driving service files of an external camera, the frame file stores SDK of a service frame, and the configuration file stores files for accessing peripheral services and the like. The main stream front end framework VUE is used to develop front end pages to complete page layout, page navigation, page operation, page data request, etc. The main task of the step is to complete the development of the page interacted by the application and the user, wherein the page data request is JavaScript development, the page data request is required to be written by using a fixed interface according to the plug-in development requirement, other aspects are not different from the common front-end development, and after the development is completed, logic files such as the page data request are compiled and copied into the S10 project structure catalog.
Step S20: under the newly built project in the step S10, a module of the external camera service is newly built, a processing interface of a Native operation code corresponding to the page data request in the step S10 is compiled, specific function codes related to the external camera such as a photographing function, a focusing function and the like are stored under a CPP catalog of the module, and a requested result is returned to the front end through a fixed interface interacted with the plug-in frame. And compiling the camera module code by using IDE to generate SO dynamic library files of the service. And copies it to the project structure directory of S10.
Step S30: copying the service library file generated in the step S20 module into the project structure catalog of the step S10, newly creating a configuration file to configure an accessed peripheral service path and service name, and analyzing and rendering a front-end page file by using the function of the framework. The project is packaged using DevEcoStudio software and installed on the equipment of the OpenHarmony system to complete the project.
The above examples are provided for illustrating the technical concept and features of the present invention and are intended to enable those skilled in the art to understand the contents of the present invention and to implement the same, and are not intended to limit the scope of the present invention. All equivalent changes or modifications made according to the spirit of the present invention should be included in the scope of the present invention.

Claims (7)

1. The plug-in service framework is characterized by comprising an application layer, a forwarding layer, a primary supporting layer and a plug-in service layer, wherein the plug-in service framework is used for supporting a terminal with reconfigurable hardware to carry out peripheral access, and cross-layer and cross-language calling from the application layer to the service layer is realized through a packaged websocket interface, and the plug-in service framework comprises the following components:
the application layer is a front-end page of the H5 standard and is responsible for interaction with a user and display and update of an interface;
the forwarding layer is mainly used for receiving and forwarding user requests and service responses;
the native support layer mainly comprises a rendering engine and an eTS engine, and has UI component rendering and eTS interface access capability;
the service layer mainly comprises a plug-in service engine and various peripheral services, wherein,
the plug-in service engine uses C++ language to develop and analyzes the service of the service suffix to perform service access authentication; loading peripheral services through a dlopen function; receiving a request of a forwarding layer by setting up a communication server of a Websocket protocol, and distributing the request to an eTS engine of a requested peripheral service or a native supporting layer according to a request type; receiving a peripheral service request response or an eTS engine interface request response through a signal slot mechanism;
the peripheral service is developed by a back-end function expansion library which is independently developed by a user, is developed by using a C++ language, receives and processes a request distributed by the plug-in service engine through inheritance of an OnMessage function, and finally returns a result to the plug-in service engine in a signal slot mode.
2. The plug-in service framework for the reconfigurable integrated terminal according to claim 1, wherein in the application layer, using WebStorm development tools, the graphic rendering page building is completed based on HTML5 or front end framework VUE, and file VUE or HTML is generated; the page style is controlled through the CSS3, and particularly, an inline style sheet, an embedded style sheet or an externally connected style sheet can be used for producing CSS style files; the service logic is controlled by the JavaScript of the ES6 standard, the JavaScript API packaged by the plug-in service framework is used for initiating the corresponding peripheral service request, the peripheral service request comprises a request callback function, the peripheral access and the request response are received, and the js script file comprising the control logic is generated.
3. The plug-in service framework for the reconfigurable integrated terminal according to claim 1, wherein the forwarding layer uses JavaScript language to build a communication client based on Websocket protocol, monitors a service access request of a front-end page of an application layer, completes request analysis, stores a callback function of the request passing the analysis in a callback pool, and forwards the request to a plug-in service engine of the service layer; the communication client based on Websocket is also used for monitoring a service request result returned by the service layer plug-in engine and returning the service request result to the front-end user through a callback function stored in the callback pool.
4. A plug-in service framework for a reconfigurable integrated terminal according to claim 3, wherein the service access request should include a request ID, a peripheral service name, a peripheral interface, a service flag, and an access parameter; the request ID is designed into a character string type, and the length is fixed to be 10 bytes; the peripheral service name is a character string type, the length is variable, and the maximum length is 256 bytes; the peripheral interface has an indefinite length, and the maximum length is 256 bytes; the service access mark is of the String type, the value "eTS" identifies the service access request as a primary interface request, and the value space identifies the service access as a bottom interface request; the access parameter is a JSON character string, and the maximum length is 65536 bytes;
the service access request analyzer analyzes the front-end page request according to the standard, if the request is analyzed without error, the request callback function is cached, and meanwhile, the request is forwarded to a plug-in service engine of a service layer through a Websocket communication client; and if the analysis is wrong, returning the corresponding error type to the front-end user through the callback function.
5. The plug-in service framework for the reconfigurable integrated terminal according to claim 3, wherein the service response includes a response ID, a call status flag, a response hold flag, and a call result, the response ID is designed as a character string type, and the length is fixed to 10 bytes; the calling state flag bit is of a Boolean type, the value true flag is successfully called, and the value false flag is failed to call; the response state flag bit is of a numerical value type, and a value 999999 represents service response of the current open source hong Monte system; the response keeps the flag bit to be of the Boolean type, the value true identifies the service response to be a long-term response, and the value false identifies the service response to be a one-time response; the calling result is a JSON character string, the maximum length is 65536 bytes, and the data transmitted back by the service is represented;
the service response analyzer analyzes the back-end response according to the standard, and if the response analysis is correct, the stored callback function is called, and the result is returned to the front-end user; and if the analysis is wrong, returning the corresponding error type to the front-end user through the callback function.
6. The plug-in service framework for a reconfigurable integrated terminal according to claim 1, wherein in the native support layer, the rendering engine is a rendering process of an OpenHarmony native ArkUI framework, is developed using the etis language, renders a front-end page of the application layer by using a Web component provided by the etis language, and delivers a service port to the forwarding layer to start a Websocket client; the eTS engine is used for analyzing the original ArkUI framework, eTS files are developed by using eTS language, a bottom layer server is initialized by calling a plug-in service engine interface, the bound port number of the bottom layer server is obtained, the socket client of the eTS native plug-in is started by transmitting the port number to the eTS native plug-in, and meanwhile, the calling work of the native interface request is completed.
7. A development flow of a plug-in service framework for a reconfigurable integrated terminal according to any one of claims 1 to 6, comprising the steps of:
step S10: constructing an OpenHarmony system application project by using open source hong Mongolian system development software DevEcostudio, wherein the project is used for compiling a device software installation package, the catalog structure of the project comprises a front-end page file, a peripheral service file, a frame file and a configuration file, the front-end page file stores H5 page source codes and resource files of users and compiled camera front-end operation logic files, the peripheral service file stores compiled driving service files of an external camera, the frame file stores SDK of a service frame, and the configuration file stores access files for peripheral services;
using a front-end frame VUE to develop a front-end page, completing page layout, page navigation, page operation and page data request, and completing the development of the page interacted by the application and the user, wherein the page data request is JavaScript development, and the development is completed by compiling a logic file according to plug-in development requirements by using a fixed interface, and copying the logic file into an S10 project structure catalog;
step S20: under the project newly created in the step S10, an external camera service module is newly created, a processing interface of a Native operation code corresponding to the page data request in the step S10 is compiled, specific function codes related to the external camera are stored under a CPP catalog of the external camera service module, the result of the request is returned to the front end through a fixed interface interacted with a plug-in frame, and the camera module code is compiled by using IDE to generate an SO dynamic library file of the service, and is copied into the project structure catalog of the step S10;
step S30: copying the service library file generated in the external camera service module in the step S20 into the project structure catalog in the step S10, newly creating a configuration file to configure an accessed peripheral service path and service name, and analyzing and rendering a front-end page file by using the function of the frame; the project is packaged using DevEcoStudio software and installed on the equipment of the OpenHarmony system to complete the project.
CN202310301910.2A 2023-03-24 2023-03-24 Plug-in service framework for reconfigurable integrated terminal Pending CN116360737A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310301910.2A CN116360737A (en) 2023-03-24 2023-03-24 Plug-in service framework for reconfigurable integrated terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310301910.2A CN116360737A (en) 2023-03-24 2023-03-24 Plug-in service framework for reconfigurable integrated terminal

Publications (1)

Publication Number Publication Date
CN116360737A true CN116360737A (en) 2023-06-30

Family

ID=86935804

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310301910.2A Pending CN116360737A (en) 2023-03-24 2023-03-24 Plug-in service framework for reconfigurable integrated terminal

Country Status (1)

Country Link
CN (1) CN116360737A (en)

Similar Documents

Publication Publication Date Title
US11409949B2 (en) Mobile device resource provisioning system and method
CN109800173B (en) Program debugging method, device and storage medium
US8612947B2 (en) System and method for remotely compiling multi-platform native applications for mobile devices
CN112579097B (en) Software project construction method and device, storage medium and electronic equipment
CN111831538B (en) Debugging method, device and storage medium
JP2007524875A (en) System and method for network-based processing
CN111740948B (en) Data packet issuing method, dynamic updating method, device, equipment and medium
CN102323880A (en) Mobile phone application interface development method and terminal based on browser parsing mode
CN110895471A (en) Installation package generation method, device, medium and electronic equipment
CN111176629A (en) Application development method and device
CN112114890A (en) Method, device and equipment for processing small program and storage medium
CN111338623A (en) Method, device, medium and electronic equipment for developing user interface
CN107193565B (en) Method for developing native APP (application) across mobile terminals
CN112988175A (en) Cross-platform application installation package generation method, device, medium and electronic equipment
CN107239265B (en) Binding method and device of Java function and C function
CN112764836A (en) Method and device for running fast application and electronic equipment
CN116360737A (en) Plug-in service framework for reconfigurable integrated terminal
CN112988588B (en) Client software debugging method and device, storage medium and electronic equipment
CN110727423A (en) Method and system for developing mobile application program across platforms
CN111338961B (en) Application debugging method and device, electronic equipment and storage medium
US10244020B1 (en) System and method for auto-generating meta-proxies
CN112379885A (en) Applet compiling method, device and equipment and readable storage medium
KR101418390B1 (en) system for remotely debugging an application programming and controlling method therefor
CN113867728A (en) Fused interface response data applied to third-generation modern Web front end and development framework based on components
CN116225394A (en) Method, device, electronic equipment and storage medium for creating cloud development environment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination