Resource calling method, development system and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a resource calling method and device, a development system and device, electronic equipment and a storage medium. The method comprises the steps that a resource calling request is received; determining a resource scene according to the resource calling request; determining a resource calling function matched with the resource scene, and executing the resource calling function to call resources of the resource scene; the resource calling function is obtained by compiling according to a first source code, the first source code adopts a first programming language, and the resource calling function adopts a second programming language; the first source code is used for declaring one or more abstract resource objects contained in the resource scene, and each abstract resource object is used for describing a corresponding resource. By implementing the embodiment of the invention, the development difficulty of developers can be reduced, and the development efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a resource calling method, a development system, a device, an electronic device, and a storage medium. Background Art

[0002] An electronic device can provide various callable resources, which can include hardware resources such as sensors and cameras, and can also include software resources such as the memory, storage, and network of the electronic device. With the development of technologies such as the Internet of Things, cloud computing, big data, and artificial intelligence, the number and types of callable resources in an electronic device have also increased significantly. These callable resources can be developed and called using programming languages. Since traditional imperative programming languages require precisely specifying the details of each operation during resource calling to implement the required computing logic, when facing a large number of complex resources, it increases the development difficulty for developers and reduces the development efficiency. Summary of the Invention

[0003] Embodiments of this application disclose a resource calling method, a development system, a device, an electronic device, and a storage medium, which can reduce the development difficulty for developers and improve the development efficiency.

[0004] Embodiments of this application disclose a resource calling method, and the method includes:

[0005] Receiving a resource calling request;

[0006] Determining a resource scenario according to the resource calling request;

[0007] Determining a resource calling function that matches the resource scenario, and executing the resource calling function to call the resources of the resource scenario; the resource calling function is compiled from a first source code, the first source code uses a first programming language, and the resource calling function uses a second programming language; the first source code is used to declare one or more abstract resource objects included in the resource scenario, and each of the abstract resource objects is used to describe the corresponding resource.

[0008] Embodiments of this application disclose a development system for resource calling, and the development system includes an application layer, an interface layer, a framework layer, and a platform layer;

[0009] The application layer is used to provide a first programming language for application development;

[0010] The interface layer provides a resource description interface that can be called in the first programming language;

[0011] The framework layer is used to provide classes included in the first programming language;

[0012] The platform layer is used to compile and run the application code developed by the application layer.

[0013] An embodiment of the present application discloses a resource invocation device, which includes:

[0014] A receiving module, configured to receive a resource invocation request;

[0015] A determining module, configured to determine a resource scenario according to the resource invocation request;

[0016] An invocation module, configured to determine a resource invocation function matching the resource scenario, and execute the resource invocation function to invoke the resources of the resource scenario; the resource invocation function is compiled from a first source code, the first source code uses a first programming language, and the resource invocation function uses a second programming language; the first source code is used to declare one or more abstract resource objects included in the resource scenario, and each of the abstract resource objects is used to describe the corresponding resource.

[0017] An embodiment of the present application discloses an electronic device, including a memory and a processor. A computer program is stored in the memory. When the computer program is executed by the processor, the processor implements the method in any one of the embodiments disclosed in the embodiments of the present application.

[0018] An embodiment of the present application discloses a computer-readable storage medium, which stores a computer program. The computer program causes a computer to execute the method in any one of the embodiments disclosed in the embodiments of the present application.

[0019] Compared with the related art, an embodiment of the present application discloses a resource invocation method, a development system, a device, an electronic device, and a storage medium, which have the following beneficial effects:

[0020] Receive a resource call request, determine a resource scenario according to the resource call request, determine a resource call function that matches the resource scenario, and execute the resource call function to call the resources of the resource scenario; wherein, the resource call function is compiled from a first source code, the first source code uses a first programming language, the resource call function uses a second programming language, and the first source code is used to declare one or more abstract resource objects included in the resource scenario for describing the corresponding resources. In the embodiments of the present application, the corresponding resource scenario is automatically matched according to the received resource call request, and the resource call function that matches the resource scenario is executed, so as to call the resources of the resource scenario. In the embodiments of the present application, when developers need to perform resource-related development, they can write the first source code in the first programming language, use the first source code to declare one or more abstract resource objects included in the resource scenario for describing the corresponding resources, and perform resource abstraction and resource description on the resources of the resource scenario through the abstract resource objects, which enables developers to develop resources in a more concise and natural way, reduces the development difficulty of developers and improves the development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0022] Figure 1 is a schematic diagram of an application scenario of a resource call method in an embodiment;

[0023] Figure 2 is a schematic flowchart of a resource call method in an embodiment;

[0024] Figure 3A is a framework design diagram of a first programming language in an embodiment;

[0025] Figure 3B is a module schematic diagram of a first programming language in an embodiment;

[0026] Figure 3C is a schematic structural diagram of a development system for resource call in an embodiment;

[0027] Figure 4 is a schematic diagram of a cross-device interaction scenario in an embodiment;

[0028] Figure 5 is a schematic flowchart of a resource call method in another embodiment;

[0029] Figure 6It is a schematic flowchart of exception handling in an embodiment;

[0030] Figure 7 It is a schematic structural diagram of a resource calling device in an embodiment;

[0031] Figure 8 It is a schematic structural diagram of an electronic device in an embodiment. Detailed implementation manners

[0032] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0033] It should be noted that the terms "including" and "having" and any variations thereof in the embodiments of the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices.

[0034] It can be understood that the terms "first", "second", etc. used in the present application can be used herein to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from another element. For example, without departing from the scope of the present application, the first electronic device can be called the second electronic device, and similarly, the second electronic device can be called the first electronic device. Both the first electronic device and the second electronic device are electronic devices, but they are not the same electronic device. The term "plurality" used in the present application refers to two or more. The term "and / or" used in the present application refers to one of the solutions or any combination of multiple solutions.

[0035] In related technologies, with the development of technologies such as the Internet of Things, cloud computing, big data, and artificial intelligence, the interconnection of all things and the intelligence of all things have become the future development trend. In order to cater to the development trend of the interconnection of all things and the intelligence of all things, various physical devices, sensors, terminals, networks, platforms, etc. can be virtualized, managed, and programmed in a software-defined manner to achieve efficient utilization and flexible scheduling of resources. However, the surge in the number of programmable resources in the context of the Internet of Everything has brought challenges to traditional imperative programming. For example, the need for devices to constantly wait and respond to server commands and polling will increase network traffic and latency, reduce performance and scalability; and the need for devices to strictly follow the operations indicated by imperative programming will reduce flexibility and customizability. Therefore, on mobile devices, due to the complexity of resource management issues, traditional imperative development methods are difficult to cope with. The declarative development method can better cope with this resource management problem and manage and maintain resources on mobile devices through descriptive code.

[0036] Declarative programming is a more efficient and concise programming method in software development. At present, the declarative programming paradigm is mainly concentrated on the declarative user interface (UI) framework, and is less used in resource management. Most of them are concentrated in the fields of cloud computing and large cluster management systems. There is currently no general declarative development framework for mobile device resource management.

[0037] The declarative UI framework uses a declarative programming language to describe UI components, separating the structure and style of the UI from the business logic, making the code more concise and easy to understand. The declarative programming language adopted by the declarative UI framework can be a syntax extension of JavaScript, allowing code similar to Hypertext Markup Language (HTML) to be written in JavaScript to describe the structure and style of UI components. Alternatively, the declarative programming language adopted by the declarative UI framework can also be an extended template language based on HTML, which can describe the structure and style of UI components, but the syntax is limited and the dynamics are insufficient. The existing declarative UI framework only supports declarative description of UI components and layout, and does not support the management of programmable resources, which makes it difficult for developers to flexibly operate and manage resources during the development process, thereby affecting development efficiency and experience.

[0038] The current declarative resource management framework uses Structured Query Language (SQL) to declaratively specify the behavior of the cluster manager. This declarative resource management framework is often only targeted at a specific scenario, such as cluster management, and lacks versatility and wide applicability.

[0039] Embodiments of the present application disclose a resource calling method, a development system, a device, an electronic device, and a storage medium, which can reduce the development difficulty of developers and improve the development efficiency. The following will be described in detail respectively.

[0040] Please refer to Figure 1 , Figure 1 which is a schematic diagram of an application scenario of a resource calling method in an embodiment.

[0041] The compilation device 10 can be used to run a compiler, and the compiler can be used to convert the source code into code that the target device 20 can run, which means converting the source code into code that conforms to the operating environment and operating requirements of the target device 20.

[0042] The compilation device 10 may include, but is not limited to, electronic devices such as laptops, palmtop computers, netbooks, personal computers (PCs), and servers.

[0043] The target device 20 can be an electronic device actually used by the user. The target device 20 may include, but is not limited to, electronic devices such as mobile phones, tablets, laptops, palmtop computers, vehicle terminal devices, wearable devices, netbooks, or personal digital assistants (PDAs), personal computers (PCs), etc.

[0044] The compilation device 10 running the compiler is usually the electronic device used by developers to write, test, and compile code. After the developers complete the code development, they can deploy the code generated by the compiler to the target device 20, so that the target device 20 can execute the code generated by the compiler, so that the target device 20 can achieve resource calling.

[0045] The resource calling method of the embodiments of the present application can be applied to the target device 20.

[0046] In some embodiments, the compilation device 10 can compile the first source code in the first programming language into a resource calling function in the second programming language. The second programming language can be a programming language adapted to the operating environment and operating requirements of the target device 20, so that the target device 20 can execute the resource calling function in the second programming language.

[0047] The target device 20 can receive a resource call request, determine a resource scenario according to the resource call request, determine a resource call function that matches the resource scenario, and execute the resource call function to call the resources of the resource scenario. The resource call function is compiled from a first source code, the first source code uses a first programming language, and the resource call function uses a second programming language; the first source code is used to declare one or more abstract resource objects included in the resource scenario, and each abstract resource object is used to describe the corresponding resource.

[0048] Please refer further to Figure 2 , Figure 2 which is a schematic flow diagram of a resource call method in an embodiment; this resource call method can be applied to the above-mentioned electronic device. As Figure 2 shown, this resource call method may include the following steps:

[0049] 201. Receive a resource call request.

[0050] In some embodiments, the resource call request may be a request triggered by a user to call a resource.

[0051] Optionally, the resource call request may be generated when the user performs a touch operation such as clicking, double-clicking, or long-pressing on a virtual button in the user interface of the electronic device, or the resource call request may be generated when the user sends a voice control instruction to the electronic device, and the specific situation is not limited.

[0052] Exemplarily, the resource call request may be generated when the user performs a touch operation on a virtual button in the user interface of an application. For example, the electronic device may include a recording application, and the user interface of the recording application includes a virtual button for starting recording. When the user performs a touch operation on this virtual button, a resource call request will be generated.

[0053] In some embodiments, the resources may include resources such as the memory, storage, and network of the electronic device, and further may include application resources, where the application resources are the memory, storage, network, etc. resources used during the execution of the application program.

[0054] 202. Determine a resource scenario according to the resource call request.

[0055] In some embodiments, the resource scenario may refer to the application scenario of the resource. When the electronic device receives a resource call request, it can obtain device information related to the resource call request and determine the corresponding resource scenario according to the device information.

[0056] Optionally, the device information may include, but is not limited to, the power of the electronic device, the battery mode of the electronic device, the network connection status, sensor data, the currently running application, etc. The resource scenarios may include, but are not limited to, the energy-saving scenario, the call scenario, the networking scenario, the low-battery scenario, the gaming scenario, the photography scenario, etc.

[0057] Exemplarily, if the resource invocation request is generated when the user touches a virtual button for starting recording, the device information related to the resource invocation request may include the battery mode of the electronic device (such as the energy-saving mode, the normal mode, the performance mode, etc.), the currently running application of the electronic device (such as the call application, the social software application, etc.), and the network connection status of the electronic device (such as whether it is connected to a Wi-Fi network).

[0058] The electronic device may determine the corresponding resource scenario according to the device information. The resource scenarios may include, but are not limited to, the energy-saving scenario, the call scenario, the networking scenario, etc. For example, if the battery mode of the electronic device is the energy-saving mode, the determined resource scenario is the energy-saving scenario; if the currently running application of the electronic device is the call application, the determined resource scenario is the call scenario.

[0059] 203. Determine a resource invocation function that matches the resource scenario, and execute the resource invocation function to invoke the resources of the resource scenario.

[0060] Among them, the resource invocation function is compiled from the first source code. The first source code uses the first programming language, and the resource invocation function uses the second programming language. The first source code is used to declare one or more abstract resource objects included in the resource scenario, and each abstract resource object is used to describe the corresponding resource.

[0061] The resource invocation function is a function used to invoke the resources of the resource scenario, and the first source code is the source code used to compile the resource invocation function.

[0062] In some embodiments, the first programming language may be a declarative programming language and is a domain-specific language (DSL) for a specific task. The first programming language may be a DSL for resource management, that is, a declarative resource management DSL.

[0063] Resource management may refer to the management of resources such as the memory, storage, and network of the electronic device. Further, it may include application resource management, which may be the management of various resources used during the execution of an application, such as memory resources, storage resources, network resources, etc.

[0064] In some embodiments, the first programming language can provide rich resource description methods, such as tags, decorators, custom scenarios, abstract resource description mechanisms, etc. These resource description methods can also be combined with the resource management classes, event methods, property methods, etc. built into the application development framework to jointly form the basis of resource operations.

[0065] Since the core features of declarative programming languages include declarative description and declarative abstraction, declarative programming languages express the goals or expected results of a program through declarative description and hide the specific implementation details of the problem through declarative abstraction. As a declarative programming language for device resource operations, the first programming language provides developers with a concise, efficient, and modular device resource programming method through resource description and resource abstraction, making the program easier to understand, maintain, and extend.

[0066] In some embodiments, the first programming language can implement resource management through scenario description functions and describe resources through abstract resource objects.

[0067] In some embodiments, the first programming language can decorate functions and variables through decorators. The decorator can endow the decorated object with the ability of resource management and resource description. For example, a scenario description function can be decorated by a scenario decorator, and an abstract resource object can be decorated by a resource decorator. Therefore, the scenario description function included in the first programming language can be a function decorated by a scenario decorator, and the scenario decorator can endow this scenario description function with the ability to manage resources. In the scenario description function, there can also be an abstract resource object decorated by a resource decorator, and the resource decorator can endow the abstract resource object with the ability to describe resources, thus realizing the management of resources.

[0068] The first programming language describes resources through abstract resource objects. The abstract resource object can include the static attributes of the resource and the action attributes of the resource. The static attributes are used to describe the device attributes of the resource, such as the device type, the component types in the device, etc. Among them, the device type can include mobile phones, tablet computers, or wearable devices, etc.; the component types in the device can include camera components, microphone components, positioning components, storage components, etc. in the device; the action attributes are used to describe the behavior of the resource, such as opening, closing, etc. Specifically, the action attributes can include actions such as the startup, operation, and shutdown of the device, or the startup, operation, and shutdown of the components in the device.

[0069] The first programming language can comprehensively describe resources through scenario description functions and abstract resource objects, covering the characteristics, behaviors of resources, and how to use these resources in different scenarios, enabling developers to more easily manage and manipulate resources, thereby improving development efficiency. In summary, as a declarative device resource operation language, the first programming language can bring many beneficial effects to developers, from improving development efficiency to optimizing application performance, and this programming language will help change the way of device resource management, providing more convenient and efficient solutions for a wide range of scenarios and fields. The first programming language provides resource abstraction and resource description for device resource management, enabling developers to more effectively manage resources such as memory, storage, and network on mobile devices, optimize application performance, and improve the user experience; at the same time, the first programming language allows developers to describe resource operations and management through concise syntax, which can reduce the cognitive burden of developers and improve coding speed and efficiency.

[0070] Therefore, by declaring one or more abstract resource objects included in the resource scenario in the source code of the first programming language, the resources in the resource scenario can be abstracted and described.

[0071] The design of a general declarative programming language for device resource operations can provide developers with a unified, concise, and efficient resource management method, thereby improving development efficiency and being applied in a wider range of scenarios and fields.

[0072] In some embodiments, the first programming language includes a domain-specific language DSL extended from the TypeScript language.

[0073] As a DSL for application resource management, the first programming language is extended from the TypeScript language, is a superset of the TypeScript language, inherits all the features of the TypeScript language, and extends the ability of declarative resource management on the basis of the TypeScript language, enabling developers to develop application resources of electronic devices in a more concise and efficient manner.

[0074] Optionally, the first programming language can be called a Resource-awareness Script (RaScript).

[0075] In summary, the first programming language is a superset of the TypeScript language, allowing developers to utilize all the functions of the TypeScript language, while providing dedicated functions for device resource management, making the first programming language highly scalable and flexible, and capable of adapting to different application scenarios and requirements.

[0076] In addition, since the TypeScript language is a strongly typed language, strongly typed languages usually provide more type safety because the compiler catches type - mismatch errors. As a superset of the TypeScript language, the first programming language can catch type - mismatch errors during compilation, thus reducing runtime errors in resource management operations. The first programming language provides abstract tools specifically for device resource management, enabling developers to more effectively manage resources such as memory, storage, and network on mobile devices, optimizing application performance and enhancing the user experience. Moreover, the first programming language allows developers to describe resource operations and resource management through concise syntax, which can reduce the cognitive burden on developers, improve coding speed and efficiency, and thus achieve more efficient electronic device resource management; the first programming language has high scalability and flexibility. As a superset of the TypeScript language, the first programming language allows developers to utilize all the functions of the TypeScript language while providing dedicated functions for device resource management, thus adapting to different application scenarios and requirements.

[0077] In some embodiments, the second programming language may include multiple programming languages adapted to the operating environment of the target device. Therefore, according to the operating requirements of the target device, the first programming language can be compiled into any programming language that matches the operating requirements of the target device, capable of adapting to different code - running requirements and improving the applicability of the first programming language.

[0078] In some embodiments, the second programming language includes the JavaScript language or the TypeScript language.

[0079] The TypeScript language or the JavaScript language can adapt to the operating environment of the target device. The TypeScript language is a superset of the JavaScript language. When an application runs on the target device, it can execute the target code using the TypeScript language or the JavaScript language. The TypeScript language or the JavaScript language has cross - platform characteristics and can run on various operating systems and devices. Therefore, since the first compiled language can be a declarative extension language based on the TypeScript language, converting the first source code in the first programming language into the general TypeScript language or the JavaScript language can adapt to multiple operating systems and devices.

[0080] The first source code can be the source code used to compile the resource calling function. The source code is the code used to develop the application. Developers develop application programs by writing the source code, and the source code can describe the logic and behavior of the application program. The resource calling function obtained by compiling the first source code and using the second programming language can be deployed to the target device, such as the electronic device actually used by the user.

[0081] The second programming language is a programming language that can adapt to the operating environment of the electronic device actually used by the user. Therefore, the resource calling function can be executed by this electronic device to achieve the calling of resources.

[0082] In the embodiments of the present application, the first programming language combines the advantages of TypeScript with declarative device resource operations, providing a concise, natural, and efficient programming method for device resource management. Through a rich resource description mechanism, powerful data processing capabilities, and flexible dynamic scenario construction, the first programming language becomes a practical programming language for device resource operations. The first programming language is extended from the TypeScript language and has the following advantages: (1) Integrating the advantages of TypeScript: As a superset of TypeScript, the first programming language inherits all its features, such as type safety, object-oriented programming, modularity, etc. This enables the first programming language to fully utilize the advantages of TypeScript and provide a dedicated solution for device resource operations. (2) Extension of declarative resource operations: The first programming language introduces declarative resource operation capabilities on the basis of TypeScript, allowing developers to handle device resources in a more concise and natural way. This includes features such as resource description, data processing, and dynamic scenario construction. (3) Unified device operation interface and state management: The first programming language provides resource abstraction, which helps simplify the development process and improve the flexibility of resource operations. Resource abstraction can mask the differences between different platforms and devices, provide a unified device operation interface for upper-layer applications, and at the same time support middleware for resource state management and provide adaptive solutions. (4) Rich resource description mechanism: The first programming language provides various resource description methods, such as tags, decorators, custom scenarios, and abstract resource descriptions. These mechanisms, combined with the built-in resource management classes, event methods, property methods, etc. in the device resource operation framework, jointly constitute the basis of resource operations. (5) Powerful data processing capabilities: The first programming language supports multi-dimensional data processing, including associated data transfer between resources, ordered asynchronous transfer implemented by blocking queues, and message distribution mechanisms. These functions provide developers with flexible data linkage capabilities, facilitating the implementation of various complex device resource operations. (6) Flexible dynamic scenario construction: The first programming language allows developers to dynamically construct resource usage scenarios, including the types of abstract resources inside custom scenarios and the static attributes of reusable abstract resource components. This ability improves the flexibility and scalability of device resource operations and meets the requirements of various different application scenarios.

[0083] Please refer further to Figure 3A , Figure 3A which is a framework design diagram of the first programming language in an embodiment.

[0084] The framework design of the first programming language may include a language layer, a parsing layer, and a runtime layer. The language layer may compile the first source code in the first compiled language into code in the second compiled language. The compiled code may include resource call functions in the second programming language. The parsing layer may automatically match the corresponding resource scenario according to the device information provided by the runtime layer, and determine the matching resource call function according to the resource scenario. The runtime layer may obtain the device information and provide the device information to the parsing layer. In addition, the runtime layer may also execute the resource call function determined by the parsing layer to call the resources in the resource scenario.

[0085] Runtime refers to the state when the code is executing, and it can also refer to the state when the application is actually running. Optionally, the runtime may include the runtime environment required for the application to execute. For example, the JavaScript runtime (JSRuntime), that is, the runtime environment based on the JavaScript language, or the Android runtime (ART Runtime), etc.

[0086] In some embodiments, the user may trigger the corresponding function through the virtual button in the user interface of the electronic device. For example, the user interface of the camera application includes a virtual button for turning on the camera. When the user performs a touch operation on the virtual button, a resource call request will be generated. When receiving the resource call request, it may be determined that the application is in progress, and the relevant device information may be obtained, and the corresponding resource scenario may be determined according to the device information. After determining the resource scenario, the resource call function matching the resource scenario may be determined, and the resource call function may be executed to call the resources in the resource scenario, so as to implement the corresponding application function. Since the resource call function is compiled from the first source code, and the first source code includes one or more abstract resource objects describing the corresponding resources included in the resource scenario, the resources in the resource scenario are abstracted and described through the abstract resource objects, and then the specific resources in the resource scenario are called, which enables developers to develop resources in a more concise and natural way, reduces the development difficulty of developers and improves the development efficiency.

[0087] Please refer to Figure 3B , Figure 3B which is a schematic diagram of the modules of the first programming language in an embodiment.

[0088] The first source code in the first programming language is used to declare one or more abstract resource objects included in the resource scenario. Each abstract resource object is used to describe the corresponding resource, and each abstract resource object may include the static attributes of the resource and the action attributes of the resource. Therefore, the first source code in the first programming language can configure the resource scenario, and by configuring the static attributes and action attributes of the abstract resource objects, the resources in the resource scenario can be configured.

[0089] After completing the scenario configuration and resource configuration, the first source code in the first programming language can be compiled by a compiler. Since the first programming language can decorate functions and variables through decorators, the scenario description functions and abstract resource objects decorated by the decorators in the first source code can be recognized, so as to perform instrumentation operations such as modifying and replacing the scenario description functions and abstract resource objects, and generate resource call functions in the second programming language according to the code after the instrumentation operation.

[0090] During the scenario matching process, when a resource call request is received, the resource scenario can be determined according to the resource call request, and according to the scenario function correspondence table, the resource call function matching the resource scenario can be determined, and the resource call function can be executed to call the resources of the resource scenario. The scenario function correspondence table stores the correspondence between the resource scenario and the resource call function.

[0091] Please refer further to Figure 3C , Figure 3C which is a schematic structural diagram of a development system for resource call in an embodiment, and the operating framework of the first programming language can be as shown in this development system. As Figure 3C shown, the development system includes an application layer, an interface layer, a framework layer, and a platform layer; the application layer is used to provide the first programming language for application development; the interface layer provides resource description interfaces that can be called in the first programming language; the framework layer is used to provide classes included in the first programming language; the platform layer is used to compile and run the application code developed by the application layer.

[0092] The application layer can provide the first programming language for developers to carry out application development, and can adapt to different types of devices, such as mobile phones, tablet computers, and wearable devices, etc.

[0093] The interface layer can provide developers with callable resource description interfaces. Optionally, the resource description interfaces can include but are not limited to static attribute interfaces, action attribute interfaces, data type interfaces, etc. Among them, the static attribute interface is an interface that provides the static attributes of resources, the action attribute interface is an interface that provides the action attributes of resources, and the data type interface is an interface that provides the data types describing resources. The data types can include functions, variables, etc. Among them, the static attributes are used to describe the attributes of resources, such as device types, component types in devices, etc., and the action attributes are used to describe the behaviors of resources, such as opening, closing, etc.

[0094] The framework layer can provide core modules and basic modules for the declarative resource programming framework, including various classes contained in the first programming language such as various resource management classes, exception handling classes, etc. The core modules can include, but are not limited to, resource management classes such as camera resource management class (RCameraManager), storage resource management class (RStoreManager), speaker resource management class (RSpeakerManager), playback resource management class (RDisplayManager), microphone resource management class (RMicManager), memory resource management class (RMemManager), sensor resource management class (RSensorManager), processor resource management class (RCPUManager), etc. The basic modules can include, but are not limited to, device status classes, exception handling classes, etc. Therefore, the framework layer provides rich resource management functions through multiple resource management classes, simplifies the processing of common tasks, improves development efficiency, and splits the code into modular multiple resource management classes, which can improve the reusability and maintainability of the code. Also, through providing support for framework layer modules and interfaces, the first programming language can ensure that the code written in the first programming language can run properly.

[0095] The platform layer can provide an operating system, a runtime, and a compiler. The compiler can perform translation and instrumentation operations, and can provide a compilation environment for the application code developed in the application layer during compilation, and a runtime environment for the compiled application code during runtime.

[0096] In the embodiments of the present application, according to the received resource call request, the corresponding resource scenario is automatically matched, and the resource call function matching the resource scenario is executed, so as to call the resources of the resource scenario. In the embodiments of the present application, when developers need to conduct resource-related development, they can write the first source code in the first programming language, use the first source code to declare one or more abstract resource objects that describe the corresponding resources included in the resource scenario, and perform resource abstraction and resource description on the resources of the resource scenario through the abstract resource objects, enabling developers to develop resources in a more concise and natural way, reducing the development difficulty of developers and improving development efficiency.

[0097] In some embodiments, the first source code includes a scenario description function corresponding to the resource scenario; the scenario description function contains one or more abstract resource objects corresponding to the resource scenario; the abstract resource objects include attribute variables and / or action variables, and the attribute variables are used to describe the static attributes of the corresponding resources, and the action variables are used to describe the action attributes of the corresponding resources.

[0098] The scene description function can be a function capable of managing resources in a resource scene. For example, the scene description function can include functions such as startRecording() for starting recording and takePhoto() for taking photos.

[0099] The scene description function contains one or more abstract resource objects corresponding to the resource scene. Resource management can be achieved through the scene description function, and resources can be described through the abstract resource objects.

[0100] The abstract resource object can be defined through attribute variables and action variables, and can be used to describe the static attributes and action attributes of resources. Optionally, the static attributes and action attributes of the abstract resource object can be configured in the form of chained calls.

[0101] The static attributes are used to describe the attributes of resources, such as device type, component type in the device, etc. For example, the device type can include mobile phones, tablets, or wearable devices, etc.; the component type in the device can include camera components, microphone components, positioning components, storage components, etc.

[0102] In some embodiments, the configuration of the static attributes can be <resconfig>It can be defined within the tag. You can directly define the attributes or use the chained call form for setting. For the configuration name prefixes of different abstract resource objects and the types of static attributes within the configuration block, you can refer to the static attribute configuration document. After configuring the static attributes, you can use the @resconfig.XX method to reference the configuration of the static attributes.

[0103] The action attribute is used to describe the actions of the resource, such as opening and closing. For example, the actions of the resource can include actions like turning on, running, and turning off the device, or actions like turning on, running, and turning off the components within the device. The configuration of the action attribute can be directly defined or set using the chained call form. To configure the action attribute, you can refer to the corresponding abstract resource management class document.

[0104] For example, assume the resource scenario is the camera scenario. Then the resources used in this resource scenario refer to the resources used to perform the camera operation through the camera application. Therefore, the static attributes of the resource can refer to which cameras in which electronic devices are controlled, and which cameras in the electronic devices are controlled for taking pictures; the action attributes of the resource can refer to actions such as controlling the camera to start taking pictures and stop taking pictures.

[0105] Through these resource description methods, the source code in the first programming language can comprehensively describe the resources, covering the characteristics, behaviors of the resources, and how to use these resources in different scenarios, enabling developers to more easily manage and manipulate the resources, thereby improving the development efficiency.

[0106] In some embodiments, the scenario description function is decorated by a scenario decorator, and the scenario decorator is used to mark the resource scenario corresponding to the scenario description function. Optionally, the scenario decorator can be represented as the @Scenarios decorator. After @Scenarios, parameters can be input to specify the resource scenario, such as call: call scenario; EnerySaving: energy-saving scenario.

[0107] In some embodiments, the abstract resource object is decorated by a resource decorator, and the resource decorator is used to mark the resource description of the abstract resource object; the attribute variable is decorated by an attribute decorator, and the attribute decorator is used to mark the static attribute of the abstract resource object to which the attribute variable belongs.

[0108] Among them, the decorator can endow the decorated object with the ability of resource management and resource description. The decorator can not only decorate functions but also decorate variables.

[0109] A scenario description function is a function decorated by a scenario decorator. After being decorated by the scenario decorator, the scenario description function has the ability to manage resources and is assigned a corresponding resource scenario, enabling the scenario description function to manage resources in a specific resource scenario. The scenario description function may include various abstract resource objects for describing resources. During the compilation of the source code in the first programming language, the abstract resource objects in the resource scenario can be constructed and invoked according to the scenario decorator.

[0110] The scenario description function contains one or more abstract resource objects, which can be decorated by a resource decorator. Optionally, the resource decorator can be represented as @Device. After being decorated by the scenario decorator, the abstract resource object has the ability to describe resources.

[0111] The attribute variables contained in the abstract resource object can be decorated by an attribute decorator. Optionally, the attribute decorator can be @res. After being decorated by the attribute decorator, it has the ability to describe the static attributes of the resources.

[0112] The following uses Code One to illustrate the first source code in the first programming language. Code One can be used as a development example in the first programming language.

[0113] Code One:

[0114]

[0115]

[0116] It can be seen that the scenario description function is startRecording(). The scenario configuration is implemented through the startRecording() function decorated by the scenario decorator @Scenarios. After being decorated by @Scenarios, startRecording() has the ability to manage resources. The parameters of @Scenarios are optional and are used to specify the resource scenario, such as Call (call scenario), EnergySaving (energy-saving scenario). During the compilation of the first source code by the compiler, the resource scenario of the current resource description function will be extracted according to @Scenarios, and at the same time, the abstract resource objects in the resource scenario will be constructed and invoked. According to the first source code, a resource call function can be compiled, and when the electronic device is actually running, the corresponding resource call function can be adaptively matched according to the current resource scenario. Among them, Mic and Location can be abstract resource objects in the scenario description function. The operate(["stop","get_lastdata"]) in the abstract resource object Mic can be an action variable, and stop is the action attribute described by the action variable.

[0117] As can be seen from the above Code 1, if the scenario decorator @Scenarios is in a parameterless form, it indicates that it is in a normal scenario. When starting recording, both recording and positioning can be performed simultaneously; if the parameter of the scenario decorator @Scenarios is an energy-saving scenario and a call scenario, when starting recording, only recording is performed without positioning. Therefore, in the actual process of users using electronic devices, when users perform a touch operation or a voice operation to start recording, a resource call request will be generated, and the electronic device will determine the current resource scenario according to the resource call request, and then match the corresponding resource call function according to the resource scenario. Since the resource call function is compiled from the scenario description function, when the resource call function is executed, the management and description method of resources in the scenario description function can be followed, so that the resources in the specific resource scenario can be called, enabling developers to develop resources in a more concise and natural way, reducing the development difficulty of developers and improving the development efficiency.

[0118] Moreover, the source code in the first programming language can omit repetitive code, such as omitting repetitive code like getInstance(), attr(), new, build(), sceAttr(), etc., which can reduce the workload of writing repetitive code and make the programming style more concise. In addition, by implementing device resource management through the source code in the first programming language, dynamic judgment of resource scenarios can be achieved, and corresponding resource call functions can be automatically generated, avoiding a large amount of logical code writing such as if_else at the programming level and representing the same semantics with more concise syntax.

[0119] In some embodiments, the source code in the first programming language can achieve continuous and orderly transmission of streaming data through a blocking queue, and achieve global transmission of single data through a message subscription and distribution mechanism. For other data management, such as resource data and user interface (UI), and global data management of applications, the data management capabilities provided by the UI framework can be reused, such as continuous and orderly transmission, blocking queue, incoming data type, enqueueing and dequeueing operations, or single-message subscription and distribution, registering listeners, sending messages, and performing global message distribution operations.

[0120] In some embodiments, the resource call method is applied to a first electronic device; in the case where the resource scenario is a cross-device interaction scenario, the static attribute includes the status identifier of the first electronic device, and the action attribute includes data transmission operations and / or device control operations performed on the second electronic device.

[0121] The cross-device interaction scenario may include a resource interconnection scenario across multiple electronic devices. Optionally, it may be multi-device interaction relying on an application, such as cross-device transfer in Harmony OS or cross-device interaction in Android.

[0122] Among them, the status identifier can be used to identify the status of the first electronic device. In some embodiments, the control status of the first electronic device may include, but is not limited to, local control status, automatic status, remote control status, etc.; or, the working status of the first electronic device may include, but is not limited to, normal status and fault status, etc.; or, the type of data transmission may include, but is not limited to, transmission of device data, transmission of device control instructions.

[0123] In some embodiments, the data transmission operation may include, but is not limited to, sending data operation, receiving data operation, etc.; the device control operation may include an operation to control a remote device to perform a specified function. Taking the resource scenario as the camera resource interaction scenario as an example, the action attributes may include an operation for the first electronic device to send image data to the second electronic device, an operation to receive image data acquired by the second electronic device, an operation to control the camera of the second electronic device (remote device) to take an image, and an operation to control the camera of the first electronic device (local device) to take an image.

[0124] The following Figure 4 illustrates the cross-device interaction scenario. Figure 4 is a schematic diagram of the cross-device interaction scenario in an embodiment.

[0125] The first electronic device and the second electronic device have the same application program. Taking the use of the camera as an example, when calling the camera resources, the camera status attribute (camType) in the static attributes can be set. The camera status attribute can include the status identifier of the first electronic device. The status identifier can include the local identifier (local), the automatic identifier (auto), and the remote identifier (remote), which are used to identify the local control status, the automatic status, and the remote control status respectively. The local control status can include controlling the local camera to take pictures, and the remote control status can include controlling the remote camera to take pictures. The automatic status is the automatic status that switches between the local control status and the remote control status. Optionally, the static attributes can also include the control type attribute (remoteKind). The control type attribute can include the control type identifier. The control type identifier can include the control identifier (control) and the non-control identifier (not-control). The control identifier (control) is used to describe that the first electronic device can directly send a control instruction to the second electronic device, so that the second electronic device (remote device) automatically executes the operation indicated by the control instruction and returns the data. For example, the second electronic device executes the photographing operation and returns the captured image data to the first electronic device.

[0126] Among them, the first electronic device can be regarded as the master device (Master), and the second electronic device can be regarded as the slave device (Slave). The master device can send a control instruction to the slave device and control the slave device to complete the task indicated by the control instruction. The slave device receives the control instruction of the master device and completes the corresponding task.

[0127] As Figure 4 shown, when the first electronic device calls the camera resources, the process is as follows:

[0128] 1. First, determine whether the local camera is available;

[0129] 2. If it is available and the camType is local or auto, directly use the local camera to take pictures;

[0130] 3. If the camType is remote, it means that the first electronic device needs to call the remote camera. Therefore, the first electronic device needs to call the camera resources of the second electronic device. When the remoteKind is control, it means directly sending an instruction to make the remote camera (the camera of the second electronic device) automatically execute the photographing operation and then return the image data; otherwise, it is necessary to manually control the remote device (the second electronic device) and then return the data. If the local camera is not available, when the camType is auto or remote, it means calling the remote device (the second electronic device) and executing the above step 3 process; otherwise, directly prompt that the camera is not available.

[0131] In some embodiments, a user may trigger cross-device interaction through an application and generate a resource call request. For example, the user may perform a touch operation on a virtual button in the application user interface for establishing a connection with a remote device, or the user may issue a voice control instruction to control the remote device to perform a specified operation, thereby generating a resource call request.

[0132] Upon receiving a resource call request, the electronic device may determine a corresponding resource scenario based on device information. The device information related to cross-device interaction may include, but is not limited to, the master-slave mode of the electronic device (e.g., the electronic device is a master device or a slave device), the working state information of the electronic device (e.g., the electronic device is in a normal state or a fault state), and the resource quantity of the electronic device (e.g., whether the electronic device includes a camera or the number of cameras of the electronic device). After determining the resource scenario, the electronic device will determine a resource call function corresponding to the resource scenario and execute the resource call function, thereby performing cross-device interaction of resources. Optionally, the electronic device may callback the corresponding resource call function and perform cross-device interaction of resources during the callback process.

[0133] In some embodiments, the cross-device interaction scenario may include a cross-device resource complementary scenario and a cross-device resource collaboration scenario.

[0134] Multiple devices can complement resources. For example, if the camera of the first electronic device is unavailable and the camera of the second electronic device is available, then when the two devices are interconnected, cross-device resource complementarity can be performed. For example, an application on the first electronic device can receive data transmitted back by the camera of the second electronic device, thereby enhancing the function support of the first electronic device.

[0135] Code Two is an example of the first source code in the first programming language, which describes the resource call process of the first electronic device in the cross-device resource complementary scenario.

[0136] Code Two:

[0137]

[0138] It can be seen that the resource scenario of the first electronic device is the camera master mode, that is, the first electronic device is the master device. Therefore, the corresponding scenario description function takePhoto() is executed, and the static attribute camType('auto') indicates that the camera status attribute is automatic. Therefore, the first electronic device can take a photo by calling the local camera through onPhoto(), or can take a photo by calling the remote camera through onGetRemote(), that is, call the camera of the second electronic device to take a photo.

[0139] Code three is an illustrative example of the first source code in the first programming language. Code three describes the resource invocation process of the second electronic device in the cross-device resource complementary scenario.

[0140] Code three:

[0141]

[0142]

[0143] It can be seen that the resource scenario of the second electronic device is the camera slave mode, that is, the second electronic device is the slave device. Therefore, the corresponding scenario description function takePhoto() is executed. The static attribute camType('local') indicates that the camera status attribute is local. Therefore, the second electronic device can send the captured image data to the first electronic device through onSetRemote().

[0144] Multiple devices can cooperate on resources. For example, when the first electronic device and the second electronic device are interconnected, the first electronic device can operate the camera of the second electronic device for cross-device resource cooperation to enhance the function support of the second electronic device.

[0145] Code four is an illustrative example of the first source code in the first programming language. Code four describes the resource invocation process of the first electronic device in the cross-device resource cooperation scenario.

[0146] Code four:

[0147]

[0148] It can be seen that the resource scenario of the first electronic device is the camera master mode, that is, the first electronic device is the master device. Therefore, the corresponding scenario description function takePhoto() is executed. The static attribute camType('remote') indicates that the camera status attribute is remote. The first electronic device can not only control the remote camera to take pictures and obtain the image data returned by the remote camera, but also send the captured image data to the second electronic device through onSetRemote() to achieve resource cooperation. The first electronic device can both send and receive data.

[0149] Code five is an illustrative example of the first source code in the first programming language. Code five describes the resource invocation process of the first electronic device in the cross-device resource cooperation scenario.

[0150] Code five:

[0151]

[0152]

[0153] It can be seen that the resource scenario of the second electronic device is the camera slave mode, that is, the second electronic device is the slave device. Therefore, the corresponding scenario description function takePhoto() is executed. The static attribute camType('local') indicates that the camera status attribute is local. The second electronic device can send the captured image data to the first electronic device through onSetRemote().

[0154] In summary, the first programming language can provide a unified device operation interface and status management. Since the first programming language provides resource abstraction and resource description, it can help simplify the development process and improve the flexibility of resource operations. Resource abstraction can mask the differences between different platforms and devices. During the process of resource invocation, cross-device resource interaction can be achieved, and resource collaboration and resource complementarity among multiple devices can be realized, which helps to enhance the functional support between electronic devices and enables developers to develop resource collaboration and resource complementarity operations among multiple devices in a more concise and natural way, reducing the development difficulty of developers and improving the development efficiency.

[0155] In some embodiments, the same set of source code using the first programming language can be adapted according to the target platform, that is, adapted according to the electronic device actually used by the user, so as to achieve multi-device compatibility of the code. The adaptation methods may include: providing a consistent interface through the Software Development Kit (SDK) and performing adaptation at the SDK layer; or performing adaptation at the syntax layer, such as conditional compilation according to the @target(phone, pad) statement, and adapting different devices through the decorator @target, such as conditional compilation through the @target(phone, pad) statement.

[0156] Please refer further to Figure 5 , Figure 5 which is a schematic flowchart of a resource invocation method in another embodiment. This method can be applied to the above-mentioned electronic devices, such as Figure 5 shown. The resource invocation method may include the following steps:

[0157] 501. Receive a resource invocation request.

[0158] 502. Determine the resource scenario according to the resource invocation request.

[0159] 503. Determine the resource invocation function that matches the resource scenario, and execute the resource invocation function to invoke the resources of the resource scenario.

[0160] Among them, the resource calling function is compiled from the first source code. The first source code uses the first programming language, and the resource calling function uses the second programming language. The first source code is used to declare one or more abstract resource objects included in the resource scenario, and each abstract resource object is used to describe the corresponding resource.

[0161] 504. When it is detected that an exception occurs in the resource scenario, an exception handling function matching the resource scenario is called to handle the exception.

[0162] Among them, the exception handling function is compiled from the second source code. The second source code uses the first programming language, and the exception handling function uses the second programming language. The second source code includes an error identifier and a handling identifier. The error identifier is used to identify the occurred exception, and the handling identifier is used to identify the handling operation for the occurred exception.

[0163] The exception handling function is a function used to handle exceptions. The second source code is the source code in the first programming language used to compile the exception handling function.

[0164] The exception handling function describes the process of exception handling through the error identifier and the handling identifier.

[0165] The error identifier is used to identify the occurred exception. Different exceptions correspond to different error identifiers. For example, exceptions can include but are not limited to various states such as invalid permissions, device status errors, input / output errors, data transmission errors, etc. Each exception can correspond to an error identifier. For example, invalid permissions can use the error identifier 001, and device status errors can use the error identifier 002, etc.

[0166] The handling identifier is used to identify the handling operation for the occurred exception. The handling operations for the occurred exception can include but are not limited to retry, end, and skip.

[0167] As Figure 6 shown, Figure 6 is a schematic diagram of the exception handling process in an embodiment.

[0168] The exception handling function at the application layer is function(code, errProcess), where code is the error identifier and errProcess is the handling identifier.

[0169] The resource management class in the framework layer already has an exception handling class built-in. The exception handling class is used to provide exception handling measures. The design of the exception handling process includes the definition of the error code ErrorCode and the exception handling interface ErrorProcess in the framework layer. ErrorProcess provides three process handling functions for when an exception occurs: retry, end, and skip. The resource management class module needs to implement ErrorProcess, and when an exception occurs, pass the error code ErrorCode and the exception handling object ErrorProcess to the application layer, so that the error identifier and the handling identifier in the exception handling function function(code, errProcess) in the application layer are assigned values, and then call back the exception handling function set by the application layer. The application layer can implement the code related to specific exception handling.

[0170] If the user needs to obtain the exception information for customized processing, they can judge and process the returned error code through onError(errcode:Number, errProcess:ErrorProcess). The customized exception handling method provided by ErrorProcess can be as shown in Code Six below.

[0171] Code Six:

[0172]

[0173] It can be seen that the exception handling function includes the error identifier errcode and the handling identifier ErrorProcess. When the error identifier indicates that the exception is an invalid permission, the handling operation indicated by the corresponding handling identifier is a retry operation. When the error identifier indicates that the exception is a device status error, the handling operation indicated by the corresponding handling identifier is a skip operation. When the error identifier indicates that the exception is an input / output error, the handling operation indicated by the corresponding handling identifier is an end operation. When the error identifier indicates that the exception is a data transmission error, the handling operation indicated by the corresponding handling identifier is to output the text "Send failed".

[0174] In summary, the first programming language can provide dedicated functions for device exception handling, can adapt to a wide range of exception scenarios. The second source code of the first programming language describes the exception handling process through the exception handling function, can flexibly execute corresponding exception handling operations for different exception scenarios, and enables developers to develop exception handling operations in a more concise and natural way, reducing the development difficulty of developers and improving the development efficiency.

[0175] In some embodiments, the language design of the first programming language is not limited to a specific runtime. Support for the first programming language can be added at the operating system level, and the underlying device interfaces can be exposed for the first programming language, so that the syntax for declaring and calling resources in the first programming language can be further simplified to make it more concise.

[0176] In some embodiments, by adding a monitoring interface for device status to the underlying operating system, it may be possible to achieve two-way binding of the status of the underlying device using the first programming language, and the changes in the device status can be timely feedback, thus avoiding the way of manually inserting stub function callbacks to simulate this action. This will greatly enhance the management and control capabilities of the first programming language for device resources and make the code more concise.

[0177] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of a resource calling device in an embodiment. This device is applied to the above-mentioned electronic device. As Figure 7 shown, the resource calling device 700 may include: a receiving module 710, a determining module 720, and a calling module 730.

[0178] The receiving module 710 is configured to receive a resource calling request;

[0179] The determining module 720 is configured to determine a resource scenario according to the resource calling request;

[0180] The calling module 730 is configured to determine a resource calling function that matches the resource scenario and execute the resource calling function to call the resources of the resource scenario; the resource calling function is compiled from a first source code. The first source code uses the first programming language, and the resource calling function uses the second programming language; the first source code is used to declare one or more abstract resource objects included in the resource scenario, and each abstract resource object is used to describe the corresponding resource.

[0181] In one embodiment, the first source code includes a scenario description function corresponding to the resource scenario; the scenario description function contains one or more abstract resource objects corresponding to the resource scenario; the abstract resource object includes an attribute variable and / or an action variable. The attribute variable is used to describe the static attribute of the corresponding resource, and the action variable is used to describe the action attribute of the corresponding resource.

[0182] In one embodiment, the scenario description function is decorated by a scenario decorator, and the scenario decorator is used to label the resource scenario corresponding to the scenario description function.

[0183] In one embodiment, the abstract resource object is decorated by a resource decorator, and the resource decorator is used to label the resource description of the abstract resource object; the attribute variable is decorated by an attribute decorator, and the attribute decorator is used to label the static attribute of the abstract resource object to which the attribute variable belongs.

[0184] In one embodiment, the resource invocation method is applied to a first electronic device; in the case where the resource scenario is a cross-device interaction scenario, the static attribute includes the status identifier of the first electronic device, and the action attribute includes the data transmission operation and / or device control operation performed on the second electronic device.

[0185] In one embodiment, when it is detected that an exception occurs in the resource scenario, an exception handling function matching the resource scenario is called to handle the exception; the exception handling function is compiled from a second source code, the second source code uses a first programming language, and the exception handling function uses a second programming language; the second source code includes an error identifier and a handling identifier, the error identifier is used to identify the occurred exception, and the handling identifier is used to identify the handling operation for the occurred exception.

[0186] In one embodiment, the first programming language includes a domain-specific language DSL extended based on the TypeScript language, and the second programming language includes the JavaScript language or the TypeScript language.

[0187] In the embodiments of the present application, the corresponding resource scenario is automatically matched according to the received resource invocation request, and the resource invocation function matching the resource scenario is executed, so as to invoke the resources of the resource scenario. In the embodiments of the present application, when developers need to perform resource-related development, they can write a first source code in the first programming language, use the first source code to declare one or more abstract resource objects that describe the corresponding resources included in the resource scenario, and perform resource abstraction and resource description on the resources of the resource scenario through the abstract resource objects, which enables developers to develop resources in a more concise and natural manner, reduces the development difficulty of developers, and improves the development efficiency.

[0188] Please refer to Figure 8 , Figure 8 is a schematic structural diagram of an electronic device in an embodiment. As Figure 8 shown, the electronic device 800 may include: a memory 810 storing executable program code; a processor 820 coupled to the memory 810; wherein, the processor 820 invokes the executable program code stored in the memory 810 to execute any resource invocation method disclosed in the embodiments of the present application.

[0189] The embodiments of the present application disclose a development system for resource invocation. The development system includes an application layer, an interface layer, a framework layer, and a platform layer; the application layer is used to provide a first programming language for application development; the interface layer provides a resource description interface that can be invoked in the first programming language; the framework layer is used to provide classes included in the first programming language; the platform layer is used to compile and run the application code developed by the application layer.

[0190] An embodiment of the present application discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by the processor, the processor implements any one of the resource calling methods disclosed in the embodiments of the present application.

[0191] It should be understood that the "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the "in one embodiment" or "in an embodiment" that appears throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics may be combined in any suitable manner in one or more embodiments. Those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0192] In various embodiments of the present application, it should be understood that the magnitudes of the serial numbers of the above processes do not necessarily mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The units described as separate components above may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, the functional units in each embodiment of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0193] When the above integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-accessible memory. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several requests to enable a computer device (which can be a personal computer, a server, or a network device, etc., specifically, the processor in the computer device) to execute some or all of the steps of the above methods in various embodiments of this application. Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing relevant hardware through a program. This program can be stored in a computer-readable storage medium, and the storage medium includes a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electrically-erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc memories, magnetic disk memories, tape memories, or any other computer-readable medium that can be used to carry or store data.

[0194] The above has introduced in detail a resource invocation method, a development system, a device, an electronic device, and a storage medium disclosed in the embodiments of this application. Specific examples are used in this article to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. At the same time, for those of ordinary skill in the art, according to the idea of this application, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to this application.< / resconfig>

Claims

1. A resource calling method, characterized in that, The method includes: Receiving a resource call request; Determining a resource scenario according to the resource call request; Determining a resource call function that matches the resource scenario, and executing the resource call function to call the resources of the resource scenario; the resource call function is compiled from a first source code, the first source code uses a first programming language, and the resource call function uses a second programming language; the first source code is used to declare one or more abstract resource objects included in the resource scenario, and each of the abstract resource objects is used to describe the corresponding resource.

2. The method according to claim 1, characterized in that, The first source code includes a scenario description function corresponding to the resource scenario; the scenario description function includes one or more abstract resource objects corresponding to the resource scenario; The abstract resource object includes an attribute variable and / or an action variable, the attribute variable is used to describe the static attribute of the corresponding resource, and the action variable is used to describe the action attribute of the corresponding resource.

3. The method according to claim 2, wherein The scenario description function is decorated by a scenario decorator, and the scenario decorator is used to label the resource scenario corresponding to the scenario description function.

4. The method according to claim 2, wherein The abstract resource object is decorated by a resource decorator, and the resource decorator is used to label the resource description of the abstract resource object. The attribute variable is decorated by an attribute decorator, and the attribute decorator is used to label the static attribute of the abstract resource object to which the attribute variable belongs.

5. The method according to claim 2, characterized in that, The resource call method is applied to a first electronic device; in the case where the resource scenario is a cross-device interaction scenario, the static attribute includes a status identifier of the first electronic device, and the action attribute includes a data transmission operation and / or a device control operation performed on a second electronic device.

6. The method according to claim 1, characterized in that, The method further includes: In the case of detecting an abnormality in the resource scenario, calling an exception handling function that matches the resource scenario for exception handling; the exception handling function is compiled from a second source code, the second source code uses the first programming language, and the exception handling function uses the second programming language; the second source code includes an error identifier and a processing identifier, the error identifier is used to identify the occurred exception, and the processing identifier is used to identify the processing operation for the occurred exception.

7. The method according to claim 1, wherein The first programming language includes a domain-specific language DSL extended based on the TypeScript language, and the second programming language includes the JavaScript language or the TypeScript language.

8. A development system for resource invocation, characterized in that, The development system includes an application layer, an interface layer, a framework layer, and a platform layer; The application layer is used to provide the first programming language for application development; The interface layer provides a resource description interface that can be called in the first programming language; The framework layer is used to provide classes included in the first programming language; The platform layer is used to compile and run the application code developed by the application layer.

9. A resource calling device, characterized in that, The apparatus includes: A receiving module, configured to receive a resource call request; A determining module, configured to determine a resource scenario according to the resource call request; A calling module, configured to determine a resource calling function that matches the resource scenario and execute the resource calling function to call the resources of the resource scenario; the resource calling function is compiled from a first source code, the first source code uses a first programming language, and the resource calling function uses a second programming language; the first source code is used to declare one or more abstract resource objects included in the resource scenario, and each of the abstract resource objects is used to describe the corresponding resource.

10. An electronic device, characterized in that, It includes a memory and a processor. A computer program is stored in the memory. When the computer program is executed by the processor, the processor implements the method according to any one of claims 1 to 7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 7.

Images