Automatic updating method during APP-UI binding data change

Abstract

The invention provides an automatic updating method during APP-UI binding data change, the method adopts a generic programming mode to package a set of template interfaces, and the method comprises the following steps: S1, creating a global observer processing object; s2, creating a data observer set; s3, data generated by a user is packaged into a data type, all components only using the data type are registered into a monitoring set, and when the data changes, all dependent components can be matched according to the data type and updating is automatically notified: S3.1, an observer monitors a Map set; s3.2, adding an observer to an observer set; s3.3, when data changes including addition, deletion and updating occur, obtaining an observer set according to the Key; s3.4, an observer changes the notification, and the observer executes corresponding actions according to the characteristics of the observer; and S3.5, when a certain observer is not needed, removing one monitor from the monitor set.

Description

Technical Field

[0001] The invention belongs to the technical field of Android development, and in particular relates to a method for automatically updating APP-UI binding data when it changes. Background Art

[0002] Good-looking interface design and friendly interaction methods on mobile APPs require drawing components provided by the Android development platform. Each component can only perform a single function, such as a button can only accept user click events. Android development is to combine components to receive or display data generated by users, such as the display and sliding of contact information lists in the address book. However, the data generated by users may be used by components of multiple different interfaces. When the data changes, developers need to consider which interface components need to be updated at this time.

[0003] Components on the Android platform can only passively draw the data passed to them. When the data changes, the components will not automatically update the component status according to the latest data. Instead, the latest data needs to be re-transmitted and the components need to be notified to draw in order to update the component status and experience the friendliness of APP interaction.

[0004] However, the data generated by users is usually used by components of multiple different interfaces. When some data changes, developers need to think about which components of which interfaces use the data and notify the corresponding components one by one to update the data. However, an APP has many components, which makes the management of component and data matching cumbersome and difficult to maintain.

[0005] In addition, common terms in the prior art include:

[0006] APP: software installed on the mobile phone, such as WeChat.

[0007] APP-UI: Interface design in software. An interface consists of several functional components. For example, the WeChat avatar is drawn by the component provided by Android for displaying pictures, and the style of the WeChat avatar is determined by the data provided to the drawing component. Summary of the invention

[0008] In order to solve the above problems, the purpose of this application is to design an automatic update method when the APP-UI binding data changes, which can enable the components of the Android platform to establish a binding relationship with the data that needs to be drawn, so that when the data changes, all components using the data are automatically found and notified to update.

[0009] Specifically, the present invention provides a method for automatically updating APP-UI binding data when it changes. The method adopts a generic programming method to encapsulate a set of template interfaces, including the following steps:

[0010] S1, create a global observer processing object, create a global singleton object, and trigger data change related actions through this singleton object operation in the entire project, expressed as:

[0011]

[0012] S2, create a data observer collection,

[0013] Observer capability definition:

[0014] Observation object, represented by: @param <data>

[0015] public interface IDataChangeListener<Data extends BaseData> {

[0016] String getObserverName();

[0017] This function can get the name of the data observer;

[0018] S3, encapsulates the data generated by the user into a data type, and all components that only use this data type are registered in the listening collection. When the data changes, all dependent components can be matched according to the data type and automatically notified and updated: The order relationship of a data type is as follows:

[0019] S3.1, create an observer to monitor the Map collection;

[0020] S3.2, add an observer to the observer collection;

[0021] S3.3, when data changes including addition, deletion, and update, obtain the observer set according to the key;

[0022] S3.4, Observer: Change notification, the observer performs corresponding actions according to its own characteristics;

[0023] S3.5, when an observer is no longer needed, remove a listener from the listener set.

[0024] The step S3 further comprises:

[0025] S3.1, create an observer to listen to the Map collection, expressed as:

[0026] private final Map <Class<?> ,CopyOnWriteArraySet <idatachangelistener>>

[0027] changeListeners=new HashMap<>();

[0028] Among them, Class<?> represents the table in the database being monitored; Set <datachangelistener>Represents a collection of listeners that listen to each listener in this table;

[0029] S3.2, adding an observer to the observer set, is represented as:

[0030]

[0031]

[0032] S3.3, when data changes including addition, deletion, and update, the observer set is obtained according to the key, expressed as:

[0033] @param tClass observed object category;

[0034] @param <model>The inherited parent class is BaseData;

[0035] @return returns the observer collection, which supports multi-threaded concurrent reading and writing, but does not support multi-threaded simultaneous writing, expressed as

[0036]

[0037] S3.4, notify observers that data has changed:

[0038] Observer: Delete notification, represented by:

[0039]

[0040]

[0041] Observer: Change notification, represented by:

[0042]

[0043] S3.5, remove a listener from the listener set, expressed as:

[0044]

[0045] The step S3.3 obtains the observer set according to the Key, that is, the corresponding value can be found through the index. The Key here represents the data type, and all the corresponding observers can be found through the data type.

[0046] In the method, notification is triggered when the following situations occur:

[0047] A. When a data entity is added or modified, an observer notification is triggered;

[0048] The data entity observed by the observer is represented by: @param datas,

[0049] There are not many identification behaviors for data, just updating data attributes and deleting data entities;

[0050] The specific behavior identifier of the observer is expressed as: @param action,

[0051] There are two behaviors: adding devices and deleting devices. After executing different behaviors, the processing results will be different. Here, tag is used to identify the behavior that triggers the observer to notify this behavior;

[0052] However, the behavior that one behavior triggers may be diverse, so we need to distinguish and treat them through behavior identifiers, as shown in the following example:

[0053] void onDataSave(Object action,Data...datas);

[0054] A unified trigger function for data addition or update behavior, and informs the observer through the action identifier what action caused the data change, so that the observer can take his own actions; B. When the data entity undergoes deletion behavior, the observer is notified.

[0055] The actions triggered by adding, deleting, and updating the data need to be determined by the observer, i.e., the business function module, similar to news broadcasting, which notifies that a change has occurred and also conveys what has changed;

[0056] The purpose of the tag is to inform multiple data observers how to take corresponding actions when the received data has changed.

[0057] The tag is customized according to the business function and can be expressed as:

[0058] Device added successfully notification: String TAG_DEV_ADD = "DEV_ADD";

[0059] Device list deletion device notification callback: String TAG_DEV_LIST_DEL = "DEV_LIST_DEL";

[0060] Device list refresh operation: String TAG_DEV_REFRESH_LIST = "DEV_REFRESH_LIST".

[0061] An APP can have many data types, and steps S3.1-S3.5 can be repeated for each data type.

[0062] The observers include a device list observer.

[0063] Therefore, the advantage of this application is that during the APP development process, this method encapsulates the data generated by users into a data type, and all components that only use this data type are registered in the listening collection. When the data changes, all dependent components can be matched according to the data type and automatically notified for updates. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention.

[0065] Figure 1 It is a flow chart of the present application method.

[0066] Figure 2 This is a code flow diagram of step 3 of the method of this application. DETAILED DESCRIPTION

[0067] In order to more clearly understand the technical content and advantages of the present invention, the present invention is now further described in detail in conjunction with the accompanying drawings.

[0068] This method uses the characteristics of JAVA language and adopts generic programming to encapsulate a set of template interfaces, such as Figure 1 As shown, including:

[0069] S1, create a global observer processing object, create a global singleton object, and trigger data change related actions through this singleton object operation in the entire project, expressed as:

[0070]

[0071] S2, create a data observer collection,

[0072] Observer capability definition:

[0073] Observation object, represented by: @param <data>

[0074] public interface IDataChangeListener<Data extends BaseData> {

[0075] String getObserverName();

[0076] This function can get the name of the data observer, because one data can have multiple observers, which makes it clearer when debugging the data;

[0077] S3 encapsulates the data generated by users into data types, and all components that only use this data type are registered in the monitoring collection. When the data changes, all dependent components can be matched according to the data type and automatically notified for updates: Figure 2 As shown, the order of a data type is as follows:

[0078] S3.1, create an observer to monitor the Map collection;

[0079] S3.2, add an observer to the observer collection;

[0080] S3.3, when data changes including addition, deletion, and update, obtain the observer set according to the key;

[0081] S3.4, Observer: Change notification, the observer performs corresponding actions according to its own characteristics;

[0082] S3.5, when an observer is no longer needed, remove a listener from the listener set.

[0083] An APP can have many data types, and steps S3.1-S3.5 can be repeated for each data type.

[0084] The step S3 further comprises:

[0085] S3.1, create an observer to listen to the Map collection, expressed as:

[0086] private final Map <Class<?> ,CopyOnWriteArraySet <idatachangelistener>>

[0087] changeListeners=new HashMap<>();

[0088] Among them, Class<?> represents the table in the database being monitored; Set <datachangelistener>Represents a collection of listeners that listen to each listener in this table;

[0089] S3.2, adding an observer to the observer set, is represented as:

[0090]

[0091] S3.3, when data changes including addition, deletion, and update, the observer set is obtained according to the key, and the corresponding value can be found through the index. The key here represents the data type, and all the corresponding observers can be found through the data type, which is expressed as:

[0092] @param tClass observed object category;

[0093] @param <model>The inherited parent class is BaseData;

[0094] @return returns the observer collection, which supports multi-threaded concurrent reading and writing, but does not support multi-threaded simultaneous writing, expressed as

[0095]

[0096]

[0097] S3.4, notify observers that data has changed: Observer: delete notification, expressed as:

[0098] Observer: Change notification, represented by:

[0099]

[0100]

[0101] S3.5, remove a listener from the listener set, expressed as:

[0102]

[0103] In the method, notification is triggered when the following situations occur: A. When a data entity is added or modified, the observer notification is triggered; the data entity observed by the observer is represented by: @param datas,

[0104] There are not many identification behaviors for data, just updating data attributes and deleting data entities;

[0105] The specific behavior identifier of the observer is expressed as: @param action,

[0106] There are two behaviors: adding devices and deleting devices. After executing different behaviors, the processing results will be different. Here, tag is used to identify the behavior that triggers the observer to notify this behavior;

[0107] However, the behavior that one behavior triggers may be diverse, so we need to distinguish and treat them through behavior identifiers, as shown in the following example:

[0108] void onDataSave(Object action,Data...datas);

[0109] The unified trigger function for data addition or update behavior tells the observer what action caused the data change through the action identifier, so that the observer can take his own action.

[0110] B. When a data entity is deleted, the observer notification is triggered.

[0111] C. The actions triggered by adding, deleting, and updating the data need to be determined by the observer, i.e., the business function module, similar to news broadcasting, which notifies that a change has occurred and also conveys what changes have occurred;

[0112] The role of the tag is to inform many data observers how to take corresponding actions when receiving data that has changed. For example, if a WeChat friend updates his profile picture, the tag action that needs to be executed for the profile picture in your contact list is to refresh the list and update the profile picture of the latest friend. Therefore, the tag is customized according to the business function and can be expressed as:

[0113] Device added successfully notification: String TAG_DEV_ADD = "DEV_ADD";

[0114] Device list deletion device notification callback: String TAG_DEV_LIST_DEL = "DEV_LIST_DEL";

[0115] Device list refresh operation: String TAG_DEV_REFRESH_LIST = "DEV_REFRESH_LIST".

[0116] The observers include a device list observer.

[0117] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.< / model> < / datachangelistener> < / idatachangelistener> < / data> < / model> < / datachangelistener> < / idatachangelistener> < / data>

Claims

1. A method for automatically updating APP-UI binding data when it changes, characterized in that: The method adopts a generic programming approach to encapsulate a set of template interfaces, including the following steps: S1, create a global observer processing object, create a global singleton object, and trigger data change related actions through this singleton object operation in the entire project, expressed as: S2, create a data observer collection, Observer capability definition: Observation object, represented by: @param <data>< / data> public interface IDataChangeListener<Data extends BaseData> {} S3 encapsulates the data generated by users into data types. All components that use only this data type are registered in the monitoring collection. When the data changes, all dependent components can be matched according to the data type and automatically notified for updates: The order of a data type is as follows: S3.1, create an observer to monitor the Map collection; S3.2, add an observer to the observer collection; S3.3, when data changes including addition, deletion, and update, obtain the observer set according to the key; S3.4, Observer: Change notification, the observer performs corresponding actions according to its own characteristics; S3.5, when an observer is no longer needed, remove a listener from the listener set.

2. According to claim 1, a method for automatically updating when APP-UI binding data changes, characterized in that: The step S3 further comprises: S3.1, create an observer to listen to the Map collection, expressed as: private final Map<Class<?>,CopyOnWriteArraySet <idatachangelistener> >changeListeners=new HashMap<>();< / idatachangelistener> Among them, Class<?> represents the table in the database being monitored; Set <datachangelistener> Represents a collection of listeners that listen to each listener in this table;< / datachangelistener> S3.2, adding an observer to the observer set, is represented as: S3.3, when data changes including addition, deletion, and update, the observer set is obtained according to the key, expressed as: @param tClass observed object category; @param <model> The inherited parent class is BaseData;< / model> @return returns the observer collection, which supports multi-threaded concurrent reading and writing, but does not support multi-threaded simultaneous writing, expressed as S3.4, notify observers that data has changed: Observer: Delete notification, represented by: Observer: Change notification, represented by: S3.5, remove a listener from the listener set, expressed as:

3. The method for automatically updating APP-UI binding data when it changes according to claim 2, characterized in that: The step S3.3 obtains the observer set according to the Key, that is, the corresponding value can be found through the index. The Key here represents the data type, and all the corresponding observers can be found through the data type.

4. The method for automatically updating APP-UI binding data when it changes according to claim 2, characterized in that: In the method, notification is triggered when the following situations occur: A. When a data entity is added or modified, an observer notification is triggered; The data entity observed by the observer is represented by: @param datas, There are not many identification behaviors for data, just updating data attributes and deleting data entities; The specific behavior identifier of the observer is expressed as: @param action, There are two behaviors: adding devices and deleting devices. After executing different behaviors, the processing results will be different. Here, tag is used to identify the behavior that triggers the observer to notify this behavior; However, the behavior that one behavior triggers may be diverse, so we need to distinguish and treat them through behavior identifiers, as shown in the following example: void onDataSave(Object action,Data...datas); A unified trigger function for data addition or update behavior, and informs the observer through the action identifier; B. Trigger observer notification when data entity deletion behavior occurs.

5. The method for automatically updating APP-UI binding data when it changes according to claim 4, characterized in that: The actions triggered by the addition, deletion, and update of the data need to be determined based on the observer, that is, the business function module, that is, to notify that a change has occurred and also to convey what changes have occurred; the role of the tag is to inform many data observers how to take corresponding actions when they receive that the data has changed.

6. A method for automatically updating APP-UI binding data when it changes according to claim 5, characterized in that: The tag is customized according to the business function and can be expressed as: Device added successfully notification: String TAG_DEV_ADD = "DEV_ADD"; Device list deletion device notification callback: String TAG_DEV_LIST_DEL = "DEV_LIST_DEL"; Device list refresh operation: String TAG_DEV_REFRESH_LIST = "DEV_REFRESH_LIST".

7. The method for automatically updating APP-UI binding data when it changes according to claim 1, characterized in that: An APP can have many data types, and steps S3.1-S3.5 can be repeated for each data type.

8. The method for automatically updating APP-UI binding data when it changes according to claim 1, characterized in that: The observers include a device list observer.

Images