Method and device for implementing map encapsulator for vehicle control application

Abstract

The present application provides a method and device for implementing a map encapsulator for a vehicle control application. The method includes: determining a system callback function for performing a map initialization operation, creating a map instance in the system callback function, and initializing the map instance; adding the initialized map instance to the view hierarchy of the page; judging whether the map has been loaded based on a predetermined map area change callback, and performing a preset visual adjustment operation on the map after the map has been loaded; ensuring that the custom node is within the visible area of ​​the map, adjusting the view range to include all key nodes, and performing additional map operations based on the center point or specific node; when the vehicle control application receives an event triggered by the user, adjusting the center point and visual display of the map through the event callback function so that the map view responds to the user's interaction. The present application improves the customization flexibility of the application, enhances the stability of the vehicle control application, and improves the user experience.

Description

Technical Field

[0001] The present application relates to the technical field of application development, and in particular to a method and device for implementing a map encapsulator for a vehicle control application. Background Art

[0002] Map services are an indispensable part of modern vehicle control applications, providing key functions such as vehicle positioning, navigation, and travel services. Conventional solutions on the market often involve directly calling the APIs of map service providers to meet these requirements. However, this approach has a series of problems:

[0003] Errors caused by information opacity: The initialization and configuration process of map services is extremely sensitive to the order, timing, and settings of API calls. Inappropriate calls can lead to map display errors, inaccurate positioning, animation anomalies, and other issues. Because map SDK implementation details are generally not publicly available, developers struggle to fully understand their working principles through official documentation and sample code, making it difficult to meet customized requirements in specific scenarios.

[0004] Differentiated map services: Significant API differences exist between different map services. While their basic functionality is similar, applications targeting different user groups in different regions (e.g., domestically and internationally) require selecting the appropriate map service based on geographic location and user preferences, increasing development complexity and maintenance costs.

[0005] The main problem with existing technologies is the lack of a solution that can flexibly adapt to different map services while simplifying the map service integration and switching process. Developers need to manually manage map API call details and service differences, which not only increases development difficulty but also affects application stability and user experience. Summary of the Invention

[0006] In view of this, an embodiment of the present application provides a method and device for implementing a map encapsulator for a vehicle control application to solve the problem in the existing technology that developers need to manually manage the call details and service differences of the map API, which not only increases the development difficulty, but also affects the stability of the application and user experience.

[0007] In a first aspect of an embodiment of the present application, a method for implementing a map encapsulator for a vehicle control application is provided, comprising: determining a system callback function for performing a map initialization operation, creating a map instance in the system callback function, and initializing the map instance; adding the initialized map instance to the view hierarchy of the page so that the initialized map instance can be rendered on the page; determining whether the map has been loaded based on a predetermined map area change callback, and performing a preset visual adjustment operation on the map after the map has been loaded; ensuring that the custom node is within the visible area of ​​the map, adjusting the view range to include all key nodes, and performing additional map operations based on the center point or specific node; when the vehicle control application receives an event triggered by the user, adjusting the center point and visual display of the map through the event callback function so that the map view responds to user interaction.

[0008] According to a second aspect of an embodiment of the present application, a map encapsulator implementation device for a vehicle control application is provided, comprising: a determination module configured to determine a system callback function for performing a map initialization operation, create a map instance in the system callback function, and initialize the map instance; a rendering module configured to add the initialized map instance to the view hierarchy of the page so as to render the initialized map instance on the page; a judgment module configured to determine whether the map has been loaded based on a predetermined map area change callback, and perform a preset visual adjustment operation on the map after the map has been loaded; an adjustment module configured to ensure that the custom node is within the visible area of ​​the map, adjust the view range to include all key nodes, and perform additional map operations based on the center point or specific node; an interaction module configured to adjust the center point and visual display of the map through the event callback function when the vehicle control application receives an event triggered by the user, so that the map view responds to the user's interaction.

[0009] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0010] By determining the system callback function for performing map initialization operations, creating a map instance in the system callback function and initializing the map instance; adding the initialized map instance to the view hierarchy of the page so that the initialized map instance can be rendered on the page; judging whether the map has been loaded based on the predetermined map area change callback, when the map is loaded, performing preset visual adjustment operations on the map; ensuring that the custom node is within the visible area of ​​the map, adjusting the view range to include all key nodes, and performing additional map operations based on the center point or specific node; when the vehicle control application receives an event triggered by the user, adjusting the center point and visual display of the map through the event callback function so that the map view responds to the user's interaction. This application improves the customization flexibility of the application, enhances the stability of the vehicle control application and the end-user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 This is a flow chart of a method for implementing a map encapsulator for a vehicle control application provided in an embodiment of the present application;

[0013] Figure 2 This is a schematic diagram of the structure of a map encapsulator implementation device for a vehicle control application provided in an embodiment of the present application;

[0014] Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0015] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0016] As described in the background, the general solution for map settings in the market is to call the map API to meet the corresponding requirements. However, this has the following problems:

[0017] 1. Errors caused by information opacity

[0018] When initializing a map, the order, timing, and settings of API calls are crucial. Even the slightest inconsistency can lead to significant discrepancies and undesirable results. For example, if you first set the map level, then the center point, and then adjust the edge position, and if the "animation parameter" for all three APIs is set to true, unexpected phenomena can occur, such as map flickering, the center point not being in the preset position, animation anomalies, and incorrect map positioning areas. Another example is setting the midpoint of Map A in the page's drawing completion function (viewDi dAppear system function). While it might seem like there's no problem on the surface, in practice, you'll find that the map's midpoint is not in the desired location and occasionally exhibits significant positioning errors. These issues are common because the Map SDK is not open source, making its specific implementation unknown. Its development documentation and sample code are also very simplistic, failing to meet the customized needs of automakers in specific scenarios. Therefore, the only way to determine the optimal timing and order for calling the Map APIs is through continuous practice and debugging. This knowledge is then summarized into a fixed set of practices and implemented as a code module (solution). This is the primary reason and purpose behind the development of this patent.

[0019] 2. Differentiation of map services

[0020] Assume that map A and map B are two different map libraries, and their APIs are actually called in many ways. However, the company's project can be made into a collection of modules that can be quickly built. For example: the user app installed on a certain domestic car is for domestic users, so map A is used in terms of vehicle location and travel services, but the app installed on a certain overseas car is for overseas users, so map B is used in terms of vehicle location and travel services. The design and appearance of the two maps in terms of business logic functions are similar. For the purpose of efficient research and development, the map module is an independent business module within the company. It can be freely combined in domestic apps or overseas apps, so this module needs to shield the differences brought by the specific map SDK at the top level, and only intervene in the specific map SDK at the bottom level. This requires the map encapsulator to have the ability to layer + shield the differences between specific map SDKs + maintain the same appearance, which is another aspect of the technical solution of this application.

[0021] The technical solution of this application is based on the best practices of multiple real-machine tests to develop a set of effective map encapsulators. The map encapsulator of this application is applicable to the latest version and historical versions of the map. To meet the needs of vehicle control business, the map center point setting and node style replacement under the customized area can be set. The layered design shields the adaptation differences of different map SDKs and provides a stable and unified API to the outside world. It also supports real-time map switching. Therefore, the purpose of this application is to develop a map encapsulator that can shield the differences between the underlying map SDKs and provide a unified calling interface. The encapsulator should support the rapid integration of different map services, realize the customization of map functions, and flexibly switch map services according to business needs or user choices, so as to solve the limitations of existing technologies and improve the development efficiency and user satisfaction of vehicle control applications.

[0022] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] Figure 1 It is a flowchart of a method for implementing a map encapsulator for a vehicle control application provided in an embodiment of the present application. Figure 1 The map encapsulator implementation method of the vehicle control application can be executed by the application. Figure 1 As shown, the map encapsulator implementation method of the vehicle control application may specifically include:

[0024] S101, determining a system callback function for executing a map initialization operation, creating a map instance in the system callback function, and performing initialization settings on the map instance;

[0025] S102, adding the initialized map instance to the view hierarchy of the page so as to render the initialized map instance in the page;

[0026] S103, determining whether the map is loaded according to a predetermined map area change callback, and performing a preset visual adjustment operation on the map when the map is loaded;

[0027] S104, ensuring that the custom node is within the visible area of ​​the map, adjusting the view range to include all key nodes, and performing additional map operations based on the center point or specific node;

[0028] S105 , when the vehicle control application receives an event triggered by the user, the center point and visual display of the map are adjusted through the event callback function, so that the map view responds to the user's interaction.

[0029] First, some technical terms involved in the practical application scenarios of the embodiments of the present application are explained, which may include the following:

[0030] Map SDK (Software Development Kit): A map SDK is a development toolkit provided by map service providers that allows developers to integrate and use these providers' map services in their own applications. This includes but is not limited to map display, positioning, navigation, map annotation, route planning, and other functions.

[0031] The SDK provides a series of APIs (Application Programming Interfaces) that allow developers to perform various map operations and customizations, such as setting the map's center point, adjusting the zoom level, and adding map markers. Using the Map SDK helps developers quickly develop map-related features, avoiding the complexity and time cost of building a map system from scratch.

[0032] The Wrapper is a software layer developed on top of the Map SDK. Its purpose is to simplify the differences between different Map SDKs and provide a unified interface for application developers. This allows developers to more easily switch the underlying Map SDK without having to rewrite most of the application code.

[0033] The wrapper hides the specific implementation details of different map SDKs, allowing developers to perform map operations through a unified API, eliminating the need to write specific code for each map SDK. This is particularly useful when developing applications that need to support multiple map services simultaneously. Through the wrapper, developers can implement customized requirements such as setting the map center point and replacing node styles, while maintaining functional consistency and a unified appearance when switching between different map services.

[0034] The following describes the timing and sequence of calling the API when first entering a map using the technical solution of this application in conjunction with specific embodiments, which may include the following:

[0035] Due to vehicle control business requirements, the map needs to cover the entire app's viewport. However, the actual usable area is limited to the upper middle portion. The lower, left, and right sides, as well as the upper portion, all have other views required by the business. When the user first enters the page, the designated center point must be centered within the usable area. Note that this refers to the usable area, not the map itself.

[0036] The first difficulty with the above requirement is that, although the map covers the entire app, it is overlaid with many business-specific views. In this example, the business views are located at the bottom and left and right, while the top is just the system's built-in status bar. For other business requirements, the business views can also be located in other locations or at different heights.

[0037] The official map examples and code only provide instructions for setting the center point for a full-screen map, completely ignoring any obstructions to the business view. Therefore, if you directly call the sample code for Map A using -(void)setCenterCoordinate:(CLLocationCoordinate2D)centerCoordinate animated:(BOOL)animated; , the center point will be centered on the entire map screen, but slightly below the actual usable area.

[0038] Difficulty 2 is: According to its official website documentation, Map A provides various APIs for setting the edges of the map's available area (see the insets parameter of each function for details), for example:

[0039] -(void)setVisibleMapRect:(MAMapRect)mapRect edgePadding:(UIEdgeInsets)insets animated:(BOOL)animated;

[0040] -(MAMapRect)mapRectThatFits:(MAMapRect)mapRect edgePadding:(UIEdgeInsets)insets;

[0041] -(void)showAnnotations:(NSArray*)annotations edgePadding:(UIEdgeInsets)insets animated:(BOOL)animated;

[0042] -(void)showOverlays:(NSArray*)overlays edgePadding:(UIEdgeInsets)inset s animated:(BOOL)animated;

[0043] @property(nonatomic,assign)MACoordinateRegion region;

[0044] Which API can achieve the above results? The documentation and examples are so brief that I have no way of knowing. I can only experiment one by one and found that many of them cannot achieve the desired effect. Finally, I got the best practice.

[0045] Difficulty 3 lies in the lack of a map loading completion API, making it unclear when the map has finished loading upon entering the page. Therefore, if the map hasn't finished loading, we can't begin setting the center point and edge processing, otherwise various strange behaviors will occur. When the page's viewDidAppear system callback function is called, all views on the page are visible to the user. However, this doesn't mean that Map A has finished loading. In fact, based on real-device debugging and extensive practice, the map still takes at least 0.2-0.5 seconds to complete when the viewDidAppear system callback function is called. Therefore, we can't perform map processing in this function. Even delaying the processing is not feasible (because that would make the user clearly aware of it, and we can't be sure of the appropriate delay). Therefore, it takes practice to determine which callback function is most appropriate for processing.

[0046] Difficulty 4 is: the latitude and longitude of the initial center point is generally the position of the car given by the server, but this position is not necessarily available (because it is reported to the server by the car computer, which is a very unstable factor). When the server gives a null value, we have to use the user, that is, the current position of the mobile phone, as the center point when the page is first entered. So when is the timing to obtain this user center point (that is, the user Location attribute of the map)? In any case, it is definitely not when the map is initialized, nor is it the viewDidLoad system callback function, nor is it necessarily the viewDidAppear system callback function. Although viewDidAppear can get the user's position most of the time, it is definitely not absolute. The reason is shown in Difficulty 3. At this time, the actual time to obtain the current position of the mobile phone should be in the callback function after the map loading is completed.

[0047] In some embodiments, determining a system callback function for performing a map initialization operation, creating a map instance in the system callback function, and performing initialization settings on the map instance include:

[0048] The system callback function corresponding to when the main view of the page is loaded or when the page content is about to be displayed is used as the system callback function for performing the map initialization operation;

[0049] Create a map instance in the system callback function and set the basic properties of the map instance to initialize the map instance;

[0050] Among them, the basic properties of the map instance include map agent, user location display, user location tracking accuracy, display compass and zoom controls, map zoom level, map display type and current map level.

[0051] Specifically, the purpose of this embodiment of the application is to properly arrange the initialization and configuration of the map in the App page to ensure the correct loading of the map and the implementation of the function. The following is the implementation process and steps of the map initialization in the page initialization system callback function for easy understanding.

[0052] 1. Select the page to initialize the system callback function

[0053] In iOS application development, page initialization and view loading involve several key steps, each of which corresponds to a different system callback function.

[0054] viewDidLoad: This is the first callback called after the main view of the page is loaded. At this time, the view hierarchy of the entire page has been laid out, but the view may not yet be displayed on the screen. This is the most appropriate time to do some initialization setup.

[0055] viewWillAppear: This callback occurs when the view of the page is about to be displayed on the screen. Some updates can be performed at this time, but heavy calculation operations should be avoided to not affect the smoothness of the animation.

[0056] viewDidAppear: This callback is called when the view is displayed on the screen. It is usually used to start animation, data loading, etc.

[0057] viewDidLayoutSubviews: Called when all subviews in the page are laid out, usually used to adjust the layout.

[0058] For map initialization, it is best to choose viewDidLoad (the system callback function when the main view of the page is loaded) or viewWillAppear (the system callback function when the page content is about to be displayed) because the necessary parameters of the map can be set at this time, and the view has not yet been displayed to the user.

[0059] 2. Map initialization

[0060] In the selected system callback function, perform the following initialization operations:

[0061] Map creation: Create a map instance, usually by calling the constructor or factory method provided by the map SDK.

[0062] Set the following basic properties of the map instance:

[0063] Set Delegate: Specify the map's delegate object to receive callbacks for map events.

[0064] User location display: Use the isShowsUserLocation API to set whether to display the user's current location.

[0065] User location tracking: Set the user location tracking mode through the userTrackingModeAPI, such as tracking the user's location and direction.

[0066] Compass display: Set whether to display the compass through the showsCompass API.

[0067] Magnifier display: Set whether to display the zoom ratio control through the showsScale API.

[0068] Maximum / minimum zoom level: Set the zoom level range of the map through the maxZoomLevel / minZoomLevel API.

[0069] Map type: Use the mapType API to set the map type, such as standard map or satellite map.

[0070] Current level: Set the initial zoom level of the map through the ZoomLevelAPI.

[0071] 3. Add to the view hierarchy

[0072] Add the initialized map to the page's view hierarchy. This step ensures that the map is loaded and rendered as part of the page.

[0073] It should be noted that adjusting the map center point and available area should not be included in the initialization phase, as these operations can only be performed correctly after the map is fully loaded and rendered. If these operations are performed in advance, you may encounter problems such as incorrect map scaling, inaccurate positioning, incorrect center point, and abnormal animation.

[0074] Through the above process and steps, the embodiment of the present application can ensure that the map is correctly initialized in the App page and has basic functions and appearance. This provides a solid foundation for subsequent map operations and user interactions.

[0075] In some embodiments, determining whether the map is loaded completely according to a predetermined map area change callback includes:

[0076] After initializing the map instance, use the map's software development kit to set a default display area. When the default display area is displayed on the map, the map area change callback is triggered, and the map loading is judged to be complete.

[0077] Specifically, let's take Map A as an example. Since Map A's SDK doesn't provide a clear callback function for when map loading is complete, we need to use other callback functions to determine when loading is complete and make corresponding visual adjustments. The following is the implementation process and steps for making visual adjustments in Map A's loading completion callback function.

[0078] In one example, the regionDidChangeAnimated callback function is used to signal when map loading is complete. Specifically, it is: -(void)mapView:(MAMapView*)mapViewregionDidChangeAnimated:(BOOL)animated . This callback function is called when the map's display area changes, whether manually by the user or programmatically. After initializing the map, the Maps SDK sets a default display area, typically centered on the user's current location. Therefore, this callback can serve as a signal that map loading is complete.

[0079] In some embodiments, performing a preset visual adjustment operation on the map includes:

[0080] The center point of the map is adjusted, the visible area of ​​the map is set to the available area, custom nodes are added to the map, and the nodes are drawn within the visible range, wherein the custom nodes represent markers of specific geographic locations.

[0081] Specifically, after determining that the map has been loaded, perform the following visual adjustment operations:

[0082] 1) Adjust the center point of the map:

[0083] Set the center of the map to a specific location based on the application's needs. For example, if it's a car navigation application, the center point might need to be set to the vehicle's current location.

[0084] 2) Adjust the visible area of ​​the map to the available area:

[0085] Set the map's visible area to the available area, ensuring that all important map elements are visible to the user.

[0086] 3) Add custom nodes to the map:

[0087] Adding custom nodes such as vehicle position markers. This typically involves creating a marker object, configuring its appearance, and specifying its coordinates on the map.

[0088] 4) Ensure that the node is within the visible range as much as possible:

[0089] After adding nodes, you may need to adjust the map's zoom level or view extent to ensure that the nodes are not out of the user's view.

[0090] 5) Other operations:

[0091] Perform other map-related operations as needed, such as searching for nearby locations based on a center point.

[0092] By following these steps, you can perform a series of visual adjustments after the map is loaded to meet specific business needs, such as vehicle tracking and user navigation, to ensure that users are provided with a clear, accurate, and easy-to-interact map view.

[0093] The following describes in detail the specific implementation of the above-mentioned visual adjustment operation with reference to specific embodiments, which may include the following:

[0094] 1) Adjust the center point of the map

[0095] According to the official documentation of Map A, Map A provides various APIs for adjusting the center point of the map (see the insets parameter of each function for details), for example:

[0096] -(void)showAnnotations:(NSArray*)annotations edgePadding:(UIEdgeInsets)insets animated:(BOOL)animated;

[0097] -(void)showOverlays:(NSArray*)overlays edgePadding:(UIEdgeInsets)inset s animated:(BOOL)animated;

[0098] @property(nonatomic,assign)MACoordinateRegion region;

[0099] -(void)setCenterCoordinate:(CLLocationCoordinate2D)centerCoordinateani mated:(BOOL)animated;

[0100] @property(nonatomic,assign)CLLocationCoordinate2D centerCoordinate;

[0101] In actual applications, it is necessary to determine which one to use to achieve the desired effect. For example, the first function showAnnotations has a documentation that says: "Set the map so that it can display all annotations in the array. If there is only one value in the array, directly set the center of the map to the position of the annotation." However, in practice, it is found that even if only one value is passed in the array, the effect of setting the center of the map cannot be achieved at all.

[0102] Finally: In practice, the available APIs for setting the central point are:

[0103] -(void)setCenterCoordinate:(CLLocationCoordinate2D)centerCoordinateani mated:(BOOL)animated;

[0104] Alternatively, set the region property of the map (that is, the above @property(nonatom ic, assign)MACoordinateRegion region;).

[0105] 2) Adjust the visible area of ​​the map to the available area

[0106] According to best practices, you must adjust the center point of the map before adjusting the map's visible range, otherwise unexpected situations may occur.

[0107] As mentioned above, there are many APIs for adjusting the visible range of the map. The documentation is vague about what the function parameters are, so the best practice is:

[0108] Using the Maps API:

[0109] -(void)setVisibleMapRect:(MAMapRect)mapRect edgePadding:(UIEdgeInsets)insets animated:(BOOL)animated;

[0110] The first parameter is the current visible area of ​​the map, which is the map's visibleMapRect property. The second parameter is the four-sided boundary distance of the available area, calculated based on the vehicle control page layout. Because the layout is determined by vehicle control business requirements, the four-sided distance is known. The third parameter is the animation switch, which can be passed a Boolean value based on business requirements. If animation is required, pass true; if not, or if no explicit value is specified, it is best to pass false.

[0111] It should be noted that in order to avoid animation conflicts and abnormal bugs, you can set the animation switch in steps 1), 2), and 3). It is best to only turn on one animation and turn off the others, or only turn on the animation of the last step. This is based on the following reasons: because the internal implementation of map animation is unknown (the map SDK is not open source), and animation is a continuous and finite thing; when executing step 1)

[0112] 2) and 3) , we are not sure which area of ​​the map the map SDK uses to proceed to the next step. If it happens to use an area during the animation to set the next step, unexpected effects and exceptions may occur.

[0113] 3) Add custom nodes to the map

[0114] We will add custom nodes to the map, such as vehicle locations and person locations. This is a regular map API call. This is an optional step; if your business requirements do not require adding custom nodes, this step is not required.

[0115] Note that here, we only call -(void)addAnnotations:(NSArray*)annotations; to add the nodes to the map, but we cannot call -(void)showAnnotations:(NSArray*)annotationsanimated:(BOOL)animated; to draw the nodes on the map. This is because, according to the official documentation, this method tries to draw all nodes within the currently visible area of ​​the map, that is, within the screen. This setting conflicts with steps 1) and 2). Therefore, steps 1) and 2) are binary choices with step 4).

[0116] Even without calling showAnnotations, the map will still display the nodes, so the purpose of showAnnotations is to keep the nodes as close to the current visible range of the map as possible. This step is optional and can be done after (1-2) because it does not involve visual adjustments to the map. However, I chose to write it here for easier separation. Step (1) focuses on initializing the map, while step (2) focuses on time configuration.

[0117] 4) Ensure that the node is as visible as possible

[0118] This is the aforementioned drawing of all nodes into the visible range of the map. It has a 2-choose-1 relationship with steps 1) and 2). That is, if you choose to set the center point, there is no guarantee that all nodes can be drawn into the visible range of the map; if you choose to draw all nodes into the visible range of the map, there is no guarantee that the center point will still be at the center of the map.

[0119] Because the center position is constantly changing due to objective factors, we cannot guarantee that the center point will be exactly at the center of the visible range when the map is drawn. For example, on the vehicle control service center page, if all nodes on the map are ensured to appear within the visible range, the center point (the current phone location) will actually be at the bottom.

[0120] 5) Other operations

[0121] The visual adjustments to the map have been completed. There may be other operations required by business needs, such as searching around a center point. These can be done by calling the map API in a regular way.

[0122] In another example, taking the implementation process of another map B as an example, the native SDK documentation support and utility of Map B are better than those of the above-mentioned Map A, and there are not many obstacles when accessing it. For Map B, the best practices summarized in the embodiments of this application are as follows:

[0123] (1) Initialize the map in the page initialization system callback function

[0124] Map initialization includes:

[0125] Map creation and basic map settings are similar to those for Map A. Simply find the corresponding API for Map B and set it up. However, Map B's custom node types and custom node view types must be registered in advance during basic setup, while Map A doesn't require registration. Therefore, Map B requires an additional step: registering custom node types.

[0126] (2) In the callback function after the map is loaded, make further visual adjustments to the map

[0127] Map B provides a clear map loading completion callback function, namely:

[0128] func mapViewDidFinishLoadingMap(_mapView:MKMapView)

[0129] Further visual adjustments include adjusting the center point of the map as mentioned in the aforementioned embodiments, adjusting the visible area of ​​the map to the available area, adding custom nodes to the map (such as vehicle locations), drawing nodes within the visible range as much as possible, and other operations (such as starting to search for surrounding locations based on the center point, etc.).

[0130] It can be seen that these steps and specific APIs are similar to Map A in the aforementioned embodiment, so they will not be repeated here.

[0131] In some embodiments, when the vehicle control application receives a user-triggered event, the center point and visual display of the map are adjusted through the event callback function, including:

[0132] In response to the user's interactive operation, the event callback function corresponding to the interactive operation is triggered. The event callback function is used to adjust the center point of the map to the center position of the available area of ​​the vehicle control application, and the map is adjusted according to the visual adjustment operation corresponding to the event callback function to change the visual display of the map.

[0133] Specifically, embodiments of the present application also include adjusting the map by responding to user interaction events. When a user clicks the Find Car or Find Person button or long-presses a point on the map, the event callbacks triggered by these actions can be used to adjust the center point of the map to the corresponding position. These callbacks are used to move the map center point to the corresponding position and ensure that it is centered within the available area. These operations are dynamic map adjustments, which make the map view responsive to user interaction and, in the event callbacks of user interaction, adjust the center point and visual display of the map according to business needs.

[0134] In some embodiments, the map encapsulator includes a map software development kit layer, a software development kit call layer, a business logic layer and an external call layer, wherein the software development kit call layer includes a map initialization module, a visual adjustment module, a node view customization module and other map interaction modules.

[0135] Specifically, the map encapsulator of the embodiment of the present application adopts a layered design. The layered design is to shield the differences in the map SDK calling methods, place the differences related to the map SDK in the lower layer (i.e., the software development kit calling layer), and place the customization of business needs not related to the map in the middle layer (i.e., the business logic layer) as the input and tools of the underlying layer, and encapsulate the external API and functions in the upper layer (i.e., the external calling layer), so that the map encapsulator can be easily integrated into any project.

[0136] The specific design is as follows:

[0137] Map software development kit layer: includes SDKs for various maps.

[0138] Software Development Kit Call Layer: Specific calls to the map SDK, which is the encapsulation difference point.

[0139] Business logic layer: Places the business logic customization requirements of vehicle control as the underlying input and tool.

[0140] For example: the style of the user node view, the style of the vehicle node view, the logic of long pressing / clicking the button to switch the center point of the map, and the logic of searching for surrounding objects (such as charging stations / car washes, etc.) based on the center point. These business logics that are not related to the map are the same no matter what map is used to implement them, so they should be placed in the second layer.

[0141] External call layer: APIs that are open to the outside world. These APIs are external and are used by external pages or external modules to access the vehicle control map encapsulator.

[0142] In some embodiments, the node view customization module is used to:

[0143] Receive and judge node input parameters to distinguish user nodes from other types of ordinary nodes;

[0144] For common nodes, create a custom node class that inherits from the specific node class provided by the map service provider;

[0145] In the node view generation proxy function of the map service provider, a new node view is reused or created according to the node type, wherein the reuse operation obtains the node view from the memory pool through the specified reuse identifier;

[0146] When the reused node view is unavailable, create a new node view based on the custom node class and customize the type and display status of the new node view according to business requirements;

[0147] For user nodes, in the node adding proxy function of the map service provider, the user node view is determined by the user node type, and the display effect of the user node view is customized according to business needs;

[0148] The update function of the map service provider is used to apply the customized user node view effect to the map in order to personalize the display of the user node.

[0149] Specifically, taking Map A as an example, Map A's node view customization is done by calling Map A's API. At the bottom level, we should only focus on calling the map API, not the specific types of node views, such as people, cars, gas stations, charging stations, etc. These are passed in by the upper-level caller.

[0150] Furthermore, the node input parameters are received and evaluated to determine whether the node is a user node or a regular node. A Boolean value indicates whether this is a user node or another node (such as a car, gas station, or charging station). The user node view on Map A is completely customized and therefore must be treated separately.

[0151] Furthermore, a common node, a custom node class, inherits from a node class provided by Map A. Map A's SDK provides many node classes, all of which are subclasses of the base class MAAnnotation. Based on business needs, we can freely select a node class as the parent class and define our own node class for deep customization. For detailed implementation of custom node classes, see the "Custom Nodes" section of the business logic layer.

[0152] Furthermore, other information specified by the business logic. For example, in the embodiment of this solution, the user node view is a special graph consisting of a pointed blue circle surrounding the user's avatar. This graph falls within the scope of business requirements and is passed to this module by the upper-level caller.

[0153] In an example, the logic is described as follows: 1) 2) 3) need to be done in the proxy function of the following map A:

[0154] -(MAAnnotationView*)mapView:(MAMapView*)mapView viewForAnnotation:(id <maannotation>)annotation; This function is the callback function of map A to generate the corresponding node view for the node.

[0155] 1) Read the input parameters: whether the node is a user node or a common node, and determine whether it is a user node or other node; if it is a user node: proceed to step 4), otherwise proceed to steps 2) and 3); in the callback function of drawing the node view of map A:

[0156] 2) Access the node's attributes: "reuse id attribute of type". The reuse id is actually a string. Use "generate" to create a node view. The "generate" method is the API of map A:

[0157] -(MAAnnotationView*)dequeueReusableAnnotationViewWithIdentifier:(NSString*)identifier;

[0158] The purpose of the quotation marks is that, according to the official website documentation, this function "obtains a node view with a specified reuse identifier from the reuse memory pool" rather than generating a new view. This is an optimization of the SDK's own performance.

[0159] 3) Create + customize + return node view

[0160] As we know from step 2), Map A will obtain an existing node view from the reused memory pool. However, if the node view has never been created, Map A cannot obtain it, and its function will return null. So how is the first node view obtained? Therefore, we determine whether the node view obtained in step 2) is null. If it is null, it means that the node view has never been created, so we create the node view.

[0161] The created node view is a customized node view. Its specific layout has a one-to-one correspondence with the node we customized earlier. Therefore, we need to customize the node view, that is, assign the node type to the node view; assign the current node highlight status to the node view according to business needs; after creation, return to this node view.

[0162] 4) User node view creation

[0163] This requires the following logic to be implemented in the proxy function of the following map A:

[0164] -(void)mapView:(MAMapView*)mapView didAddAnnotationViews:(NSA rray*)views; This function is called by map A after map A adds all nodes to the map.

[0165] First, get the first one in the views parameter, take it out and check whether it is of type MAUserLocation. This type is the default user node type of map A. If it is, it means that the node obtained is a user node.

[0166] Next, create a new object of type MAUserLocationRepresentation and customize it to meet business requirements:

[0167] For example, you can set the display of the accuracy ring (showsAccuracyRing property), whether to indicate the direction (showsHeadingIndicator property), etc. An important customization is to assign the node's image (image property) to the image specified by the business needs, that is, the "it consists of a pointed blue circle surrounding the user's head portrait" mentioned earlier.

[0168] Then, call the map function:

[0169] -(void)updateUserLocationRepresentation:(MAUserLocationRepresentation*)representation;

[0170] Passing the customized MAUserLocationRepresentation type object as a parameter means assigning the user node to the map. From then on, the user location on the map changes from the default blue dot on Map A to the customized effect required by the vehicle control business.

[0171] In another example, the node view customization of map B adopts a common process, which is roughly as follows:

[0172] 1) Register

[0173] In fact, registration is to create a "node-node view" correspondence. This step has been introduced before and can be done when the map is initialized.

[0174] 2) Create a node view

[0175] In its proxy callback function:

[0176] In func mapView(_mapView:MKMapView,viewFor annotation:MKAnnotation)->MKAnnotationView?, perform steps 1), 2), and 3) of creating a node view, similar to those in the Map A module above. This function is the callback function that Map B uses to generate the corresponding node view for a node.

[0177] Furthermore, other map interactions: In addition to the ones mentioned above, there may be other map interactions according to business needs, such as long pressing to change the center point of the map, searching for things around the center point, users double-clicking the map, etc. These are all included in other modules.

[0178] In the embodiment of the present application, the business logic layer includes the following:

[0179] This application solution provides unified management of various functions involved in the node, which are introduced one by one below.

[0180] The business logic layer is used to provide the underlying layer with the required business logic customization information, such as the map node view style; unified management of all node information in the form of enumeration; and other processing, such as drawing pictures of special user nodes according to business needs, including using user avatars when logged in and default avatars when not logged in.

[0181] (1) Custom Node

[0182] Taking Map A as an example, based on business needs, we select one of the many node types in Map A as the parent class to inherit from and create a custom node class. The node design is very simple, requiring only one attribute: the node type.

[0183] In an example, the types of vehicle control scenarios are listed as follows:

[0184] Vehicles, charging stations, parking lots, repair shops, car washes, gas stations, 4S stores, and people (current location of the phone).

[0185] The sample code for a custom node is as follows:

[0186] class TypeResultAnnotation:MAPointAnnotation{

[0187] var type:TypeResultAnnotationType=.result

[0188] }

[0189] (2) Type enumeration

[0190] As mentioned above, custom nodes are mainly distinguished by type, so various business logic information of different types can be carried on the enumeration.

[0191] In iOS development, Swift's enumeration is a powerful type that not only distinguishes types but also carries a lot of type information. This information is represented by member variables or member functions. It is a data storage + data processor. For example:

[0192] 1) The type after a certain type of flow

[0193] Enumeration can realize the flow of types, such as changing from one type to another. If the business needs require that all nodes on the map turn into red circles after being clicked, then the red view is also considered as a type, added to the enumeration, and written in the flow function: If the current state is xx, return to the red state

[0194] 2) The image name corresponding to each type

[0195] Create a member function or variable that returns a different image name for each type.

[0196] 3) Image size for each type

[0197] Create a member function or variable that returns a different image size for each type.

[0198] 4) Reuse ID corresponding to each type

[0199] The reused ID has been introduced before, and here it serves the purpose of storing it.

[0200] (3) Customized node view

[0201] The custom node view inherits from the node view base class provided by map A.

[0202] Now let's design some properties: public properties are assigned by external parties, and private properties are the properties of the node itself, which change with the public properties.

[0203] Public attribute: Type, which is a "(2) Type enumeration". Different types correspond to different images (size, dimensions, style), text, and callouts. When the type is assigned externally, the node view assigns corresponding content to its own image, text, and callout based on the different types.

[0204] Whether it is highlighted: The corresponding image, text, and callout of the highlighted state may be different from the normal state.

[0205] Private attributes: images, text, and others, such as callout.

[0206] In the initialization function of the custom node, operations such as drawing pictures, text, and adjusting the position of pictures will be performed.

[0207] In some embodiments, the external call layer is used to provide external APIs and external interaction methods. The external call methods of the map encapsulator include:

[0208] Provide a parent page that encapsulates map functions. The parent page is used to initialize the map and perform proxy callback processing to facilitate the integration of map functions and the encapsulation of business logic.

[0209] Use external function pages to inherit from parent pages to obtain map functions and add specific business logic to integrate map functions with business needs;

[0210] Alternatively, a map proxy object is created in the map encapsulator. The map proxy object is used for map settings and provides result feedback to the external function page through a callback block or proxy method to minimize direct interaction between the external module and the map encapsulator.

[0211] Alternatively, method exchange and observer mode are used to automatically monitor and respond to system callback functions and target property changes of external function pages, so as to automatically trigger the map encapsulator to execute corresponding map functions.

[0212] Specifically, the external call layer is used to provide a stable API to the outside world, facilitate external calls, minimize external calls and dependencies, and encapsulate as much business logic as possible in this layer.

[0213] (1) External API and external interaction methods

[0214] As mentioned earlier, the map adapter is a standalone module that can be directly integrated into your project. Therefore, in external interactions, its API shields the differences in the underlying map and minimizes external changes.

[0215] In order to achieve low coupling by externally calling these APIs, this embodiment of the application introduces the following three solutions:

[0216] Option 1:

[0217] 1) Encapsulation page

[0218] This map wrapper contains a parent page, which is equivalent to: the outside only needs to jump to the page of this wrapper to enter the map function, and the rest of the logic is processed in this layer.

[0219] For example, if parent page A is part of the local map wrapper, the corresponding map initialization function can be directly called in its page initialization system callback function. The map proxy object can be directly set to parent page A. Then, in the corresponding callback function of the map proxy, parent page A can call the visual adjustment function and other lower-level functional modules to complete the map function.

[0220] 2) External function pages inherit from this page

[0221] Page A only includes map functionality and excludes other business requirements. This business functionality is independent of the map wrapper and is external. Therefore, external users should customize their own pages, but by inheriting from Page A, they achieve the goal of integrating map functionality while also meeting their own customized business requirements.

[0222] Option 2:

[0223] This map wrapper only provides functions, not encapsulated pages. Some functions of the map wrapper will feedback results (such as map search). This feedback exists in the form of callback blocks or proxies. External modules can use these callback blocks or implement proxy methods.

[0224] 1) Encapsulate map agent

[0225] In order to minimize the intersection with the outside, the map encapsulator creates its own xx map proxy object, which is responsible for the map settings.

[0226] 2) External calls to other modules

[0227] Because the page is external, other modules, such as the map initialization module, need to be actively called by the external page. Active calls include but are not limited to direct calls: for example, external page B directly calls the map wrapper's public API: the map initialization API. The map initialization API is actually a simple call to the underlying module "xx_map initialization".

[0228] In one example, sending notifications is also a good way to communicate. It can make the API private and not visible to the outside world. The external and map wrapper communicate back and forth using notifications, and the data is carried in the notifications.

[0229] The specific implementation steps are as follows:

[0230] 1. The map encapsulator registers specific notifications, and different notifications perform different functions; for example, map initialization can correspond to notification A, map interaction can correspond to notification B, and so on.

[0231] 2. Send corresponding notifications when necessary.

[0232] 3. The map encapsulator receives specific notifications and completes specific functions.

[0233] 4. The map encapsulator actively sends specific notifications to tell the outside world some information (such as transferring data, notifying that an operation has been completed, etc.).

[0234] Option 3:

[0235] This solution is the same as Solution 2, but does not encapsulate the page. For some functions of the map encapsulator, feedback on operation results or data (such as map search) is provided in the form of callback blocks or proxies. External modules can use these callback blocks or implement proxy methods.

[0236] However, the implementation of solution 3 is slightly different:

[0237] Utilizing iOS's commonly used method swapping and observers, we monitor the movements of various system callback functions, custom functions, and custom properties on the page, minimizing the need for external calls and allowing the map wrapper to "move" automatically. It's important to note that method swapping and observer techniques are common iOS methods and are unrelated to the technical solution of this application, so we won't explain them here.

[0238] The specific implementation steps of Solution 3 are as follows:

[0239] Assign the external page to the map encapsulator as a weak reference object.

[0240] For those functions that need to be implemented in the system callback function of the page, the map encapsulator uses the extension + method exchange technology (hook). Whenever the external page enters the page initialization system callback function, the map encapsulator calls its own corresponding module in the function, such as the map initialization API.

[0241] For those other fragmented functions that are not implemented in the unified callback function of the page, the map encapsulator uses the corresponding properties of the external page through observer technology to automatically call the corresponding module.

[0242] If an external page needs to call the long press function of the map, it has a corresponding public attribute X. The map encapsulator will observe this attribute X, and when X changes accordingly, the map will call the corresponding function module.

[0243] It's important to emphasize that Solutions 1, 2, and 3 are not a one-or-the-other-choice relationship. Instead, they can coexist based on business needs. Choose the most appropriate approach for each scenario.

[0244] In some embodiments, the method further comprises:

[0245] In the car control application's map wrapper, develop map function components that meet the application's requirements. These components are then divided and integrated into the map wrapper's software development kit call layer according to the application's layered architecture.

[0246] Add a relationship configuration module in the external call layer. The relationship configuration module is used to manage and switch the map service currently used by the vehicle control application and switch the software development kit of the current map;

[0247] The user determines the map service used by the vehicle control application through configuration or selection, uses the relationship configuration module to record the user's map service preference, and uploads the map service preference data to the server so that the server configures the application according to the map service preference data;

[0248] During the map service switching process, the map proxy object currently used by the external call layer is changed, while the software development kit call layer and business logic layer remain unchanged.

[0249] Specifically, the map encapsulator of the present application also provides the functions of adding and switching maps.

[0250] First, add the following map content:

[0251] Although the map wrapper currently supports two maps, you can also add more maps based on this idea. The specific implementation steps are as follows:

[0252] 1. Develop functional components that meet vehicle control requirements based on the official documentation and code examples of the new map SDK.

[0253] 2. According to the layered planning, divide the functional components into modules and place them at the bottom layer.

[0254] 3. Place the map SDK at the bottom layer.

[0255] 4. In addition to adding necessary proxy objects in the upper layer, the rest of the logic, including the business logic layer, will basically not change. This is a very good design.

[0256] Secondly, the content of the map switch is as follows:

[0257] Map selection involves understanding and customizing user habits. As mentioned earlier, the domestic version uses Map A, while the overseas version uses Map B. This fixed relationship is determined by business requirements. However, a map wrapper can make this fixed relationship configurable, even user-selectable.

[0258] Whether a product manager configures this relationship or a dialog pops up for the user to select the relationship mapping, it's the same thing, just with a different source. The layered design of the map wrapper allows for one-click switching and one-click validation.

[0259] 1) Relationship configuration module

[0260] Add a relationship operation module in the upper layer, which is responsible for managing which map SDK the map encapsulator currently uses. Once the external environment selects it, the relationship operation module is responsible for switching the currently used SDK from map SDK_A to map SDK_B.

[0261] In the specific design, the relationship configuration module should exist as a tool module, which is a tool for other upper-level modules. Other upper-level modules obtain the functions of the current specific map object through it, including the map proxy object and map initialization API, and other map functions (if any).

[0262] It should be noted that, in terms of specific implementation, the relationship operation module can adopt a series of designs such as the commonly used factory mode and adapter mode to ensure the rationality of the call.

[0263] The only layer affected by the switch is the upper layer. For example, when switching from map B to map A, you only need to change the map proxy object currently used by the upper layer, switching from the proxy object of map B to the proxy object of map A. The rest of the calling modules, the bottom layer, and the business logic layer remain unchanged.

[0264] In addition, taking into account user habits, when the map wrapper is called externally, the map wrapper can provide a pop-up window or other form to allow users to select their favorite map. This user's usage habits can be recorded by the map wrapper and uploaded to the server for further analysis. The server can also further configure the map wrapper, such as turning on / off the user's selection rights, specifying the map types supported by the map wrapper (for example, the map wrapper originally supports five maps, but the server only allows the selection of three of them), etc.

[0265] Based on the technical solutions provided in the embodiments of this application and the best practices of multiple real-device tests, this solution has developed a proven map wrapper that has been put into use in the company's commercial projects. It is compatible with both the latest and historical versions of maps, meeting the needs of vehicle control services, and can set map center points and replace node styles in customized areas. This map wrapper utilizes a layered design to shield against differences in the adaptation of different map SDKs, providing a stable and unified API and supporting real-time map switching.

[0266] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0267] Figure 2 This is a schematic diagram of the structure of the map encapsulator implementation device for the vehicle control application provided by the embodiment of the present application. Figure 2 As shown, the map encapsulator implementation device of the vehicle control application includes:

[0268] The determining module 201 is configured to determine a system callback function for executing a map initialization operation, create a map instance in the system callback function, and perform initialization settings on the map instance;

[0269] The rendering module 202 is configured to add the initialized map instance to the view hierarchy of the page so as to render the initialized map instance in the page;

[0270] The judgment module 203 is configured to judge whether the map is loaded according to the predetermined map area change callback, and perform a preset visual adjustment operation on the map when the map is loaded;

[0271] An adjustment module 204 is configured to ensure that the custom node is within the visible area of ​​the map, adjust the view range to include all key nodes, and perform additional map operations based on the center point or specific nodes;

[0272] The interaction module 205 is configured to adjust the center point and visual display of the map through an event callback function when the vehicle control application receives an event triggered by the user, so that the map view responds to the user's interaction.

[0273] In some embodiments, Figure 2 The determination module 201 uses the system callback function corresponding to when the page main view is loaded or when the page content is about to be displayed as the system callback function for performing the map initialization operation; creates a map instance in the system callback function, and sets the basic properties of the map instance to initialize the map instance; wherein the basic properties of the map instance include map agent, user location display, user location tracking accuracy, display compass and zoom controls, map zoom level, map display type and current map level.

[0274] In some embodiments, Figure 2 After initializing the map instance, the judgment module 203 uses the map software development kit to set a default display area. When the default display area is displayed on the map, the map area change callback is triggered, and it is judged that the map loading is completed.

[0275] In some embodiments, Figure 2 The judgment module 203 adjusts the center point of the map, sets the visible area of ​​the map as the available area, adds a custom node to the map, and draws the node within the visible range, wherein the custom node represents a marker of a specific geographical location.

[0276] In some embodiments, Figure 2 The interactive module 205 responds to the user's interactive operation, triggers the event callback function corresponding to the interactive operation, uses the event callback function to adjust the center point of the map to the center position of the available area of ​​the vehicle control application, and adjusts the map according to the visual adjustment operation corresponding to the event callback function to change the visual display of the map.

[0277] In some embodiments, the map encapsulator includes a map software development kit layer, a software development kit call layer, a business logic layer and an external call layer, wherein the software development kit call layer includes a map initialization module, a visual adjustment module, a node view customization module and other map interaction modules.

[0278] In some embodiments, Figure 2 The node view customization module 206 is used to receive and judge node input parameters to distinguish user nodes from other types of ordinary nodes; for ordinary nodes, a custom node class is created, and the custom node class inherits from the specific node class provided by the map service provider; in the node view generation proxy function of the map service provider, according to the node type, a new node view is reused or created, wherein the reuse operation obtains the node view from the memory pool through the specified reuse identifier; when the reused node view is not available, a new node view is created according to the custom node class, and the type and display status of the new node view are customized according to business needs; for user nodes, in the node addition proxy function of the map service provider, the user node view is determined by the user node type, and the display effect of the user node view is personalized according to business needs; using the update function of the map service provider, the customized user node view effect is applied to the map to personalize the display of the user node.

[0279] In some embodiments, the external call layer is used to provide external APIs and external interaction methods. Figure 2 The external call module 207 is used to provide a parent page that encapsulates map functions. The parent page is used to initialize the map and perform proxy callback processing so as to integrate map functions and encapsulate business logic; the external function page is used to obtain map functions and add specific business logic by inheriting from the parent page so as to integrate map functions with business needs; or, a map proxy object is created in the map encapsulator, and the map proxy object is used for map settings, and result feedback is provided to the external function page through a callback block or proxy method to minimize direct interaction between the external module and the map encapsulator; or, method exchange and observer mode are used to automatically monitor and respond to system callback functions and target attribute changes of the external function page so as to automatically trigger the map encapsulator to execute corresponding map functions.

[0280] In some embodiments, Figure 2 The map switching module 208 is used to develop map function components that meet the application requirements in the map encapsulator of the vehicle control application, and divide and integrate the map function components into the software development tool kit call layer of the map encapsulator according to the layered architecture plan of the application; add a relationship configuration module in the external call layer, the relationship configuration module is used to manage and switch the map service currently used by the vehicle control application, and switch the software development tool kit of the current map; the user determines the map service used by the vehicle control application through configuration or selection, uses the relationship configuration module to record the user's map service preference, and uploads the map service preference data to the server, so that the server configures the application according to the map service preference data; during the map service switching process, the map proxy object currently used by the external call layer is changed, and the software development tool kit call layer and the business logic layer remain unchanged.

[0281] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0282] Figure 3 Schematic diagram of the structure of the electronic device 3 provided in the embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps of the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0283] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to implement the present application. One or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of computer program 303 in electronic device 3.

[0284] The electronic device 3 may be a desktop computer, a notebook, a PDA, a cloud server or other electronic device. The electronic device 3 may include but is not limited to a processor 301 and a memory 302. Those skilled in the art will understand that Figure 3 It is only an example of electronic device 3 and does not constitute a limitation of electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0285] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0286] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard drive or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the electronic device 3. Furthermore, the memory 302 can include both an internal storage unit of the electronic device 3 and an external storage device. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or is about to be output.

[0287] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment 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-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0288] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0289] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0290] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer equipment and methods can be implemented in other ways. For example, the apparatus / computer equipment embodiments described above are merely schematic. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of the apparatus or unit, which may be electrical, mechanical or other forms.

[0291] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0292] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0293] If the integrated module / 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-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0294] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.< / maannotation>

Claims

1. A method for implementing a map encapsulator for a vehicle control application, characterized in that: include: Determining a system callback function for executing a map initialization operation, creating a map instance in the system callback function, and performing initialization settings on the map instance; Adding the initialized map instance to the view hierarchy of the page so as to render the initialized map instance in the page; Determining whether the map is loaded according to a predetermined map area change callback, and performing a preset visual adjustment operation on the map when the map is loaded; Ensure that custom nodes are within the visible area of ​​the map, adjust the view range to include all key nodes, and perform additional map operations based on the center point or specific nodes; When the vehicle control application receives an event triggered by a user, the center point and visual display of the map are adjusted through the event callback function so that the map view responds to the user's interaction; The map encapsulator includes a map software development kit layer, a software development kit call layer, a business logic layer, and an external call layer. The software development kit call layer includes a map initialization module, a visual adjustment module, a node view customization module, and other map interaction modules. The node view customization module is used to: Receive and judge node input parameters to distinguish user nodes from other types of ordinary nodes; For the common node, create a custom node class, where the custom node class inherits from the specific node class provided by the map service provider; In the node view generation proxy function of the map service provider, a new node view is reused or created according to the node type, wherein the reuse operation obtains the node view from the memory pool through a specified reuse identifier.

2. The method according to claim 1, characterized in that The determining of a system callback function for executing a map initialization operation, creating a map instance in the system callback function, and performing initialization settings on the map instance includes: The system callback function corresponding to when the page main view is loaded or when the page content is about to be displayed is used as the system callback function for performing the map initialization operation; Creating a map instance in the system callback function and setting basic properties of the map instance so as to initialize the map instance; Among them, the basic properties of the map instance include map agent, user location display, user location tracking accuracy, display compass and zoom controls, map zoom level, map display type and current map level.

3. The method according to claim 1, characterized in that The method of determining whether the map loading is complete according to the predetermined map area change callback includes: After the map instance is initialized, a default display area is set using the map software development kit. When the default display area is displayed in the map, the map area change callback is triggered, and it is determined that the map loading is complete.

4. The method according to claim 1, wherein The performing of a preset visual adjustment operation on the map includes: The center point of the map is adjusted, the visible area of ​​the map is set as the available area, a custom node is added to the map, and the node is drawn within the visible range, wherein the custom node represents a marker of a specific geographic location.

5. The method according to claim 1, wherein When the vehicle control application receives an event triggered by a user, adjusting the center point and visual display of the map through an event callback function includes: In response to a user's interactive operation, an event callback function corresponding to the interactive operation is triggered. The event callback function is used to adjust the center point of the map to the center of the available area of ​​the vehicle control application, and the map is adjusted according to the visual adjustment operation corresponding to the event callback function to change the visual display of the map.

6. The method according to claim 1, characterized in that The node view customization module is also used to: When the reused node view is unavailable, a new node view is created according to the custom node class, and the type and display state of the new node view are customized according to business requirements; For the user node, in the node adding agent function of the map service provider, the user node view is determined by the user node type, and the display effect of the user node view is personalized according to business needs; The customized user node view effect is applied to the map by utilizing the update function of the map service provider, so as to perform personalized display of the user node.

7. The method according to claim 1, characterized in that The external call layer is used to provide external API and external interaction mode. The external call method of the map encapsulator includes: Provide a parent page that encapsulates map functions, and the parent page is used to initialize the map and perform proxy callback processing to integrate map functions and encapsulate business logic; Utilize the external function page to obtain the map function and add specific business logic by inheriting from the parent page, so as to integrate the map function with the business needs; Alternatively, a map proxy object is created in the map encapsulator, the map proxy object is used for map settings, and provides result feedback to the external function page through a callback block or a proxy method, so as to minimize direct interaction between the external module and the map encapsulator; Alternatively, method exchange and observer mode are adopted to automatically monitor and respond to the system callback function and target attribute changes of the external function page, so as to automatically trigger the map encapsulator to execute the corresponding map function.

8. The method according to claim 1, characterized in that The method further comprises: In the map wrapper of the vehicle control application, developing a map function component that meets the application requirements, and dividing and integrating the map function component into the software development kit call layer of the map wrapper according to the layered architecture planning of the application; Add a relationship configuration module in the external call layer, the relationship configuration module is used to manage and switch the map service currently used by the vehicle control application, and switch the software development kit of the current map; The user determines the map service used by the vehicle control application through configuration or selection, uses the relationship configuration module to record the user's map service preference, and uploads the map service preference data to the server, so that the server performs application configuration according to the map service preference data; During the map service switching process, the map proxy object currently used by the external call layer is changed, and the software development kit call layer and the business logic layer remain unchanged.

9. A map encapsulator implementation device for vehicle control applications, characterized in that: include: a determination module configured to determine a system callback function for executing a map initialization operation, create a map instance in the system callback function, and perform initialization settings on the map instance; A rendering module is configured to add the initialized map instance to the view hierarchy of the page so as to render the initialized map instance in the page; a judgment module configured to judge whether the map is loaded according to a predetermined map area change callback, and perform a preset visual adjustment operation on the map when the map is loaded; an adjustment module configured to ensure that the custom node is within the visible area of ​​the map, adjust the view range to include all key nodes, and perform additional map operations based on the center point or specific nodes; an interaction module configured to adjust the center point and visual display of the map through an event callback function when the vehicle control application receives an event triggered by the user, so that the map view responds to the user's interaction; The map encapsulator includes a map software development kit layer, a software development kit call layer, a business logic layer, and an external call layer. The software development kit call layer includes a map initialization module, a visual adjustment module, a node view customization module, and other map interaction modules. The node view customization module is used to: receive and judge node input parameters to distinguish user nodes from other types of ordinary nodes; create a custom node class for the ordinary node, and the custom node class inherits from the specific node class provided by the map service provider; in the node view generation proxy function of the map service provider, reuse or create a new node view according to the node type, where the reuse operation obtains the node view from the memory pool through the specified reuse identifier.

Images