Decoupling type program authority management method and device
By using a unified permission management interface and declarative API, the inconsistency and coupling issues of permission requests in mobile applications are resolved, achieving consistency and logical decoupling of permission interactions, thereby improving user experience and development efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-07
AI Technical Summary
The decentralized implementation of permission verification and requests in existing mobile applications leads to inconsistent user experience and difficulties in development and maintenance. The permission processing logic is highly coupled with the user interface logic, making it difficult to maintain and extend.
A unified permission management interface and pre-configured logic are introduced. Permission type identifiers unify permission verification, requests, and interaction content. Permission verification abstract classes and declarative APIs are used to decouple permission logic from business logic.
Ensure consistency of interaction for the same permission type across different business modules, reduce development complexity and coupling, improve user experience and system maintainability, and support flexible expansion and simplified development processes.
Smart Images
Figure CN121808761A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of program development, and particularly relates to a decoupled program permission management method and device. BACKGROUND
[0002] In the development of mobile applications, permission checking and requesting is the basic link to realize various functions. At present, the processing method commonly used in the industry is that the developer writes the corresponding permission application code in each business function module that needs permission. This decentralized implementation method leads to significant problems, which are embodied in the following two aspects:
[0003] 1. Inconsistent user experience: Due to the lack of unified management, the request and guidance experience of the same permission in the same application in different functional scenarios may be completely disjointed. For example, in a smart home App, the Bluetooth permission is needed by multiple functional modules:
[0004] Scenario one: "Scan and add device" function (developer A implementation). When the Bluetooth permission is needed, A may have designed a detailed explanation pop-up window to explain "Bluetooth permission is needed to discover and pair your new device". If the user refuses, A will show a full-screen guidance page with illustrations and instructions to guide the user to open the permission in the system settings.
[0005] Scenario two: "Device remote control" function (developer B implementation). When connecting a device also needs Bluetooth permission, B may directly call the system's default request pop-up window without any additional explanation. After the permission is refused, B only uses a short Toast message to prompt "Bluetooth connection failed".
[0006] Result: The user experiences two completely different experiences in process, interaction and prompt quality when facing the same permission request ("Bluetooth permission" request) of the same APP. This inconsistency confuses the user and seriously damages the professionalism and smoothness of the user experience of the application.
[0007] 2. Development and maintenance difficulties: The permission processing logic, user interface logic and business function logic are highly coupled. For example, when the product manager requires that all Bluetooth permission rejection guidance styles be unified, the development team must coordinate developers A and B to modify the scattered permission handling code in the "Scan and Add Device" and "Device Remote Control" modules. This modification not only involves repetitive work, but also is extremely prone to new inconsistencies due to poor communication or omissions. This architectural defect makes the code highly difficult to maintain and extend.
[0008] Therefore, it is necessary to improve the existing permission checking method to improve the consistency of the permission interaction experience within the application and reduce the development coupling degree between functional modules.
[0009] The information disclosed in this background section is included only to enhance the understanding of the context of this disclosure, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0010] One objective of this invention is to provide a decoupled program permission management method and apparatus that can improve the consistency of permission interaction experience within an application and reduce the development coupling between various functional modules.
[0011] To achieve the above objectives, the present invention provides a decoupled program permission management method, comprising:
[0012] Through a unified permission management interface, at least one permission processing request is received from at least one business function module in the application; wherein each permission processing request carries a target permission type identifier, and permission processing requests of the same type carry the same target permission type identifier.
[0013] Based on the target permission type identifier, the corresponding pre-configured permission verification logic is invoked to perform a system permission status check and obtain the permission verification result:
[0014] If the permission verification result shows that the permission has not been granted, a permission request process is executed, which includes initiating a permission request to the operating system, displaying unified interactive content to the user, and obtaining the user's response operation; if the permission verification result shows that the permission has been granted, a confirmation message that the permission has been granted is directly generated.
[0015] The confirmation message indicating that the permission has been granted or the user's response operation is returned to the business function module.
[0016] Optionally, before receiving at least one permission processing request from at least one business function module in the application through a unified permission management interface, the method further includes:
[0017] For different target permission type identifiers, pre-configure corresponding permission verification logic, permission request logic, and interaction content.
[0018] Optional,
[0019] The pre-configured permission verification logic, permission request logic, and interaction content are all bound to the target permission type identifier, so that the permission verification logic, permission request logic, and interaction content corresponding to each permission processing request pointing to the same target permission type identifier remain consistent.
[0020] Optionally, the permission verification logic is implemented based on a permission verification abstract class;
[0021] The abstract class for permission verification defines a general interface for permission verification, and the specific permission verification logic is implemented by subclasses that inherit from this abstract class.
[0022] The interactive content is managed and provided by a permission dialog box data class that is independent of the business function modules.
[0023] Optionally, the predefined interactive content in the permission dialog box data class includes: permission usage description information, guidance information after permission is denied, and icons and / or text content required for user interface display.
[0024] Optionally, the "perform system permission status check" includes:
[0025] Each target permission type identifier is verified sequentially. If the first target permission type identifier with an ungranted permission status is encountered during the verification process, the subsequent verification is terminated, and the verification result is taken as the final permission verification result.
[0026] Optionally, the unified permission management interface is a declarative application programming interface, used to receive declarative configurations of target permission type identifiers and interaction content.
[0027] Optionally, the unified permission management interface is also used to manage the lifecycle state of asynchronous operations from permission verification to result return.
[0028] Optional,
[0029] When the permission processing request carries multiple target permission type identifiers, the target permission type identifiers are combined into a permission list;
[0030] The method sequentially processes each target permission type identifier in the permission list, and renders the user interface uniformly based on the final verification and request results of all target permission type identifiers in the permission list.
[0031] On the other hand, a permission management device is provided for executing any of the decoupled program permission management methods described above, including:
[0032] The request receiving module is used to receive at least one permission processing request from at least one business function module in the application through a unified permission management interface; wherein each permission processing request carries a target permission type identifier, and permission processing requests of the same type carry the same target permission type identifier.
[0033] The verification processing module is used to call the corresponding pre-configured permission verification logic based on the target permission type identifier, perform a system permission status check, and obtain the permission verification result.
[0034] The request execution module is used to execute a permission request process if the permission verification result shows that the permission has not been granted. The permission request process includes initiating a permission request to the operating system, displaying unified interactive content to the user, and obtaining the user's response operation. If the permission verification result shows that the permission has been granted, a confirmation message indicating that the permission has been granted is directly generated.
[0035] The result return module is used to return the confirmation information that the permission has been granted or the user response operation to the business function module.
[0036] The beneficial effects of this invention are as follows: It provides a decoupled program permission management method and apparatus. First, through a "unified permission management interface" and "unified interaction content," it ensures that when the same permission type is requested in different business modules, the user's seen process, prompt text, and interface style are completely consistent, thus completely eliminating fragmented experience. Second, it encapsulates complex permission verification, request, and UI interaction logic, requiring only simple calls and result reception from business function modules. This achieves complete decoupling of permission logic and business logic, greatly reducing code complexity and making development and maintenance simple and efficient.
[0037] Therefore, the decoupled program permission management method and apparatus provided by the present invention can improve the consistency of permission interaction experience within the application and reduce the development coupling between various functional modules. Attached Figure Description
[0038] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0039] Figure 1 A flowchart of the decoupled program permission management method provided in this embodiment;
[0040] Figure 2 A structural block diagram of the permission management device provided in the embodiment. Detailed Implementation
[0041] In this invention, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of the invention. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in this invention, as long as there is no technical contradiction or conflict, the technical features mentioned in each embodiment can be combined in any way to form a corresponding implementable technical solution.
[0042] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit the invention.
[0043] In the description of this invention, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and A and B exist simultaneously. Additionally, the character " / " generally indicates that the preceding and following objects have an "or" logical relationship.
[0044] Without further limitations, the use of terms such as “comprising,” “including,” “having,” or other similar expressions in this invention is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a list of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.
[0045] Example 1
[0046] See Figure 1 This embodiment provides a decoupled program permission management method, including:
[0047] Step S100: Receive processing request: Receive at least one permission processing request from at least one business function module in the application through a unified permission management interface; wherein each permission processing request carries a target permission type identifier, and permission processing requests of the same type carry the same target permission type identifier.
[0048] Step S200: Perform permission verification: Based on the target permission type identifier, call the corresponding pre-configured permission verification logic to perform a system permission status check and obtain the permission verification result;
[0049] Step S300, Permission Request Process Execution Steps: If the permission verification result shows that the permission has not been granted, a permission request process is executed. The permission request process includes initiating a permission request to the operating system, displaying unified interactive content to the user, and obtaining the user's response operation; if the permission verification result shows that the permission has been granted, a confirmation message that the permission has been granted is directly generated.
[0050] Step S400, Result Return Step: Return the confirmation information that the permission has been granted or the user response operation to the business function module.
[0051] The decoupled program permission management method begins in step S100, receiving one or more permission processing requests from one or more business function modules through a unified permission management interface. Each request carries its target permission type identifier, and crucially, when these requests belong to the same category, their target permission type identifiers must be identical. In step S200, the system calls pre-configured verification logic to perform a rapid system-level status check based on the target permission type identifier. Step S300 constitutes the decision core: if permission has been granted, confirmation information is directly generated; if not granted, a complete request process is initiated. This process not only sends a request to the system but, more importantly, displays unified interactive content to the user and obtains their response. Finally, in step S400, regardless of whether the result comes from direct confirmation or user interaction, it is uniformly returned to the original business module.
[0052] The aforementioned decoupled program permission management method, firstly, ensures that when the same permission type is requested in different business modules, the user's experience, including the flow, prompts, and interface style, remains completely consistent, thus eliminating fragmented user experience, through a "unified permission management interface" and "unified interaction content." Secondly, it encapsulates complex permission verification, request, and UI interaction logic, requiring only simple calls and result reception from business functional modules. This achieves complete decoupling of permission logic from business logic, significantly reducing code complexity and making development and maintenance simple and efficient.
[0053] Therefore, the decoupled program permission management method provided by the present invention can improve the consistency of permission interaction experience within the application and reduce the development coupling between various functional modules.
[0054] Optionally, before step S100, the following may also be included:
[0055] Step S001: Pre-configure permission content: For different target permission type identifiers, pre-configure the corresponding permission verification logic, permission request logic, and interaction content.
[0056] Before receiving a processing request, developers pre-configure three elements for at least one target permission type identifier (such as Bluetooth permission) that needs to be managed: permission verification logic for checking the status, permission request logic for initiating a request to the system, and interface content for user interaction. This configuration process is usually completed during application initialization or module loading, preparing for all subsequent runtime requests.
[0057] By introducing a separate configuration phase, permission management is completely separated from business logic code, achieving a separation of "configuration" and "execution." This allows adjustments to permission policies (such as updating prompt text or adding new permission types) to be made without modifying any business logic code; they can be managed uniformly during the configuration phase, significantly improving system maintainability and scalability. This provides the entire approach with high flexibility and reusability.
[0058] Specifically,
[0059] The pre-configured permission verification logic, permission request logic, and interaction content are all bound to the target permission type identifier, so that the permission verification logic, permission request logic, and interaction content corresponding to each permission processing request pointing to the same target permission type identifier remain consistent.
[0060] During the configuration phase, the pre-defined validation logic, request logic, and interaction content for a specific target permission type identifier (e.g., down to the "Bluetooth Scan" permission) are strictly bound to the unique identifier of that permission. When any business function module in the application (such as the "Scan Device" page and the "Device Remote Control" page) issues a request carrying this target permission type identifier, the system will automatically and enforce the use of this bound logic and content for processing.
[0061] This "binding" mechanism is the technical guarantee for achieving a "unified" experience. It ensures that regardless of which module the request originates from or which developer wrote it, as long as the target is the same permission, the processing flow and user interface remain constant. This enforces consistency from an architectural perspective, avoiding differences caused by human factors, making "decoupling" and "unification" no longer development specifications, but rather built-in characteristics of the system.
[0062] Optionally, the permission verification logic is implemented based on a permission verification abstract class;
[0063] The abstract class for permission verification defines a general interface for permission verification, and the specific permission verification logic is implemented by subclasses that inherit from this abstract class.
[0064] The interactive content is managed and provided by a permission dialog box data class that is independent of the business function modules.
[0065] Specifically, the permission verification logic is implemented through an object-oriented "permission verification abstract class." This abstract class defines a general verification interface, while the specific verification code for different permissions such as Bluetooth and location is implemented by subclasses that inherit from this abstract class (such as BluetoothPermissionCheck). Meanwhile, all interactive content (such as icons, titles, and descriptive text) is centrally managed in a separate "permission dialog data class," independent of any business module.
[0066] By using abstract classes, adding support for new permissions becomes incredibly simple; all that's needed is to create a new subclass and implement the specific logic. This adheres to the open / closed principle and significantly improves the system's scalability. Furthermore, digitizing interactive content and managing it through independent classes achieves complete separation of logic and UI. This means that modifying the application's interface style doesn't require touching the program code; only the data content needs to be updated, greatly reducing the cost and risk of UI iteration.
[0067] In this embodiment, the predefined interactive content in the permission dialog box data class includes: permission usage description information, guidance information after permission is denied, and icons and / or text content required for user interface display. By clearly defining these content elements, the completeness and professionalism of the permission request interface information are ensured. For example, when Bluetooth permission is denied, the system can display a unified and user-friendly guidance page instead of a rigid system error message. This design transforms user experience details into configurable data, allowing product or designer personnel to directly participate in optimization without developer intervention, further improving collaboration efficiency and the final user experience quality.
[0068] In this embodiment, the "execution system permission status check" in step S100 includes:
[0069] Each target permission type identifier is verified sequentially. If the first target permission type identifier with an ungranted permission status is encountered during the verification process, the subsequent verification is terminated, and the verification result is taken as the final permission verification result.
[0070] Specifically, the process of performing system permission status checks requires sequentially traversing the list of target permission type identifiers to be verified. During this process, the system employs an efficient "short-circuit" logic: once the first permission in the list is detected as "not granted," the check of subsequent permissions is immediately terminated. At this point, the first ungranted permission is recorded and directly used as the final result of this verification.
[0071] This "short-circuit" verification mechanism delivers significant performance advantages. In scenarios requiring the checking of multiple permissions (e.g., a function needing to simultaneously verify network status and storage permissions), it avoids unnecessary subsequent checks after a known failure exists, thereby reducing system overhead and speeding up response times. More importantly, it can quickly pinpoint the most pressing permission issue (i.e., the first unauthorized permission) and immediately guide the user to resolve it, improving the efficiency and relevance of the interaction.
[0072] In this embodiment, the unified permission management interface is a declarative application programming interface (API) used to receive declarative configurations of target permission type identifiers and interaction content, and automatically execute subsequent permission verification and request processes based on these configurations.
[0073] Declarative Application Programming Interfaces (APIs) operate on a declarative model, meaning developers don't need to write traditional, step-by-step "procedural" code (i.e., worrying about "how" and "when" to validate and request). Instead, developers simply "declare" the target permission types required for their business functionality, along with the interactive content they want to display in different states (e.g., authorization success, failure). Upon receiving these declarative configurations, the API automatically drives and executes the entire process from permission validation to request.
[0074] Adopting a declarative API greatly simplifies development complexity and lowers the barrier to entry. Developers can focus entirely on the business logic itself—"what is needed" and "what to display in various situations"—while delegating the tedious details of permission handling to the framework's underlying layer. This not only significantly improves development efficiency and reduces code volume but also ensures a clear separation between permission logic and business logic from a design paradigm perspective, making the code more readable and maintainable.
[0075] Optionally, the unified permission management interface not only handles the initiation of permission requests and the return of results, but also acts as a central manager, monitoring and managing the entire lifecycle of the asynchronous operation from initiating permission verification to finally returning the result to the business module. This includes handling complex situations such as potential network latency, user response waiting, and mid-process request cancellation. For example, if a user switches application pages while a permission request is in progress, the unified permission management interface can detect the change in page lifecycle and automatically suspend or cancel the incomplete permission request, preventing the callback function from executing in a destroyed context and causing application crashes.
[0076] Centralized management of asynchronous lifecycles significantly enhances the robustness and reliability of the entire permission processing flow. It effectively prevents callback loss or state inconsistencies caused by page navigation, application background processes, and other scenarios, ensuring that business modules receive definite and accurate processing results under all circumstances. This provides users with a more stable and smoother experience, while also reducing the burden on developers in handling various edge cases.
[0077] In this embodiment, when the permission processing request carries multiple target permission type identifiers, the target permission type identifiers are formed into a permission list;
[0078] The method sequentially processes each target permission type identifier in the permission list, and renders the user interface uniformly based on the final verification and request results of all target permission type identifiers in the permission list.
[0079] Specifically, when a permission processing request carries multiple target permission type identifiers (for example, a smart access control app's "fingerprint enrollment" function requires both "biometric" and "key creation" permissions), this method automatically organizes these target permission type identifiers into a permission list. Subsequently, the system does not initiate all requests simultaneously, but processes each permission type sequentially according to the list order. After all permissions have been processed (whether all are automatically granted or after partial requests and user interaction), the system performs a one-time, unified user interface update and rendering based on a final overall state (such as "all permissions granted successfully" or "a certain permission denied").
[0080] This solution perfectly addresses the user experience challenges of batch permission requests. It avoids the annoyance of multiple system permission pop-ups that occur in traditional methods, and prevents the UI from frequently flickering and updating due to the successive return of permission results. Through sequential processing and unified rendering, it transforms a potentially chaotic process into a well-organized one, displaying the most suitable guided interface based on the final aggregated result. This provides a clear, coherent, and professional one-time interactive experience, significantly improving user satisfaction and permission granting rates.
[0081] To more clearly illustrate the technical solution and beneficial effects of the present invention, the following describes specific implementation scenarios of the above-mentioned decoupled program permission management method in conjunction with typical application scenarios in the field. It should be understood that the described implementation scenarios are only a part of the implementation scenarios of the present invention, and not all of them.
[0082] Implementation Scenario 1: Pure permission status verification in the permission management page
[0083] In the application's "Permission Management" settings page, it is necessary to clearly display to the user the current authorization status of all sensitive permissions (such as camera, contacts, location, etc.). In this scenario, only the permission status needs to be verified, without initiating permission requests.
[0084] Implementation details: Developers pre-configure corresponding permission verification classes (such as CameraCheckPermission, LocationCheckPermission) for "camera permission," "location permission," etc. These classes inherit from the aforementioned abstract permission verification class and implement its validate() method. When the permission management page loads, these permission verification classes are passed in through the unified permission management interface (UIPermission component). This interface will sequentially call the validate() method of each class to perform system verification.
[0085] Workflow: After verification, the page will uniformly render the UI based on the verification results of all permissions. For example, for granted permissions, a green "Authorized" indicator and a checkmark icon will be displayed next to the corresponding entry; for ungranted permissions, a gray "Unauthorized" indicator and a warning icon will be displayed. The display style of all statuses is controlled by predefined content such as passedPermissionContent and invalidPermissionContent, ensuring a consistent interface style.
[0086] Beneficial effects: This implementation scenario demonstrates the application of the present invention in a pure verification scenario. Developers do not need to write repetitive checking logic in the code for each permission entry; they only need to declare the list of permissions to be verified to automatically obtain a uniformly styled permission status display page, greatly simplifying development and ensuring a consistent user experience.
[0087] Implementation Scenario 2: Multiple Permission Requests and Guidance on the Device Scanning Page
[0088] On the "Scan to Add Device" page of a smart home app, this function requires that the device's Bluetooth is enabled (system settings) and that the app has been granted Bluetooth scanning permission (application permission). This is a typical scenario involving conditional, multi-permission requests.
[0089] Implementation details: Developers pre-configure two classes: BluetoothEnableCheckPermission (Bluetooth enable verification class) and RequestBluetoothPermission (Bluetooth permission request class), and bind them to a unified PermissionDialogData, which contains detailed instructions on the purpose of the permission and guidance information after denial. On the scanning page, these two classes are passed in sequentially through the UIPermission component.
[0090] Work process:
[0091] The system first checks if Bluetooth is enabled. If it is not enabled, it skips further permission requests and directly displays a pop-up window stating, "Bluetooth is not enabled. Please enable system Bluetooth to scan for devices," and provides a "Go to Enable" button to guide the user to system settings. This process demonstrates the "short-circuit check logic."
[0092] If Bluetooth is already enabled, proceed with the Bluetooth permission request. A consistent explanation will then be displayed to the user: "Bluetooth permission is required to discover and pair your new device."
[0093] If the user refuses authorization, a rejection prompt pop-up will be displayed: "Bluetooth permission is required to use the device scanning function," and a "Go to Settings" button will be provided.
[0094] Device scanning will only begin when both conditions (Bluetooth enabled and permissions granted) are met.
[0095] Beneficial Effects: This implementation scenario vividly demonstrates how the present invention handles complex multi-permission, conditional request processes. It integrates multiple judgment and interaction processes that were originally scattered throughout the business code into a clear, orderly, and automated process. This not only avoids the annoyance of multiple consecutive system pop-ups but also significantly improves permission authorization rates and user experience through unified and user-friendly guidance prompts.
[0096] Implementation Scenario 3: Use of Declarative APIs
[0097] For any function that requires a single permission, such as "upload avatar" which requires camera permission, developers can use the declarative API provided by this invention.
[0098] Implementation details: Developers do not need to write any permission request code; they only need to make declarative configurations in the UI components of the "Upload Avatar" page, for example:
[0099] <UIPermission
[0100] permission={CameraPermission}
[0101] onGranted={() => { / / Open camera}}
[0102] onDenied={() => { / / Display a hint}}
[0103] explanationContent={...} / / Explanation of permission usage
[0104] guideContent={...} / / Guide message after rejection
[0105] / >
[0106] Work process: When the UIPermission component is rendered, it automatically executes the complete process of the decoupled program permission management method: check the camera permission status -> if not authorized, display the configured explanation content and initiate a request -> call back the onGranted or onDenied function according to the user's operation result.
[0107] Beneficial Effects: This implementation scenario highlights the revolutionary development efficiency brought about by the declarative programming paradigm. Developers are completely freed from the tedious details of permission processes, focusing only on the business logic itself ("what is needed" and "what the result should be"). The code is extremely concise and easy to maintain, truly achieving complete decoupling between permission logic and business logic.
[0108] In summary, the solution provided in this embodiment has the following advantages:
[0109] ① By introducing a unified permission management interface and mandating that requests with the same permission have the same identifier, we ensure that when the same permission is processed in different business modules, the interaction flow and user interface content are highly consistent, which fundamentally solves the problem of fragmented user experience.
[0110] ② By pre-configuring and separating permission verification, request, and UI interaction logic from business modules, complete decoupling of permission logic and business logic is achieved, greatly reducing code complexity and coupling between modules, and improving the maintainability and scalability of the system.
[0111] ③ By implementing the permission verification abstract class and its subclasses, supporting new permission types only requires adding new subclasses without modifying the existing architecture, which significantly improves the system's scalability and conforms to the open / closed principle.
[0112] ④ By centrally managing all UI interaction content through an independent permission dialog box data class, the permission logic and user interface presentation are completely separated, so that interface updates and style adjustments do not require modification of program code, reducing UI iteration costs and risks.
[0113] ⑤ By using a declarative application programming interface, developers can use permission functions by declaring requirements rather than writing procedural code, which greatly simplifies the development process, lowers the development threshold, and ensures logical separation from a paradigm perspective.
[0114] Example 2
[0115] This embodiment provides a permission management device for executing any of the decoupled program permission management methods described in Embodiment 1. It is implemented by hardware and / or software and has the same function and beneficial effects.
[0116] See Figure 2 In this embodiment, the access control device includes:
[0117] The request receiving module 2 is used to receive at least one permission processing request from at least one business function module in the application through a unified permission management interface; wherein each permission processing request carries a target permission type identifier, and the target permission type identifier carried by permission processing requests of the same type is the same.
[0118] Verification processing module 3 is used to call the corresponding pre-configured permission verification logic according to the target permission type identifier, perform a system permission status check, and obtain the permission verification result:
[0119] The request execution module 4 is used to execute a permission request process if the permission verification result shows that the permission has not been granted. The permission request process includes initiating a permission request to the operating system, displaying unified interactive content to the user, and obtaining the user's response operation. If the permission verification result shows that the permission has been granted, a confirmation message that the permission has been granted is directly generated.
[0120] Result return module 5 is used to return the confirmation information that the permission has been granted or the user response operation to the business function module.
[0121] This access control device ensures that the user experience—including the flow, prompts, and interface style—remains consistent across different business modules when the same access type is requested, completely eliminating user fragmentation. Secondly, it encapsulates complex access verification, request, and UI interaction logic, allowing business modules to simply call and receive results. This complete decoupling of access control logic from business logic significantly reduces code complexity, making development and maintenance simple and efficient. Furthermore, its device-based implementation allows for deployment and reuse as an independent software component or development package, enhancing the versatility and ease of use of the technical solution.
[0122] Therefore, the permission management device provided by the present invention can improve the consistency of permission interaction experience within the application and reduce the development coupling between various functional modules.
[0123] Optionally, the access control device may also include:
[0124] The pre-configuration module 1 is used to identify different target permission types and pre-configure corresponding permission verification logic, permission request logic, and interaction content.
[0125] Optional,
[0126] The pre-configured permission verification logic, permission request logic, and interaction content are all bound to the target permission type identifier, so that the permission verification logic, permission request logic, and interaction content corresponding to each permission processing request pointing to the same target permission type identifier remain consistent.
[0127] Optionally, the permission verification logic is implemented based on a permission verification abstract class;
[0128] The abstract class for permission verification defines a general interface for permission verification, and the specific permission verification logic is implemented by subclasses that inherit from this abstract class.
[0129] The interactive content is managed and provided by a permission dialog box data class that is independent of the business function modules.
[0130] Optionally, the predefined interactive content in the permission dialog box data class includes: permission usage description information, guidance information after permission is denied, and icons and / or text content required for user interface display.
[0131] Optionally, the "perform system permission status check" includes:
[0132] Each target permission type identifier is verified sequentially. If the first target permission type identifier with an ungranted permission status is encountered during the verification process, the subsequent verification is terminated, and the verification result is taken as the final permission verification result.
[0133] Optionally, the unified permission management interface is a declarative application programming interface, used to receive declarative configurations of target permission type identifiers and interaction content.
[0134] Optionally, the unified permission management interface is also used to manage the lifecycle state of asynchronous operations from permission verification to result return.
[0135] Optional,
[0136] When the permission processing request carries multiple target permission type identifiers, the target permission type identifiers are combined into a permission list;
[0137] The method sequentially processes each target permission type identifier in the permission list, and renders the user interface uniformly based on the final verification and request results of all target permission type identifiers in the permission list.
[0138] It should be noted that, based on Embodiment 1, features not explained in this embodiment are explained using the methods described in Embodiment 1, and will not be repeated in this embodiment.
[0139] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.
Claims
1. A decoupled program permission management method, characterized in that, include: Through a unified permission management interface, at least one permission processing request is received from at least one business function module in the application; wherein each permission processing request carries a target permission type identifier, and permission processing requests of the same type carry the same target permission type identifier. Based on the target permission type identifier, the corresponding pre-configured permission verification logic is invoked to perform a system permission status check and obtain the permission verification result: If the permission verification result shows that the permission has not been granted, a permission request process is executed, which includes initiating a permission request to the operating system, displaying unified interactive content to the user, and obtaining the user's response operation; if the permission verification result shows that the permission has been granted, a confirmation message that the permission has been granted is directly generated. The confirmation message indicating that the permission has been granted or the user's response operation is returned to the business function module.
2. The decoupled program permission management method according to claim 1, characterized in that, Before receiving at least one permission processing request from at least one business function module in the application through a unified permission management interface, the method further includes: For different target permission type identifiers, pre-configure corresponding permission verification logic, permission request logic, and interaction content.
3. The decoupled program permission management method according to claim 2, characterized in that, The pre-configured permission verification logic, permission request logic, and interaction content are all bound to the target permission type identifier, so that the permission verification logic, permission request logic, and interaction content corresponding to each permission processing request pointing to the same target permission type identifier remain consistent.
4. The decoupled program permission management method according to claim 3, characterized in that, The permission verification logic is implemented based on a permission verification abstract class. The abstract class for permission verification defines a general interface for permission verification, and the specific permission verification logic is implemented by subclasses that inherit from this abstract class. The interactive content is managed and provided by a permission dialog box data class that is independent of the business function modules.
5. The decoupled program permission management method according to claim 4, characterized in that, The predefined interactive content in the permission dialog box data class includes: permission usage description information, guidance information after permission is denied, and icons and / or text content required for user interface display.
6. The decoupled program permission management method according to claim 1, characterized in that, The "execution system permission status check" includes: Each target permission type identifier is verified sequentially. If the first target permission type identifier with an ungranted permission status is encountered during the verification process, the subsequent verification is terminated, and the verification result is taken as the final permission verification result.
7. The decoupled program permission management method according to claim 1, characterized in that, The unified permission management interface is a declarative application programming interface used to receive declarative configurations of target permission type identifiers and interaction content.
8. The decoupled program permission management method according to claim 1, characterized in that, The unified permission management interface is also used to manage the lifecycle state of asynchronous operations from permission verification to result return.
9. The decoupled program permission management method according to claim 1, characterized in that, When the permission processing request carries multiple target permission type identifiers, the target permission type identifiers are combined into a permission list; The method sequentially processes each target permission type identifier in the permission list, and renders the user interface uniformly based on the final verification and request results of all target permission type identifiers in the permission list.
10. A permission management device, used to execute the decoupled program permission management method according to any one of claims 1-9, characterized in that, include: The request receiving module is used to receive at least one permission processing request from at least one business function module in the application through a unified permission management interface; wherein each permission processing request carries a target permission type identifier, and permission processing requests of the same type carry the same target permission type identifier. The verification processing module is used to call the corresponding pre-configured permission verification logic based on the target permission type identifier, perform a system permission status check, and obtain the permission verification result. The request execution module is used to execute a permission request process if the permission verification result shows that the permission has not been granted. The permission request process includes initiating a permission request to the operating system, displaying unified interactive content to the user, and obtaining the user's response operation. If the permission verification result shows that the permission has been granted, a confirmation message indicating that the permission has been granted is directly generated. The result return module is used to return the confirmation information that the permission has been granted or the user response operation to the business function module.